UXD - User eXperience Design

Personas and Football

This year I’m once again in the Pick a Loser football pool*. Each week, I pick an NFL team that I believe will lose and if they don’t lose, I’m out of the pool. So, for example, the first week I selected my team, the Chicago Bears, to lose (so much for fan support). They complied so I'm still in play. I can only select a team once; therefore, da Bears are off limits for the rest of the season (even though I’m fairly confident they’ll lose another game or two).

My point here is not to kvetch about our quarterback (don’t get me started) or our running back (oy), but to mention that once you Pick a Loser, you start experiencing the NFL games a bit differently. It’s not that you’re actually outright rooting for them to lose (poor sportsmanship, old bean, not at all done), but you begin to look at which team excels in mishaps, penalties, and/or position weakness, or which team is thrown off stride by an unexpected change in personnel, and how you can exploit that to ‘win’ that week.

In other words, when picking a loser I am adopting a different persona than when I pick a team to win. I have different goals and objectives, looking at the stats (data) differently and end up going down a different path (workflow) to make my selection.

This, my friend, is the point of having personas on a project. You use them to identify the different ways a user needs to interact with your product -- their point of view determines the different paths and interactions they need to take in order to achieve their goals and objectives. Once you know the different points of view, it’s a lot easier to design a flexible workflow that accommodates your users. A win-win for all.

As for me, I survived week 2 (the Chiefs in case you're interested) and now need to figure out my week 3 loser.

*disclaimer: naturally for all the kiddies out there, you should never try this at home because gambling causes your hair to fall out


Technorati Tags: personas, user experience, design

Powered by ScribeFire.

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.

Key Elements of Effective Personas

Alan Cooper is generally recognized for bringing personas to the UXD world in his 1998 classic book The Inmates Are Running the Asylum. Today, personas can be found stretching into the toolbox of marketing experts and business strategists. But what makes an effective persona? In our experience, several things are important.

First, give your personas a name and a photo. We can readily remember and relate to a series of names and photographs. It isn’t just soft fuzzy stuff, it will speed your discussions and make them more engaging. You will get to know these users as your project evolves.

Second, get a firm delineation of the user’s goals. What is this person trying to do? Then consider headlining the goals with a quote that characterizes the user’s attitude, desire or priority as it relates to the goals. For instance, in a mission critical healthcare setting, a quote might be something like “I need to be fast and accurate.”

Finally, provide a day in the life narrative about your user. What in his or her day relates to the product or system you are designing? What tasks or steps are key? You don’t need to be a great storyteller to write such a narrative. You can simply lay out a chronology of events from, say, arriving at work to leaving at the end of the day.

While there is a lot of science you can apply to personas, master the basics and you will be able to quickly craft a powerful vehicle for guiding design, strategy and ideation.

Designers on Joel

Apparently we weren't the only ones to notice Joel Spolsky's rather empty observation on usability. John S. Rhodes over at WebWord also takes issue. He puts it very succinctly:

If a software product is meant for thousands of users, exactly who is expecting exactly what?

Indeed. I'd go a step further and say that what even one user expects from an application may change over time. For one, they may appreciate an application that provides training wheels early on and prefer one that lets them get down and dirty as they become experienced in the application's domain.

Maybe it's easy writing usable software if, like Joel, you stick to bug tracking software and the like. Come out into the real world and deal with non-technologists and you may get a rude reception.

Not-So-Great Expectations

Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."

Here's an extract:

So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That's it! That's the whole story! As Hillel said, all the rest is commentary.

One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.

It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise,  self-evident and facile. His use of the passive voice is revealing:

". . . if it behaves exactly as expected."

Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.

User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"

It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?

Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.

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.