Four seconds of silence

Here’s a quick tip for you as you conduct your goal-directed interviews with users and potential users: Leave a four-second pause after your interviewee pauses their response, allowing them to add more information or additional detail.

This is hard to do. In ordinary conversation, people will often step in and fill these silences. Especially with a stranger, we don’t want to leave the conversation “hanging,” preferring instead to offer up some response or reflection on what the other has said.

But an interview is not a cocktail conversation. The interviewer is trying to get as complete a picture as he or she can of the user’s thoughts. To help do this, we want to give them that room to think about what they’ve just said and append as necessary.

Continue reading...

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...

Innovation Games for your Agile UX Toolbox

A few months ago, Luke Hohmann visited Cooper to teach a special session of his Innovation Games class. Alan Cooper, Steve Calde, Tim McCoy, Jeff Patton and I and spent two days with Luke learning about the games and practicing how to apply them in different situations. Since the class, I’ve often found myself reflecting on what I learned. I’d like to share with you how I’ve adapted some of the techniques in my User Experience consulting practice:

• I look for opportunities to make all my meetings more engaging and participatory. A collaborative process generates a different kind of results than a meeting run by a single facilitator. When people work together to create an artifact (as you do in “Spider Web,” “Start Your Day”, and several other games) they are more engaged in the conversation and it’s easier to get participation from the entire group. You also have a useful record of what you talked about for future reference. My meeting room “kit” now contains large newsprint pads, sticky notes and thick black markers so we can jump into an Innovation Game at any time it becomes relevant.
• At our ChiFoo workshop, Jeff Patton and I used a variation of “Speedboat” to guide a group discussion about blending Agile and User Experience (UX) techniques. We asked people to tell us what “anchors drag them down” and what “winds support them.” You can see a picture of the results on flickr. We budgeted about 45 minutes for the exercise, and people wanted to keep going well into lunch. The process of sharing our thoughts visually and verbally created a sense of community and shared direction in the room that surprised and pleased me.
  
• I found the Innovation Game role of “observer” and the process of recording one observation per index card useful in another context. While teaching interviewing skills at Atomic Object. We grouped the interviewers in pairs (main interviewer, backup interviewer) and had the rest of the people sit behind the interview subject and act as observers, taking notes on index cards, one observation per card. After the interview, we did a group debrief of the observations and found that we had excellent coverage of what we’d learned. Even though none of the student interviewers caught all the details, as a group they covered everything. Another benefit; we quickly reached a shared understanding of the key insights from the interviews. I can imagine this would be equally as useful during usability testing, either behind glass or with silent observers.
• And, for my personal and professional planning, I’ve found “Remember the Future” valuable to help me clearly articulate my long term objectives, and the specific measurable steps I need to follow to accomplish them.

Thanks again, Luke, for a memorable class, and some useful additions to my UX toolkit! For more information about the Innovation Games event, please see the Cooper Journal post about the event, and the full set of photos on flickr.

 

What do you think? Join the conversation in Comments

Beyond trust

At Cooper, we spend a considerable amount of time understanding the experience requirements of the products that we're designing. Our client stakeholders often request a design that our users will react to as feeling simple, intuitive, innovative, and so on. In many cases the products we're asked to design must display a sense of trust.

Why is trust good?

Trust can play an important role in the successful adoption of a product. For example, in data backup and management, if the software does not give a user, such as a backup administrator, the confidence that his data is safe and securely managed then he's unlikely to want to use, or switch to, this software. Especially, when considering that his job is on the line in cases where servers go down and critical data could be lost. Likewise, for online banking websites, customers want to know that their personal information is securely housed and not at risk of being stolen.

How do we make software that appears trustworthy?

All aspects of design and technology contribute to improving a product's trustworthiness whether it be through the visual presentation, the tone of content, the accurate and clear communication of data, or the brand awareness of a company or product. Ultimately, when considering visual design it's our task to create a visual language that appears professional, high in quality, and appropriate to the user's expectations. For content and data, it should be clear, concise, error-free and accurate. Finally, repeated interactions with brands can build trust over time if consistent, dependable, and memorable.

When trust can be bad

Right now you might be wondering, "Trust can be bad?" You've got a point. No client has ever asked me to design a software application, website, or device that's intended to be untrustworthy. But, our continuing reliance on complex information systems could lead us down the path of blindly relying on data, even when we don't fully understand that data. Trust must always be cultivated in users, but too much trust, like too much of anything, can be a bad thing.

Consider the financial meltdown. I don't pretend to fully understand what has happened, who's to blame, and how it could have been prevented. What seems clear is that many of those responsible were only looking out for themselves. Michael Lewis, author of Liar's Poker, discusses this issue that began decades ago in "The End of Wall Street's Boom,"

The shareholders who financed the risks had no real understanding of what the risk takers were doing, and as the risk-taking grew ever more complex, their understanding diminished. The moment Salomon Brothers demonstrated the potential gains to be had by the investment bank as public corporation, the psychological foundations of Wall Street shifted from trust to blind faith.

In assuming that a system is correct, users assume that what they are doing is correct, ethical and in the best interests of everyone. In doing so, they (perhaps unconsciously) absolve themselves of accountability. It is incumbent on the system to ensure that users are fully aware of their accountability, so the system must leave no doubt about that fact.

In Jerome Groopman's How Doctors Think, he discusses a surgical protocol for cardiac tamponade, a condition in which "fluid has accumulated around the heart and was compressing it." In the story, Dr. James Lock retells of how a standard procedure, where a needle is used to remove the fluid, had been nearly fatal for a young patient,

"Why do you stick the needle under the xiphoid?" Lock asked. I paused. "Because that was how my teachers taught me in my training."

"And why do you think your teachers taught you the way they did?" Lock asked.

"Because that's how they were taught."

By not fully understanding the procedure or its history, the medical staff ceased to improve the procedure and more critically put the patient at great risk.

When viewing complex systems, users should not only understand data but, when necessary, ascertain its origin. Consider the frequency with which patients receive the wrong medication in healthcare environments. Relying too much on a system could give a nurse the false sense that she has administered the correct medication when in actual fact, a pharmacist prescribed the wrong dosage in her computer.

So what's the solution?

The solution is to dive deep into the research problem and fully understand the trust need from your stakeholders and users. Regarding the stated examples, users should be made to feel like the software they're using is reliable and dependable. But most of all, users should understand the system, be accountable for managing it, and be empowered to change it.

 

What do you think? Join the conversation in Comments

Meeting the expectations of the design

At Cooper, we’ve historically advocated a clear and explicit separation of interaction design and software development efforts. Underlying this position is the assertion that the job of interaction designers is to serve as user advocates. We approach the design problem not by asking “What can we deliver?” but “What do people desire?”

We’re guarding against the urge to focus on the development and delivery of software, hardware, and services before we understand its value to the humans using the system. By no means does that suggest our designs should ignore business and technological factors, only that our designs should be influenced primarily by our the motivations of the users represented by our personas.

The design must meet the needs of its users, and it follows that the product’s creators (designers, business folks, developers, etc.) deliver a product that meets the expectations of the design.

But how to design so that those expectations can be met? It’s a delicate balance. Ideally, there is a healthy interplay of possibilities and limits between the business factors, technology issues, and design motivations. Each group shares the goal of delivering the best product possible with the time, budget, and expertise available.

Here are some ways to keep a user-centered focus without losing sight of the factors that influence development:

Understand the business situation

Get a clear sense of the breadth of the design mandate: Is management pulling out all the stops to create a category-killer, or have they set a firm cap on the time and resources available to the project?

Know your medium (but not too well)

Understand enough about the technologies underlying the product so you can leverage things it does well without falling into the trap of designing to technical capabilities rather than user needs.

Listen to developers’ concerns and ideas

Recognize that every one of your design decisions impacts the work developers will need to do to implement and support them. Solicit their input on the design’s feasibility and seek their advice on ways to make the design more achievable. Your concern should not be that you’re signing developers up for hard work (after all, solving hard problems is what being a developer is all about)—it’s signing them up for unnecessary hard work.

Don’t concede your personas’ needs to business or technological limitations

If you’ve done your homework, you know what the product needs to do (and not do) to satisfy its users. If technical or business issues are in conflict with a persona’s needs, speak up. Demonstrate the value of your design to business and technology stakeholders to help them see the merits of accommodating the design intention.

Pick your battles

Be comfortable with letting some technology and business considerations trump design ideals. There are situations where a less-perfect standard implementation of one feature means more time to develop a custom feature that truly delights your users. Too many of these is death by a thousand cuts, but everything doesn’t have to be ideal for the things that really matter to be fantastic. The reconciliation of technology, business, and user-centered design is ultimately a business decision. The most fabulous design will never see the light of day if it doesn’t meet business objectives or isn’t technically feasible. By understanding the business and technical landscape, working across disciplines, advocating for your users’ needs, and knowing when to compromise, you can produce successful designs—successful because they meet the needs of users and the needs of developers and business stakeholders.

 

What do you think? Join the conversation in Comments

The 5 habits of highly effective project teams

Here at Cooper, we’re pretty well known for our holistic and methodical approach to design, but don’t let that fool you - when the situation calls for it, we’re more than happy to get all “mavericky” with our clients and provide some good old fashioned ad-hoc consulting.

For example, I was recently asked to provide management support to a client who is in the midst of implementing a Cooper re-design of their robust web application. As I immersed myself in the project, I was quickly reminded of my previous life as a project manager and business analyst at a large software company, and how easy it is to fall into the many efficiency traps that often permeate large-scale development projects.

Over the course of my recent engagement, I identified several critical success factors for effective project teams, and some specific things that both project managers and team members can do to ensure project success.

Continue reading...

Joe six pack is not a useful archetype

A good persona (or user archetype) is based on research and is specific, memorable and includes actionable information. Often, I’ve seen people give them descriptive names that leverage often-heard phrases, like “Nora the newbie” or “Joe Helpdesk.”

The term “Joe Six Pack” has frequently been used in the 2008 presidential campaign. This is a good example of how using “soundbite” names for your persona work against your need for a specific design target that keeps everyone on the team focused on the same idea.

In NPR’s Morning Edition program “York Voters Untangle Rhetoric On Race” Renee Montagne, Steve Inskeep, Michele Norris asked 15 voters from York Pennsylvania what they thought of when they heard the term “Joe Six Pack.” The got a variety of responses:

Continue reading...