UXD - User eXperience Design

Scenarios – Recording a Day in the Life

One of the simplest and most effective scenarios you can create for an application user (someone who uses an application as part of his or her daily work) is the Day in the Life scenario. It is effective at capturing both tasks and context for using the application.

A series of interview questions can be used to extract the Day in the Life. Some possible questions are:

1. When do you arrive at work?
2. What is the first thing you do?
3. What kind of interruptions do you have?
4. Do you multitask, or finish one thing at a time?
5. How frequently do you use the application during the day?
6. What tasks does the application help you perform?
7. How critical to your job are these tasks?
8. How does the application help you do your job?
9. What does the application not help you with?
10. How much time do you spend during the day using the application?
11. What work is left unfinished at the end of the day?
12. When do you leave?

You can add to this list and modify it as needed. Once you finish your interview, transform the responses into a narrative for an effective Day in the Life scenario.

User Experience in Sovereign vs. Transitory Applications

The characteristics of what makes a quality user experience can vary dramatically when talking about a sovereign application vs. a transitory one.  Sovereign applications, like Microsoft Word, draw in and maintain our attention for a length of time. Transitory applications, like Google, serve us for a short term need and then we move on.

Walk Up and Use
A transitory application should have a walk up and use quality. Even the slightest extra need for time to figure something out can dissuade users. In addition, these applications benefit from a comfort factor. If the software seems comfortable, I’m more likely to not mind spending a few moments with it. Finally, good error recovery is essential. The software should instruct the user as to how to recover and provide an easy way to do so, or start over.

Extend My Abilities
Sovereign applications should enable us to extend our abilities to get something done which may be complex or require some time. Making the correct design trade offs and arriving at a quality experience depends on characterizing how the tool extends the user’s abilities. Does the tool allow for faster performance of a repetitive task? Does the tool enable completion of a task not possible without the tool? Does the tool aggregate tasks into one place? The key to creating an effective design (and measure of success) is determining the ways in which the tool extends the users abilities and which are most important.

Scenarios in Product and Project Management

One of the biggest challenges in product and project management is definition and control of scope. By its nature, a design process is a discovery process. As new things are discovered, scope can increase.

One way to manage scope is through scenarios. While a product can have many processes, interactions, screens or flows, at the human level there are likely to be a quantifiable and definable number of scenarios. After all, products and processes are created to enable someone to do something.

By using scenarios as the "buckets" of what a design needs to enable people to do, it's possible to manage scope from this perspective. Any new feature or requirement must fall into one of two categories: It either requires a new scenario, or it's an addition or refinement to an existing scenario. If the scenarios are prioritized, scope impact can be handled by answering the following questions:

- If the new feature requires a new scenario, how high a priority is that scenario?
- If the new feature ties to an existing scenario, does it change the priority of the scenario? Does it change the implementation time for the scenario?

Defining and prioritizing scenarios can be a great help in controlling scope of a project. Scenarios can provide a manageable way of grouping and prioritizing features, innovations and ideas to keep everyone on the same page and the project on-target.

The Design of Non-Everyday Things

Often as User Experience Architects, we are asked to bring the design process into new domains and complicated products that may have not been previously exposed to such a process. How can we, as professionals, achieve success in new and challenging environments? The answer is nothing new: Stick to the fundamentals. Don Norman listed them in his timeless classic, The Design of Everyday Things. As "Things" become more complex and more niche oriented, the principles still apply. Let's review a few of them.

First, keep the structure of tasks simple. A task may have many steps, and involve complicated data, but the structure can still be simple. Second, make things visible. If the user can't see it (or hear it or touch it), they probably can't use it. Third, design good error recovery mechanisms. The user should not be allowed to box themselves into a black hole they can't get out of. Finally, create and leverage standards. Think about the amazing complexities in road travel that are possible with a few simple standards of lights and signs.

Applying the fundamentals is the key to success in complex projects. Getting good with these timeless principles will make the complex manageable, and even fun.

Thoughtful gesture? Peter Coffee’s column misses the point.

As I leafed through my ever growing stack of tech magazines yesterday, a column in eWeek by Peter Coffee, entitled Thoughtful gestures – don’t make complexity elegant; make it disappear caught my eye. 

Mr. Coffee was writing about a patent application from Apple for processing multipoint gestures on a touch input device. The language of patent applications is notoriously dense and jargon laden, so in laymans terms, this is about making it easier to interpret what a user wants when they touch a screen or touch pad at multiple points at the same time.  Some simple examples of multipoint gestures include squeezing, stretching or twisting motions while touching a screen with your finger tips.

Mr. Coffee's contention is that this invention is a way of making more complex tasks easier to perform, that it has no real-world, practical application, and that this is the wrong problem for inventors to tackle. He states that “I’d rather see interface efforts based on watching what users do, understanding common needs and designing systems in which those actions are simple. Making complexity elegant is an achievement, but I'd rather just make that complexity invisible.”

This is a fine sentiment, and a good one-sentence description of user experience design, but he really misses the point of how new input device inventions relate to user-experience design.

He illustrates the uselessness of gestural interfaces by describing two ways of saving a users work – one using a whole series of convoluted gestures that makes the user look like she’s doing the Macarena, and a simple, elegant way of using keyboard strokes. Boy, based on that example, gestural interface sure sounds like a bad idea, and inventors should stick to improving how to use existing input devices.

The trouble with this example is that the same argument was made about the mouse when it joined the keyboard as an interface device. There were (and are) many things that are easier to do with a keyboard than with a mouse – saving a file using shortcuts, typing a letter, entering data in a spreadsheet, just to name a few. Does that make the mouse useless? Why use something as complicated as a mouse?

Let’s take the case of a user putting together a process diagram in Visio. Using a keyboard interface, a user can perform a lot of complicated keyboard strokes to generate, place, link and annotate the diagram elements. Meanwhile, back in the real world (as Mr. Coffee would say) the user simply drags and drops the elements in place using his mouse, touch pad or pointer.

Clearly, different interfaces are good for different types of actions, and it’s up to the user experience designer to apply the appropriate combination of available interfaces in a way that lets the user simplify and streamline their interactions.

So where might using a multipoint gesture interface simplify a current, real world interaction? How about Google Maps: Multipoint gestures such as squeezing, stretching or turning, combined with single point gestures like dragging, could make navigation significantly simpler and faster than the current mouse-based approach.

The point of inventions like this is not to make more complex acts achievable, but what things can be simplified using these inventions. Almost all ways in which we interface with computers are pretty complex. For example, learning to use a keyboard is a lot more complex and time consuming than learning to use a mouse, and learning to navigate using keyboard shortcuts requires much more familiarity with an application than using a mouse. Gestural interfaces need be no more complex than keyboard or mouse interfaces.

So inventors, keep inventing!  Between user experience designers, developers and usere, we'll take the best inventions to  make things genuinely simple.

Requirements Visualization, V1

At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.

The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.

Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Comprehension is more important than brevity here - at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations - look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.

In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that's another blog.

Learning Complex Domains for User Experience Design (UXD) Projects

Legend has it the famous advertising slogan “Two scoops of raisins in Kellogg’s Raisin Bran” was created by an energetic copywriter who literally dumped out the box of cereal on a table and scrutinized the content for inspiration. Moral of the story:  As designers we have to know our product. But what do you do when your product involves biological science, electrical engineering or any other complex domain? Here’s a few suggestions for getting up to speed in a complex subject areas.

Speak the Language
First, you have to speak the language. Ask your subject expert to outline the top ten or fifteen words or expressions used on a daily basis by your users. Then have him or her define those words in terms that you can understand.  Keep the number of words to ten or fifteen, and only the most important terms.

Key Scenarios
Next, identify the top five or so key scenarios your users do in a typical day. Each scenario should have a simple title and a set of steps. Remember, the goal initially isn’t to do user research, but just to get a feel for what people are doing. Try to cover the five scenarios in an hour or less. This will help your expert from getting too bogged down in details you won’t be able to digest yet.

Map the Scenarios
Once you have the key scenarios, arrange them in a hierarchy. Of course, it’s possible the scenarios are isolated tasks and don’t fit a hierarchy, which is fine. But usually a hierarchy of some kind applies. This hierarchy will become a context for understanding when your user does various things.

Construct a Day in the Life Narrative
To test your understanding of the domain, take the information you have gathered and construct a day in the life narrative of your user. In doing so, you will create a vehicle for refining your domain knowledge and a start to your more serious user research.   

Two Hours or Less
No matter how complex the domain, make it your objective to get through the above tasks in 2 hours or less. By time limiting the exercise, you can keep your subject matter expert from straying into the details before you have the basics solidified.