Mommy, where do ideas come from?

Last week some designers from Google came to our studio for a discussion about the  practice of interaction design. We each shared a bit about our team structures and processes, and talked about some of the unique challenges that we face as a consultancy vs an in-house design team. But some of the most interesting discussions emerged when we focused on the areas of overlap - the basic bread and butter of interaction design. One of the most provocative questions posed by the Googlers was simply: “Where do ideas come from?”

We spend a lot of time thinking and talking about how we do things around here, but if we’re honest, this is the “then a miracle occurs” step in our design process.

This is where the rubber meets the road for every designer: you’ve done your research, synthesis, and analysis to clearly articulate the problem you’re trying to solve, and now it’s time to produce that winning design solution. You get up, grab a marker, and hope inspiration strikes somewhere along those five small steps to the whiteboard. As seasoned designers, it’s not something we think much about anymore - it just happens (unless it doesn’t). But as mentors, it’s important not to yada yada yada the best part (though we DID mention the lobster bisque).

So this week, we’ve spent a little time looking inward to try to develop a deeper understanding of where design ideas come from. Here’s what we found:

Research matters

Cooper designers conduct our own user research, and many feel that this provides indispensible fuel for design ideas. Experiencing real people in their actual environments fuels our senses of empathy and intuition that helps to guide us towards the ideas that make people happy, successful (and even better looking). Plus, the research phase affords us the opportunity to be fully immersed in the users and the domain for a few weeks at the start of the project, which in addition to providing rich data and empathy, also gives our brains boot-up time to start noodling on the problem and explore possible solutions in the background. Many of our designers confessed that they often doodle during interviews, sketching design ideas when inspiration strikes without the pressure of being expected to produce a solution. At the end of the research and analysis phase when patterns, goals, and requirements have been formally defined, designers can flip back through these quick sketches and easily pick out the good ideas from the bad and begin to improve upon them based on their deeper understanding of the users and the problems that must be solved.

Sometimes, words are worth 1,000 pictures

The first step in our design ideation process comes before any “official” sketching is done: we describe the users’ ideal experience in words. The scenarios we develop at this stage are forward-looking and technology-agnostic, focusing on the personas and how they think, feel and behave rather than on specific interface elements or technical implementations. We also identify experience keywords that describe the emotional response that users should have to the product. Not having to answer the “how” frees us up to think big, imagining the best-case scenario for how the product supports each persona in achieving his or her goals. Then, when it comes time to actually start sketching and exploring interaction, form and visual languages, we’re already united around a clear vision for the kind of experience that would truly delight our users, helping us to focus on design solutions and visual styles that most fully embody that vision.

Just do it

Fear of the blank page can be daunting for all of us. Sometimes, just pushing past that fear and starting to sketch can get the juices flowing. Our designers make sure to have a tablet, sketchpad, or whiteboard easily accessible at all times, and we don’t wait until we have a fully formed thought or idea to use them. We may look like we have a brilliant idea in our heads as we approach the whiteboard, but often those few short steps aren’t where the thinking actually happens - the ideas start to come only after we draw the first few rectangles. There’s something special about the process of sketching - even jotting down some really bad ideas helps us learn about the tensions on the problem and gets us closer to a workable solution. (See Bill Buxton's Sketching User Experiences for a fantastic exploration of the idea that the act of sketching is integral to ideation and design problem solving.)

Continue reading...

Blending Agile and UCD at CHIFOO

The Computer-Human Interaction Forum of Oregon (CHIFOO) hosted Lane Halley and Jeff Patton for a talk and workshop on blending agile practices and user-centered design. On Wednesday night, May 6th, Lane and Jeff presented a talk titled “Making Sense of User-Centered Design and Agile.” Thursday, May 7th, Lane and Jeff taught a full-day workshop titled “All Together Now: Blending Interaction Design and Agile Development Techniques.”

The slides from the May 6th talk are available on SlideShare. Pictures of the May 7th workshop are available on Flickr.

Continue reading...

To test, or not to test? You have more than two options

Just as every author needs an editor and every engineer's code needs QA, every designer's work can benefit from evaluation. Does it surprise you that I'm saying this? As UIE's Christine Perfetti once pointed out to me in an interview, Cooper is better known for advocating up-front research, effective process, and skilled designers than for promoting the value of usability testing and other evaluation techniques. It's true that given a limited budget-which most people have, these days-we think investing in these early-stage activities yields greater value. That said, evaluation is so important that every design project at Cooper has evaluation techniques built in. When, how, and how often we evaluate depends on the nature of the project.

Continue reading...

A good design critique

How do you thoroughly critique a design without crucifying the designer? What are ways of critiquing that result in better designs, rather than defensive justifications?

Scott Berkun explores a model for design critique in a detailed post, but I'm interested in the little stuff that works for your design team in day-to-day practice.

At Cooper, our teams often work together for a year or more. It is important for us to create a dynamic of cooperation, but great design often happens when we push on assumptions and challenge the first iteration. We want to encourage this critique, but make sure that it doesn't derail the meeting.

Why is that good?

It's pretty common to hear a skeptical Cooper designer begin a critique with some variant of the question, "Why is that good?" Many ways to express disagreement have negative effects on the meeting or relationship. "That won’t work because," or "But what about." These tend to bring momentum to a halt. Designers must stop, defend their ideas, or chase objections.

As anyone who has faced a blank whiteboard knows, once the ink gets flowing it is important to run with it and see where the idea goes. Communication strategies of design partners can enhance or detract from this process. By asking to see the goodness, we focus on enlightenment, encouraging our partner to help us see what they see. Also, asking an open-ended question is an acceptably naïve way of pushing your design partner to step up and show you what is going on in their mind.

At the core, we want our teams to feel comfortable in expressing healthy disagreement, and to focus on clarifying rather than justifying.

What are ways that your team has developed to critique design while maintaining harmony on the team?

What do you think? Join the conversation in Comments

Whither Clippy?

Clippy came to mind when I was in Japan, a nation and culture richly populated with animated characters. On every surface, there are characters — talking penguins, inflatable dogs, instructive manga characters — and their cumulative presence seems to make the environment more engaging and friendly.

I saw this little guy in the UI of a Nintendo DS when I toured ATR, the Advanced Telecommunications Research Institute in Kyoto.

I don't know what he's saying, but he sure is cute.

So, after my trip to Japan, I'm worried that we've taken the wrong lesson from the shortcomings of Clippy. There must be an appropriate a place for characters in interactive systems that are not simply games — not all interactive systems, but some, maybe?

My question: Can anyone point me to some good implementations of characters in non-game software? Or recommend some best practices?

What do you think? Join the conversation in Comments

Why I hate the substitute spinning instructor, and what the heck that has to do with design

As interaction designers, it’s natural for us to pick apart the failings or successes of every website and electronic device we see and apply that knowledge to our work. But every day, we’re faced with countless products, services, and even people that provide us with positive or negative experiences. Gaining an understanding of what makes each of those non-digital experiences good or bad also exposes patterns and commonalities that we can draw upon when it’s time to design.

Not long ago I found myself growing increasingly annoyed and frustrated with a substitute instructor for my regular spinning class at the gym. To keep myself from leaping off my bicycle and strangling her, I spent the class analyzing what worked so well with my regular instructor’s approach, and what made me so crazy with the substitute’s.

Setting aside the fact that the regular instructor is a Brazilian Adonis and the sub was a perky size 0 cheerleader type, I identified that the substantive distinctions in their styles were tone and frequency of communication. My Adonis is the strong silent type; he speaks only as much as is necessary to guide our action on the bikes, using a tone that conveys respect: You have shown up for class, and are therefore self-motivated, driven, and capable of pushing yourselves to your appropriate limits. He lays out the plan for the training, cranks up the music, and lets us get in the zone. The sub, on the other hand, yammered over the music non-stop throughout the class, reminding us to breathe (gee, thanks!), stressing that we came here for a workout, and regularly demanding that we give her 10% more. Excuse me? I don’t even like you - I’m not giving YOU 10% more of anything!

As luck would have it, back here at the studio, I’m working on a business application that will be used primarily by workers who are relatively new to the job. (Advancement at my client’s company happens quickly, so just as users get good at what they’re doing, they get promoted and no longer have to perform the work that the software supports.) Knowing that the application we’re designing will need to guide users through their work, and keeping in mind my recent experiences at the gym, I made sure to ask users about the qualities they appreciated most in their human mentors. My design partners and I then took care to embody those personality traits in the visual and interaction design of the application. (For a nice list of factors that affect the perceived personality of an application, see Martijn van Welie's blog post Brand behavior in interaction.)

So the next time you find yourself particularly delighted or disgruntled as you move about your daily life, challenge yourself to figure out why — it just might help you hone your design skills.

What do you think? Join the conversation in Comments

Brainstorm without snapping branches

Ah, the rumble of an impending brainstorm. In some organizations, it is a prized tool that puts a sparkle in the eye and wind in the sails. In others, it's a feared term and a necessary evil.

And what exactly is a brainstorm anyway? Many disciplines, whether design, business, technology, or otherwise, have their own brainstorming voodoo, though it can seem like this vision is transported via secret handshakes and smoke signals. Everyone knows something is going on, but no one really articulates what. After all, it's really just the time when we get together and come up with stuff (hopefully of the clever variety), right?

I've found myself brainstorming to many tunes over the years, from industrial design rock-fests to a modern interaction design synthpop, a visual design rumba to a change management cha-cha. And this often little-understood microcosm of society has an uncanny way of pushing buttons and exposing long-held beliefs right when they're on the way to the chopping block. It's the place where the skeletons come out, and can remain fraught with quicksand no matter how long you've been doing it.

So why bother? Sure, they can be challenging. But they are also where the magic happens. Where the mish-mash of life experiences come together to create something from nothing. And the principles that make this magic happen don't change.

This is what I've learned along the way...

Be present — Put it away.

A single person checking their email or starring out the window can have a ripple effect on the whole room. This is your time! The time for the great idea. Be there for it.

Be the dynamic — Say it, show it, repeat.

Make explicit the desired group dynamic alongside the goals for the session outcome. Discuss the goals with the room, get agreement, and then keep those goals in sight. While focusing on a new idea, people can easily forget themselves and relax into old (sometimes less constructive) habits; it's only human. So stick up those dynamic and outcome goals (to your forehead if you have to) as an ever-present target.

Be a good citizen — Build a community with your bricks.

A highly-functioning brainstorm participant is both an individual contributor and advocate for the group at the same time. Each of their ideas serves a dual purpose - to contribute to the output of the session, as well as to act as a springboard for someone else's next idea. Do both with intention.

Be positive — See the good, and say so (and don't throw those bricks.)

See the good in your own ideas, and articulate the positive in the ideas of others. This is how the momentum gets started, and how to keep it going. Make "Yes, and also..." your favorite phrase.

Be safe — Keep the wolf at bay.

Ask clarifying questions if you need to, but keep those ideas away from judgment or analysis; Try setting aside a separate time for processing later. One wacky idea is all it takes to ignite the twinkle of the idea in someone's eye. Analysis and judgment are the big-idea-stealers in disguise, and guarantee discord will break the momentum before you ever get to the REALLY BIG idea.

Be flexible — Keep the energy up.

Once you have the momentum going, be flexible and go with the flow. And don't forget to pause for the occasional office Nerf gun battle if you're stuck. (You do have an office Nerf gun, don't you?) Sometimes there's nothing better to shake loose those brain cells or energize the room than a little silliness and a good laugh.

So what's the result of all this? You're ready to...

Be highly generative — Have more and better ideas, and have them fast!

Brainstorming is as much about intuition and free-association as it is about brainpower or knowledge. Speed and quantity help break through the 'low-hanging fruit' ideas, and get the brain-juice flowing. The result? You push through to new combinations and insights that will surprise and enlighten you, pointing the way. You'll get to better places than you ever thought you'd go, and I bet you'll win the day.

So what brainstorming voodoo have you picked up along the way? What works for you? What doesn't?

What do you think? Join the conversation in Comments

Does your persona eat twinkies?

I recently stumbled across an article about personas written by Andrea Wiggins late last year in Boxes and Arrows. Wiggins does a nice job talking about how personas can help the design and development process, and some approaches for creating a good persona set. But what really gave me pause was the title: “Building a Data-Backed Persona.” Data-backed? Wait a minute…is there any other kind?

Continue reading...

"Wandering" can be productive during user interviews

Recently, a client who was observing us perform stakeholder interviews made a casual off-hand remark at the end of the day that the interviews had "wandered around a bit." We had explained how our interviews are less survey-driven, and more ethnographic in style, but it's often hard for the uninitiated to see the immediate value of an ethnographic type approach to interviewing, especially when it results in circuitous answers. We were particularly happy with the wandering of our interviews, which had produced visceral clarity which could never have been delivered with an overly structured interview. For example, hearing that the back-end systems are "dog shit" provides an additional layer of information than simply hearing that they're "dated" or "inadequate."

Tommy Stinson, Strategic Director at Cheskin, another Bay Area innovation engine recently blogged: "The goal of the discussion isn't to just get the participant's 'take' on the topic (at least it's not limited to that). The goal is to understand this person (or people) and their culture - the 'webs of significance.'"

We work from structured interview instruments, but as a journalist friend of mine is fond of saying, "the best quotes happen when the tape stops rolling." When we leave the scripted interview and allow someone to lead the interview themselves, often things which we couldn't predict or identify are revealed — and, in some cases, new topic areas can be added to the instrument as a result. Of course it's important to return to the script to hit all of the main questions we have, but it is equally useful and important to allow an interview subject to lead a little, to give them enough time and latitude to wander into areas which are not on the map.

What do you think? Join the conversation in Comments

Let the walls do the talking

Many of the Cooperistas were out traveling today, so I had the opportunity to snoop undisturbed. I thought it would be fun to find out a little more about what goes on in the office and to practice an aspect of our research approach while I was at it.

Observation of the environment in which people work is important to gain a well-rounded understanding of the people we design for. The objects and information that people surround themselves with, the character of their workspaces, and the way in which people interact with each other in those spaces all provide important clues about needs, priorities, preferences, and goals. When we talk in someone's personal workspace, we often intuitively pick up on facets that would not come up in conversation.

I snapped some photos of a few curiosities, and wrote down my initial thoughts about what these artifacts say about their owners. I also recorded the questions I would have asked of them if they were around to answer.

I discovered that there are a variety of computer mice around here. At first glance, it looks like people have chosen their mouse setup based on form, control type, and the feel that they prefer.

Questions:
What do you use your computer for? Did you specifically choose this mouse? Why or why not? What other digital products or peripherals do you own? Tell me about your favorite one, and why you like it. Any that you don’t like? Why?

Continue reading...

Bringing sanity to swat-team design projects

In a perfect world, interaction design would begin when a product was still just a twinkle in a venture capitalist’s eye. In reality, many software products make it all the way through the development cycle with little thought to the users’ experience, and when executives, sales people, or QA testers finally get their hands on the functioning product and start sounding the alarm bells, interaction designers are brought in to clean up the mess. With increasing demand for design “swat teams” to rescue fully developed but flawed software that is scheduled to ship within months or even weeks, the critical question becomes: how can you avoid getting caught up in the chaos that frequently permeates “crisis-mode” engagements?

Continue reading...

How we use Fireworks

In our training courses, we're frequently asked what tools we use. The answer is pretty simple. While we might use Photoshop for heavy photo manipulation or break out Illustrator for the odd diagram or visualization, we've come to love Adobe Fireworks for designing screen-based interfaces and illustrating scenarios.

Recently, Adobe asked us to share some of our Fireworks techniques with the user community. As a result, we worked with them to create this short video about how our interaction designers and visual designers worked together on a recent project for GoldMail.

If you want to get more in depth with Fireworks, you can read a more thorough article about specific techniques that I recently wrote on Adobe's developer center.

What do you think? Join the conversation in Comments

Using jigs when rendering screens

As part of most Cooper projects we create a visual styleguide that details all of the visual elements of the design. Additionally, we create detailed scenario renderings to illustrate the behaviors of the design. While the visual styleguide is the source of record for precise measurements, it is great if the detailed scenario renderings can follow the styleguide exactly. I've come up with a technique that I use to verify and correct the accuracy of my renderings in a quick, visual way.

When working with wood, it is very common to use a jig (a device for guiding a tool) to ensure accurate repeatable results. This same technique can be applied rendering screens; allowing you to easily check the position of design elements, and correct them as needed. The easiest way to explain this is to walk through an example.

Continue reading...

Whiteboardability: How to make process diagrams memorable

Have you ever been in a design review where instead of talking about the proposed solution you spend half the time revisiting what the user is trying to accomplish in the first place? Keeping the human-centered models of the processes that lie behind your solution fresh in the minds of stakeholders (and designers) can prevent this unwanted rehashing. One way to ensure this is to create a diagram and give it qualities that make it simple enough and memorable enough so that, on a dime, you can whip out a dry-erase pen and sketch it out as a reminder.

I like to call that collection of qualities whiteboardability. It won't work with extremely complex business processes, but for simpler processes or most consumer domains, it works well.

Continue reading...

About Face 3: Foreword

The industrial age is over. Manufacturing, the primary economic driver of the past 175 years, no longer dominates. While manufacturing is bigger than ever, it has lost its leadership to digital technology, and software now dominates our economy. We have moved from atoms to bits. We are now in the postindustrial age.

More and more products have software in them. My stove has a microchip in it to manage the lights, fan, and oven temperature. When the deliveryman has me sign for a package, it's on a computer, not a pad of paper. When I shop for a car, I am really shopping for a navigation system.

More and more businesses are utterly dependent on software, and not just the obvious ones like Amazon.com and Microsoft. Thousands of companies of all sizes that provide products and services across the spectrum of commerce use software in every facet of their operations, management, planning, and sales. The back-office systems that run big companies are all software systems. Hiring and human resource management, investment and arbitrage, purchasing and supply chain management, point-of-sale, operations, and decision support are all pure software systems these days. And the Web dominates all sales and marketing. Live humans are no longer the front line of businesses. Software plays that role instead. Vendors, customers, colleagues, and employees all communicate with companies via software or software-mediated paths.

Continue reading...

Interview tips: The critical first five minutes

Goal-Directed Design necessarily involves first-hand research with real-world users. Whether these interviews last 30 minutes or two hours, the first few minutes of discussion are vital to establishing rapport with your participant.

Outside of celebrities and politicians, few people are practiced at giving interviews. And while participants are almost always willing to help as best as they can, there may be some unspoken questions troubling them before an interview begins. This article offers a list of common topics that proactively address these questions and make participants feel at ease.

Continue reading...

Three books to spark your design thinking

For the past several months, I've been working with Alan Cooper and Robert Reimann on the latest version of About Face, Alan's classic book on interface and interaction design. One of the major objectives with this new third edition has been to bring the book up to date with current conversations about the design of interactive products, which has been a great excuse for me to dig into the growing body of literature on the subject.

In particular, the last year saw the publication of three very worthwhile tomes written explicitly on the subject of interaction design. (Those of you who have been in the field for a while probably share my shock to have such a wealth of discourse.) Despite the almost comic similarity in their titles, the three books each cover different ground but are really quite complementary. These three books, along with Mullet and Sano's Designing Visual Interfaces and About Face (naturally) would be a fantastic curriculum for someone interested in interaction design.

Continue reading...

Taking Personas Too Far

I don't have to tell you that at Cooper, we love personas—how could we not?—and we're glad to see continued excitement about them. That said, although personas are essential design tools, we think some people may be losing sight of the fact that they're just tools, and tools with a specific purpose, at that. Lately, we've been seeing a lot of gold-plated hammers—unnecessarily elaborate communication about personas—and some fundamental misunderstandings about the relationships among research, personas, and scenarios.

Continue reading...

Goal-Directed Service Design

Most people think of Goal-Directed Design techniques as focused on product design, but they work equally well for services. A service is comprised of the various "touchpoints" between a customer and a business. Touchpoints include public-facing systems such as web sites and web-enabled software, but can include other channels as well, such as brick-and-mortar stores, points of sale, interactive voice response systems, email and postal mail, too.

A service model best fits offerings that are intangible, distributed in space, or play out over a length of time, especially on a routine basis. Some obvious examples include: electricity, hotels, mobile phone service, or even a government. The touchpoints you design as part of your service are critical to the user's understanding of your brand. Increasingly, many touchpoints are interactive systems rather than human contact, so paying careful attention to the design of these things from the user's goals is vital.

Continue reading...

Six Sigma and Goal-Directed Design

If you work for a large company, or have one as a client, you've probably heard about Six Sigma. Many companies report great success using Six Sigma initiatives to improve the quality of their products and services, measured by increased customer satisfaction and millions of dollars saved.

At the core, Six Sigma and Goal-Directed design share some of the same values and provide tools to solve some of the same problems. Six Sigma seeks to understand and quantify the functions that matter most to users and provide improvements in those most leveraged areas. Goal-Directed design seeks to delight users and increase loyalty by creating products that are powerful and pleasurable to use. Six Sigma identifies and tracks faults "critical to quality" (CTQs). Goal-Directed design uses personas and goals to define and communicate interaction design decisions.

Continue reading...

Early and Often: How to Avoid the Design Revision Death Spiral

One lesson we've learned over the past several years here at Cooper is that on the vast majority of our projects, intimate client collaboration is a critical ingredient for success. This is a lesson that we have sometimes learned the hard way; collaboration can be messy, unpredictable and has often forced us to compromise what we thought was a supremely clear and elegant vision. Despite these growing pains, we've learned to embrace the unpredictability and compromise; through well-managed client collaboration, our designs are stronger and are more likely to serve our clients' needs and satisfy the goals of end users.

Continue reading...

The Web, Information Architecture, and Interaction Design

The impact of digital technology—from the Web to mobile phones to the silicon in your toaster—has meant a proliferation of terms for the work people do to define digital products and services. People talk about "customer experience," "user-centered design," and so forth. This talk can confuse even people who do that work for a living, as you often find different people using different terms to mean the same thing—or using the same term to mean very different things!

Many people say that this reflects a breakdown of disciplinary distinctions in designing for the new world of the digital. "It's all just design." I disagree. I see a few major types of problems in the digital world, and I believe that each of these has its own set of tools and methods that work well to solve that type of problem.

Continue reading...

The Origin of Personas

The Inmates Are Running the Asylum, published in 1998, introduced the use of personas as a practical interaction design tool. Based on the single-chapter discussion in that book, personas rapidly gained popularity in the software industry due to their unusual power and effectiveness. Had personas been developed in the laboratory, the full story of how they came to be would have been published long ago, but since their use developed over many years in both my practice as a software inventor and architectural consultant and the consulting work of Cooper designers, that is not the case. Since Inmates was published, many people have asked for the history of Cooper personas, and here it is.

In their book, Fire in the Valley, authors Paul Freiberger and Mike Swaine, credit me with writing the “first serious business software for microcomputers” as far back as 1975. Like so much software of the time, it was terribly hard to use, and its real power was in demonstrating that making software easy to use was harder than everyone thought. Despite my commitment to making software more user-friendly, it wasn’t until 1983 and about 15 major business and personal applications later that I began to develop a more effective approach.

Continue reading...

Critic to Creator: Recognizing Good Design

Someone always asks the question, and I am never ready for it.

"So, what products out there are well-designed?"

As an interaction designer, I learn about users and design a product that helps them meet their goals—one that is tailored to the way they work. Yet this question can still stump me. I am not alone: all too often, people in our field focus so much on pointing out the egregious interaction design mistakes that make it to market, we forget to pay attention to the good design that exists. Not only does it make our profession look bad if we are always complaining, but it also makes us less effective. How can we create good products if we can only articulate what “bad” is?

Continue reading...

Design Research: Why You Need it

Ever notice how often a product that makes a huge splash at tradeshows fizzles in the marketplace? The story goes like this: Product is introduced at show to much fanfare. News media gives Product lots of press, and consumers everywhere express interest in Product's features and capabilities. Product hits store shelves…and stays there. Some early adopters purchase Product, but it never penetrates into mass consumer markets.

What went wrong? Market research clearly identified potential dollars in target markets just waiting to spend money on the new product. So why did it fail?

Continue reading...

Getting from Research to Personas: Harnessing the Power of Data

The usefulness of personas in defining and designing interactive products has become more widely accepted in the last few years, but a lack of published information has, unfortunately, left room for a lot of misconceptions about how personas are created, and about what information actually comprises a persona. Although space does not permit a full treatment of persona creation in this article, I hope to highlight a few essential points.

Continue reading...

Interface Design as a Life or Death Proposition

In the mid-1980's, a team of physicians, lawyers, and public health experts conducted a lengthy study of the nature and causes of medical errors. They published their findings, entitled "Incidence of adverse events and negligence in hospitalized patients," in the New England Journal of Medicine in 1991.[1] Their research indicated that "there is a substantial amount of injury to patients from medical management, and many injuries are the result of substandard care." While the industry evaluations and renovations sparked by these findings have taken effect, physicians and clinicians have simultaneously adopted more sophisticated technologies to provide more accurate and efficient care. [2]

Continue reading...

In Telematics, No Technology is a Panacea

The buzz in the telematics industry lately is centered around why it's not living up to expectations. Ford and Qualcomm recently ended their multi-million dollar telematics joint venture called Wingcast, which was one of the major players in the industry. Two years ago, projections for the telematics market in 2010 were in the $40 billion range; newer studies now put that amount closer to $20 billion. Telematics suppliers are cutting staff, and automotive manufacturers are scaling back telematics initiatives. So what's the problem?

Continue reading...

Turning Requirements into Product Definition

In his newsletter article last month, Ryan Olshavsky outlined an overall process for defining new products and services, taking a look at the start of that process. But how do you get from understanding your users to a vision for an innovative product which will appeal to them?

Continue reading...

Bridging the Gap with Requirements Definition

Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn't click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn't flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there's a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.

Continue reading...

Perfecting Your Personas

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design.

Continue reading...

So You Want To Be An Interaction Designer

We get a lot of email from students and usability professionals asking how one goes about becoming an interaction designer, and what background one needs to get into the field. What are good interaction design programs? What real-world skills and experience are required? What, exactly, do interaction designers do on a day-to-day basis?

Continue reading...

The Perils of Prototyping

Which is harder to change: a program with 1000 lines of code or a 1000 square foot slab of concrete? The concrete is ten inches thick and has steel reinforcing rods criss-crossing within it. Every cubic foot of it weighs almost 100 pounds. The software has almost no physical existence at all. It weighs nothing. It consumes no space. A few microamps and those bits flip from zero to one without a second glance. The answer to my question seems a simple one, doesn't it?

Which is the best medium for designing software: Visual Basic or a sharp pencil and a couple of sheets of paper? Visual Basic is a powerful, flexible integrated development environment. It is on its way to becoming the most widely used language ever. It has won every industry award there is. Paper is not interactive. Paper offers no palette of pre-made controls. It just lays there and you have to do all of the work. The answer to my question seems a simple one, doesn't it?

Continue reading...