Sunday, December 27, 2009

Pragmatic Personas: Putting the User Back in User Stories

At Agile 2009, Jeff Patton gave a workshop about how to design and build software that has a better user experience. Jeff starts out by reviewing the different ways that software is built.
  • FUBU: For Us By Us. Start with idea to build something for us. Product is built to solve a certain problem we face. Then audience diversifies and product evolves and no longer becomes for us
  • FMBY: For Me By You. We take down requirements and hope that everything comes out OK.
  • MSU: Making things up design.
  • FTBU: For Them By Us.

Jeff explains that if a product is good, it is built for the people that will use it and that is not us.For them by us is user centered design. To build a good product we need to care about the user. Another way is to keep asking users what they want.

Jeff defines a pragmatic persona as a quick exploration of what we know about our users. We want to build them to start discussions about what we know and don’t and help drive mapping your user experience using stories.

Next Jeff goes over the process of creating a persona by walking through an example of a restaurant review application:

1. Identify kinds of users (user types or roles)

Determine the criteria that makes each type distinct. Identify high priority or focal types.
Think of different kinds of people that will use your product as user types (college students, business professional).
A user role describes the relationship a person has with your product. We change roles like changing hats. Think thing-doer (late night pizza buyer, daytime lunch seeker, penny pinching pizza buyer, married daytime lunch seeker). Isolate aspects that are relevant.
Next prioritize. The user types that are the most relevant to design depends on the business and product goals. Figure out which user types are most critical to achieve the goals and objectives. Refer to these user types as focal or primary. A typical system will have 2 or 3 focal users and several more that aren’t (make sure these are listed as well).

2. Profile Users (start with assumptions about users and then add additional info by doing research). Identify information about users relevant to the product. Profiling adds general information to user types like sizing, gender, domain knowledge, pains, goals, motivation, general activities, context, frequency, collaborators, and other products they rely on.




3. Assemble a composite and give a concrete example based on the representative data. Personifying chooses specific information to create a tangible, realistic example. Include in a persona: name, job title or role, minimal and relevant demographics, description that defines user type’s primary activities, description that reveal characteristics that affect probable usage, description that reveals goals, motivations, pain points, quotes in the persona’s language expressing goals or pains.


4. Identify product design impact by naming characteristics the software must have in order to be valuable to users as design imperatives. Name valuable product features, ideas, characteristics or opportunities for this user type (ease of learning, retention of learning, efficiency of interaction, reliability of interaction, user satisfaction, user convenience, necessity for proficiency, importance of accuracy. Explain what easy to use means for this persona. Write out the user type or role, name and sketch, some context, characteristics and goals (avoid design impacts), implications (what’s valuable to chuck).


Backfill important and unknown information with facts to mitigate risk:

Given assumptions based personas, you can identify the areas where your information is sparse or incomplete. You can use research to backfill your profiles with facts in critical areas. Interviewing target user groups, observing users, questionnaires, published demographics, published research, customer service records, sales and marketing, usability testing, focus groups, innovations games. When interviewing, ask people to recall specific events or situations, don’t ask leading questions, and when they describe something ask about its benefit.

Separating a diverse group of users into types can be difficult. Look for difference that makes a difference in the design of your product.

Jeff wraps up by explaining that the trick is to sketch a pragmatic persona that is not like yourself.

This presentation is available on InfoQ at http://www.infoq.com/presentations/pragmatic-personas