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