Recently in UX Intensive Chicago 2007 Category

[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

[Notes from the first day of the UX Intensive]

To have successful design you need a clear strategy.

Utility > Usability > Profitability > Strategibility ;)

See: History of Target Clear RX

1. Design impacts strategy
2. Strategy is about fit
3. Strategy is a system

Design can impact or even embody a strategy. Clear RX was a new way to position Target in the drug delivery marketplace.

Business is about two things: innovation and marketing Peter Drucker

Strategy is about planning what is appropriate for your firm and for your customer. Being the best is not a strategy. Doing everything is not a strategy. Target's ClearRX isn't the best for the penny-pincher. It is an expensive system to manufacture. This is why Target implemented it and not Walmart. Operational efficiency is not a strategy by itself. Best practices aren't a strategy either because everyone is already doing those things.

In the end, being the same as everyone else and doing the same thing as your competition should not the basis of your strategy.

Trade-offs are about choosing what to do and what not to do. Strategy is about saying "no."

Strategy is about planning and thing ahead. It is about common sense.

So back to the history.

Utility > Usability > Profitability > Strategy

That last piece is about integrating design with the organization's strategy.

What do you need for design?

• Scope
• Customer Value
• Definition
• Focus

So let's start with focus. The question here is what will generate real business value. How can interaction design, broadly defined, interact with the business value? How can it generate measurable ROI?

People who understand and express the "R" of Return on Investment get the "I."

AP did some primary research and developed two models.

The first is organizational. Groups evolve through four stages as they become more sophisticated user experience practitioners.

1. Intuition
2. User Behavior
3. Project Value
4. Business Value
5. Market Strategy

An organization doesn't need to move up this ladder to work.

The second model is the UX value chain. This is circular.

• Identify business problems and opportunities
• Identify metrics and measures
• Choose projects
• Design and test
• Assess actual value
• Set budgets
• Repeat these steps

How do I know if my organization is doing this right?

Common problems:

• The panacea project: "this will fix everything"
• "We want to be the Google/iPod of..."
• Ambitions exceed resources
• Too many competing requirements
• Prior attempts failed
• Can't say "no"
• Focus on just one metric

So how do figure out what to do? How do we figure out what will provide the most value?

Stakeholder interviews are an important way to begin. This is a good way to generate a list of things the organization could possibly do.

See: Lulu example

The two factors to look at are importance and feasibility. Is technically feasible? Is it organizationally feasible? Plot out your ideas along this spectrum.

Not everything is automatically really really important and really really feasible. Strategy is about saying "no" to some things so you can do really well at other things.

Take all of the opportunities you have identified and rate them from 1 to 5 on importance and feasibility. Limit the number of points so the average is three. This forces scarcity and thus makes it possible to really decide between options.

[Pause for an exercise. The workshop format is a great addition to the talks.]

When setting priorities it is important to balance values. In the exercise, my group ended up nothing in the "Do Now" category because our rankings were balanced. It is almost as if ranking everything close to average is a way to avoid making a decision too. We also found that what we rated as priorities from the perspective of the business was also ranked as less feasible.

Another interesting issue is the way that priority and feasibility can influence each-other when they are side by side. If you have a group that really trusts each-other you could divide into separate groups to rate priority and feasibility before coming back to plot the initiatives on the chart.

It is very important to avoid skipping ahead to solutions. This is a big problem for me. As a designer I want to make the initiative concrete, to talk about in terms of actual designed things. This needs to be avoided so everyone can keep their minds open to all the options in front of them. It is similarly important to avoid measuring feasibility only in terms of the web team.

Focus really means saying "no." It means getting to an achievable mandate with explicit design guidance.

I'm in Chicago this week for Adaptive Path's User Experience Intensive. I'll try to take some notes if I can get rid of these damn hiccups.