Recently in Design Category

Earlier this year, America was stunned to hear of the terrible treatment of veterans at the famed Walter Reed medical center. Whatever any of us think of the wars in Iraq and Afghanistan, there is consensus that injured veterans should receive the best possible care.

On the heels of the scandal, President Bush convened a panel of experts, led by Bob Dole and Donna Shalala, to investigate the matter. Their report, released earlier this week, revealed an unexpected surprise. To get inside the problem, the commissioners took an unconventional approach: they assumed the perspective of the patient.

The President made note of this fact at his press conference:

They took a very interesting approach. They took the perspective from the patient, as the patient had to work his way through the hospitals and bureaucracies. "WhiteHouse.gov":http://www.whitehouse.gov/news/releases/2007/07/20070725.html

Charged with investigating a crisis spanning some of the largest bureaucracies in the world, Dole and Shalala led one of the most important pieces of user research done in recent years.

To quote from their final report (PDF):

Our recommendations are few, but they are actionable. They are based on the priorities of patients and families. Essentially, our recommendations hope to accomplish three goals: To serve those injured in the line of duty while defending their nation, to support their recovery and successful rehabilitation and to simplify the sometimes overly complex systems that frustrate some injured service members and their families and impede efficient care.

To see immersive user research succeeding at this level is truly inspiring. Looking closely at its components, it clearly offers a case study for designers of all variety embarking on large projects in unwieldy organizations.

Reinterpret your mission

The objectives of the project were defined by the White House in an official "Charge to the Commission." Like many project charters, the goals were defined in the language of the client. The White House uses words like "effectiveness" and "coordination." They want to know how they can provide "high-quality" service.

But what do all of these buzzwords mean? What can you do to really dig into the problem if your starting point is this kind of lingo?

You reinterpret your objective.

It is almost cliche\xC3\xC5 now to find examples of a wounded Marine having initially been treated by a Navy Corpsman, find himself medevac\x82\xC4\xF4ed by an Army helicopter to undergo emergency surgery at an Air Force Theater Hospital. Air Force LtCol Andrew E. Moore

To put it another way, the individual soldier, sailor, or marine doesn't care what uniform the doctor struggling to save his or her life happens to be wearing.

Beginning with this premise, the Commissioners turned their charge on its head. Their mission wasn't to assess the organizations and their "effectiveness," it was to assess the whole experience of soldiers as they interact with a number of sprawling organizations.

Choose your research methods carefully

In a few short months, the nine members of the Commission visited a variety of treatment facilities, met with service members and their families, and distributed a nation-wide survey that received a thirty-percent response rate. In addition to employing their own methods and relying on the unique strengths of their team, they also evaluated the findings of earlier commissions.

When pressed for time, it is essential to use carefully targeted techniques to gather new information, while also looking to old assessments for additional information. Just because the last set of research findings were left in a storage room doesn't mean they can't offer solutions to current problems.

Redefine the problem

With the experience of wounded soldiers as their starting point, the Commissioners identified and defined where the system was failing and where it was succeeding.

A significant finding was that the first touch-point of a wounded service member's experience was very successful. Individual patients were impressed by the battlefield medicine they received. The military was also pleased by the success rate of battlefield medicine, and how the speed of evacuation increased the survival numbers of service members with serious injuries.

In the Vietnam era, five out of every eight seriously injured service members survived; today, seven out of eight survive, many with injuries that in previous wars would have been fatal. This is a remarkable record.

So with all this success, where does the problem come from?

From their own experiences with the different stages of a veteran's experience and the direct discussions with patients, the Commissioners concluded that the problem was located where the tectonic plates of bureaucracies collide.

Despite accomplishments in clinical care, problems do occur\x82\xC4\xEEparticularly in handoffs between inpatient and outpatient care and between the two separate DoD and VA health care and disability systems.

By breaking down the individual experiences of wounded service members, the Commissioners were able to separate the good from the bad in the current system. This is often the hardest part of evaluating any system. When the end result is failure, it is easy to call for wholesale change.

We designers are very good at wanting to do a complete redesign, or to make an entirely new product. Instead, the right answer is often to tweak what's wrong with the current structure or product. Incremental change, though less dramatic, is often more effective. The other side of the conservative lesson is that if you are going to call for wholesale change, make sure that you understand every step of the problem and what about each piece is broken.

The solution is in the system

In their report, the Commissioners made a number of recommendations ranging in scope. Among their recommendations is a radical shift in the structure of the disability and compensation system.

Only from the perspective of the patient would you see this single piece as the key to unlocking the crisis.

After their survival is assured, injured service members undergo a process to assess whether they can return to military service. If they must be discharged of their duties, military doctors assign them a rating to determine what level of benefits they receive.

Now a veteran, the patient must choose whether to receive their benefit from Veterans Affairs or from the Department of Defense. With little or no information, they are asked to immediately evaluate which package is better and make a choice.

It is this choice the Commissioners want to eliminate. This single bureaucratic hurdle is where too many veterans trip. At no fault of their own, they often choose poorly and are blocked from the best care possible for the rest of their lives.

Explain how your solution impacts the bottom line

To sell this radical solution, Shalala argued in the language of the bottom line. By rethinking the system, the government would eliminate a large portion of its overhead. The improvement in user experience could also result in dramatic cost savings that could then be reinvested elsewhere.

Other recommendations, such as early treatment of brain injuries, could also be funded by this restructuring.

Learning from this process

Whether the report's recommendations will be implemented is still an open question. Some have criticized the report for not investigating the role the Bush administration played in setting the stage for this crisis.

Regardless, there is much to learn from the process that Dole and Shalala used to complete the Commission's work. They reinterpreted their mission by assuming the perspective of the user instead of the organization. Focussed research enabled them to then clearly define the nature and source of the problem. The recommended solutions emerged from this clear understanding of the entire system and how changes to key pieces could make the most difference.

This process mirrors the ideal strategy and research phase of the design process, and we designers can learn a valuable lesson: If focussing on user experience can uncover solutions to the most intractable problems of large government bureaucracies, surely it is the right approach for our clients.

The mobile web isn't coming, it is already here. I use the web on my cell phone every day to check headlines from the New York Times, use Google Maps to get directions, check e-mail, and post to Twitter.

With the explosion in mobile web applications comes a new problem of domain name conventions. To solve this problem, a new top level domain (TLD) has been created. You can now buy your domain all over again as a .mobi to supplement your .com. But what if they don't match?

This issue hit home with me tonight as I logged in to Bank of America and learned that they now offer mobile access to banking information. This presents the challenges of the mobile web in stark relief. Here you have data that you want to access on the go (your current checking account balance) paired with information that you don't want to leak out at all costs (your checking account number).

As a user, I want the convenience of mobile access to secure data to be ensured with absolute trust or else it isn't worth the risk. I clicked to "learn more" and was shocked by what I saw. Instead of directing me to visit a familiar bankofamerica domain, it instructed me to give secret account information to www.bofa.mobi.

I am a savvy web user who shops online without fear of credit card theft and complete most of my banking transactions online. Yet this domain name switcheroo made me uncomfortable.

bofa. Really?

This got me thinking about the other mobile sites I visit. To see The New York Times on my phone I visit m.nytimes.com. To find picture from my friends I go to m.flickr.com. The same m. approach is also used at YouTube, Yelp, and Twitter.

.mobi is sold as a domain designed exclusively for the mobile web but companies need to be careful with this new TLD. Bank of America undermined the trust I have in their web site by switching domains on me. Visiting bankofamerica.com feels the same as walking into a branch. This is hard-earned trust. bofa.com lacks gravitas, it sounds like a link I would see in my spam folder. Oddly enough, Bank of America appears to also own bankofamerica.mobi. Using m.bankofamerica.com might be more useful to them than throwing money away on .mobi domains.

With the iPhone coming many people seem to think that development of a version of the web exclusively designed for mobile devices is irrelevant. This doesn't seem right to me. First, most mobile users will continue to have devices that are phones first and internet devices second. As more and more "phone" users get web access, it becomes more important, not less, to think about how experiences can be designed for that context. Second, the iPhone itself encourages web development specifically for the iPhone. Apple's Safari web browser is being released for Windows under the pretext that web developers will want to make sure that their web applications work on the iPhone. The explosion of iPhone web apps since the announcement (and before the device is even available) speaks to the need for context in web interactions.

But for all of this to work we can't sacrifice the basics. Trust matters more than anything else. Let's learn from Bank of America's mistake and stick to the conventions. Your domain name is how your visitors know you. Don't confuse them with something else, just stick "m" on the front and go on about your business creating great mobile experiences.

Too often web sites are designed from the top down. The designer surveys organization's identity, ponders the information architecture, and dives right in... to the home page. Looking at sites from YouTube to CNN we learn that there is a better way.

Lately I've been thinking quite a bit about how web designers work together. Most of these collaborations, in my experience, occur informally. A few people get together and start dividing up their work to move a project forward.

But where do I fit in? What skills do I bring to the table? What skills do I want my partners to have?

[Notes from the second day of the UX Intensive]

An effective interview is made of two things:

1. Being a good listener
2. Asking good questions

Listen for subtle cues. Does the interviewee sound authentic? Do I need to create a space for them to fill or are they just talking? Where I can step back and give them a chance to elaborate without prompting?

[Exercise where you speak to someone for two minutes and they can't interrupt. You then do it again in reverse but the interviewer must give a one minute appreciation when the interviewee completes their two minute talk.]

Good questions are designed to get good answers. The goal is to not have to ask any questions at all. You want to get the interviewee to tell their story, not the story you might want them to tell. We want to hear their stories in their words.

Think of your interviews as an opportunity to facilitate story-telling. That's why listening and being careful is so important.

A good question is simple an focussed, yet open ended. It is not leading but helps move things along. It is avoids judgement and assumptions.

Try these techniques:

• Elaborate with examples
• Define terms
• Ask for clarification and detail
• Restate questions
• Answer with a question

If you ask an open-ended question and the interviewee seems to be unsure of where to star, have a couple of specific examples in your back pocket to help them out. Ensure that you and your interviewee are speaking the same language. Don't assume that you know what they mean.

Ask the interviewee to repeat or clarify or elaborate. Avoid jumping ahead. Don't think that your interviewee is saying what you want him or her to say without asking them to clarify.

Prompt them with simple questions. Beware of being annoying but try not to answer with leading statements. Simple question keep the story moving forward.

[Notes from the second day of the UX Intensive]

Research is not about methods. It is about questions and answers, methods are just the means to the ends. Every project is different because every design project has different objective and questions. Don't decide what the methods are before you even look at the questions.

Good research is all about being flexible. Be method-neutral. Don't wield your surveys like a war-hammer, be flexible.

Always remember that people are bad at predicting their own behaviors, good at recalling their behaviors, and bad at focusing on things they don't care about.

Don't ask people to assume that they are doing something that they aren't actually doing.

[Exercise in survey evaluation.]

Try not to structure your questions in a leading manner. Pay attention to how questions might repeat themselves or limit the options. If you don't offer an other option you risk being given false choices from your participants.

The "Other" box can also be very useful in pre-testing. If your users are filling it out in a certain way you can use those responses to inform your final research protocol.

Always know what you are trying to get at with each question. Always refer back to the core questions you are trying to answer with your research.

Always put your interesting questions early on. If it is boring a the beginning your participant is unlikely to finish. This is also why you want to keep your survey as short as possible.

Field Research

Field research is qualitative and contextual. It is about learning what people do while they are doing things in their environment.

ethnography |e\x8C?'n?\xA7gr\x85\xF4f\x83\xEC| noun the scientific description of the customs of individual peoples and cultures. Oxford American Dictionary

You don't need an anthropologist or an ethnographer. You can often just get by with ethnographic approaches.

The important thing is to be creative when it comes to field research. Instead of just going out and watching people, put them work. Give them tools to capture their own experience. Give them a diary or a camera. Use flexible tools and systems that let people communicate their experience to you. Often, handwritten notes are adequate. If you give someone a camera ask them to annotate the images. You want to know why they took the picture, what their thoughts were about the experience while they were having it.

Remote methods are also an opportunity to collect data without requiring your participant to interrupt their experience to give you information. There are a number of different kinds of remote tools

See: Ethnio

Using Ethnio you can interact with the user like they are in a lab without taking them out of their context.

See: MindCanvas

MindCanvas is a collaborative clustering and card sorting tool that structure the exercise like a game.

See: Revelation

Revelation can substitute paper diaries. It is a little bloggie and is set up well for collecting pictures and notes along with special activities and questions you can have your participants do. The advantage to this is that you can track experience over time. This longitudinal approach can be very valuable.

Bring field research into your design process. As you are iterating designs, show your comic storyboards to users and get their feedback. Find out from real people if your prototype will make their lives better.

[Time for a group activity.]

Be creative about how you can use different methods to compliment each-other and feed back into later stages.

[Notes from the first day of the UX Intensive]

Product Evolution > Elevator Pitch > Co-create Concepts > Prioritize

This isn't everything.

• Integration
• Skills
• Technology
• CRM
• Findability
• Navigation
• Etc.

What these four lenses can reveal is information that helps clean up all those others.

Remember: Scope, Customer Value, Definition, and Focus.

Case study time: A financial services firm.

They focussed on business problems to start and then prioritized what they were trying to do. Took all the inputs, excluded what couldn't be solved on the web, and produced an evolution map.

They then did research to find Customer Value. This opened up many ways that the organization could improve the total interaction beyond the web site alone.

They then brought Definition through prototypes and screen designs based on what they found.

[Question Time]

Technical feasibility is a common issue. This is always going to be an issue but if your up-front analysis can estimate correctly it won't drive your project into the ground.

Be aware of outside elements and try to take them into account. A big part of strategy is understanding your organization's drivers.

For all the talk about planning, agile development is inevitably how you will do your actual development. Bring agile principles into your planning. Be iterative. Let your ideas later in the stage take you back to quickie versions of earlier phases.

Keep your strategy documents alive throughout your process. Don't just make these documents and then lock them in a binder to do.

As you make changes the vision will keep you moving in the right direction. Use strategy to hold on to clear reasons that justify your direction.

Sometimes you will need to broaden these techniques but always err on the side of focus.

The point here is to have a shared document that represents your consensus. Avoid creating too many foci.

One way to achieve focus in big groups is to break up into many small groups, like two or three people. Send them out to create the ideas and then come back and discuss, debate, and create something as a group.

Many bosses will tell you that you aren't paid to do this. Remind them that this is the strategic background information needed for good designs. Education upward. Share new things that you've learned. You are building credibility to your boss while educating him or her about user experience practice.

The people who might oppose this need to be convinced of how this kind of work benefits them directly. Map out what drivers motivate your stakeholders and address those as you move forward.

If your boss doesn't like the word user experience then don't use it. Instead use language that your decision makers respond to.

Remember that your boss has a boss. Appeal to what your boss need to do to prove his or her success up the food chain. Listen to what your boss needs and address that.

[Notes from the first day of the UX Intensive]

Think about what you can get for free. Avoid reinventing the wheel. If you need mapping, use an API and build on top of it.

Be stingy with features. Look at Google Docs as an example. They used the 80/20 rule to build for most people while ignoring the edge cases. They did 20% of the functionality for 80% of the people.

Think about feature extensibility. Look at the way that Google Maps has created an ecosystem of unintended uses for your service.

See: Open Innovation by Henry Chesbrough

Look outside your company for innovation that you can bring in to your service.

Relinquishing control to users is hard for organizations but can be a huge opportunity for growth.

Feature Extensibility > Feature Sufficiency > Feature Stinginess > Functionality for Free

These ideas about scope take you to a platform mindset.

1. Create a sufficient solution
2. Create a platform
3. Participate in the web by letting other create valuable services using your platform

Trade-offs are essential to strategy. They create the need for choice and purposefully limit what a company offers. Michael Porter

Trade-offs are very important. You can't mashup Walmart and Prada effectively. There are different needs at play.

Use a product evolution map to stage the product in progressive offerings. Convey the customer and business value at each stage. The web is a try it and see medium. You will always be tweaking so start with what you know will succeed and add more in the next phase to compliment your initial offerings.

This is about doing less better instead of doing everything at once poorly.

[Time for a workshop exercise.]

Product evolution maps are all about connecting your plan to the ultimate project vision. Avoid falling back on tactical groupings of functionality and instead stay focussed on your strategic priorities. These documents will be living documents as the ground changes beneath you but going through the process of creating and updating the plan will keep you focussed.

[Notes from the first day of the UX Intensive]

Framing a viable offering

Who is the target audience? What experiences are compelling to them? How is your offering different from competitors and substitutes?

An example of substitution is the discovery by Lexus that the alternative to purchasing a Lexus is often taking a big vacation or buying a big piece of jewelry. These kinds of non-competitors can be very important to keep in mind.

The way to get to the answers to these questions is to use an elevator pitch. This is what you say about your projects when trying to sell it to your audience in duration of an elevator trip.

Use a MadLib like this:

For (target customers. your main market segment only)
who are dissatisfied with (the current market alternative),
our product/service is (new product category)
that provides (key problem-solving capability).
Unlike (the product alternative)
we have (differentiating attributes of your offering).

Using the "dissatisfied" portion helps you focus on the problem. You could substitute this with a positive statement if need-be.

[Time for an exercise.]

These elevator pitches are an opportunity to get input from high up the decision tree. When you hit ambiguous words like "discerning" use this as an opportunity to unpack what they mean. Get to specifics. Get a first draft and then go back and clean it up. Remind everyone that they are coming up with something that is for the customer. Think about what is meaningful to average people.

The web site should embody what the organization represents so if you get an elevator pitch for the organization you are well on the way to understanding what needs to be taken into account for the web site. Do a broad first draft for the organization and then pare it down to what about the organization's pitch is relevant to the web site. Keep the focus on the organization as a whole and talk about the web site out of that. Don't let focussing on the web site distract from other organizational questions.

Don't be afraid to iterate. Do this a few times in a meeting. Use these techniques to guide conversation. Treat them as a living document.

Use the pitch to embody the assumptions of the organization. This gives you a great place to start your research process. Look at the clear definition of the audience in the pitch and use this as a starting place. Express your assumptions in this step. Go do your field research. Come back and create a better more accurate elevator pitch.

[Thinking about these cycles in a project is a very interesting question. Avoiding a linear process seems like a profoundly important goal that is hard to achieve.]

This is the kind of thing you want to do in a workshop meeting. This is not the kind of thing you will get value from if you just e-mail it. This is about facilitating the conversation.

Once you have this written, take a look at it again with your competitor's names in the elevator pitch. If it still makes sense do it again. You and your organization are different from your competition.

Here's a test: look at Skymall. If your product would make sense in Skymall you are not likely providing much customer value.

So how does the elevator pitch really really impact user experience? This is about the first impression. You have about eight seconds to impress your users.

• What is this thing? reorienting on landing
• What does it mean? determining value
• What should I do next? making a micro-commitment

All you need on the web is the small commitment to click once more, to keep reading for a moment longer.

For Blogger there were three questions:

1. What is a blog?
2. What can you do with it?
3. How do I get one?

Articulating customer value provides clearly differentiated and meaningful offerings, getting new value into the world, market viability, etc.

[Notes from the first day of the UX Intensive]

The worst thing ever (like ever, ever) is the swoop and poop. We all know this well. It is when a stakeholder shows up late in the game and replaces the priorities that have been established with his or her own.

Definition: Converting business case and goals into something tangible.

Strategy should bring clarity to an organization; it should be a signpost for showing people where you, as their leader, are taking them -- and what they need to do to get there. But the tools executives traditionally use to communicate strategy -- spreadsheets and PowerPoint decks -- are woefully inadequate for the task. You have to be a supremely engaging storyteller if you rely only on words, and there aren't enough of those people out there. What's more, words are highly open to interpretation -- words mean different things to different people, especially when they're sitting in different parts of the organization. The result: In an effort to be relevant to a large, complicated company, strategy often gets mired in abstractions. Tim Brown in FastCompany

Measure deliverable along two axes: Vividness and Effort.

Lo-Fi prototypes are high on both axes. Comic scenarios, boxes, artifacts from the future, and other techniques move across this plane decreasing on both axes.

By defining what you want the end result to be you will bring clarity to your work. It can be high or lo fidelity as long as it offers a reminder of where you are going.

[Break for an exercise. We're designing the postcard that will serve as the tangible definition of what we are trying to accomplish for an imaginary customer.]

• Clear vision
• Obvious requirements
• A basis for prototyping
• An offering to test with others
• Alignment of your team in your organization