User-Centered Development / Personas

Type: Rules


Support the concept of user personas for requirements definition and for getting rid of the elastic user

Note: You can also use your personas {for prioritizing tests, to evaluate new ideas for features, for requirements triage, for writing the user manual] (not a complete list).

A persona is a user profile that you can use to help make design decisions, as well as use to aid you in other ways. These profiles are created from your knowledge of your users, usually knowledge gained from user testing and research. Think of it as having a “virtual” user to bounce ideas off and help you keep the goals of the user in mind on a day-to-day basis. <- D. Keith Robinson

Rules and Notes

R1: User personas should be created to find the "edge cases", use cases that make a difference within the product. Wipe out featuritis with your personas.

R2: Personas should be created with the help of stakeholders.

R3: Don't overdo it (1-3 sentences). Don't define too many (2-6).

R4: You need a complete buy-in on the personas from people who are supposed to use them

R5: Do *some* creative writing when creating personas. Small details matter.

R6: It helps putting a name and a face to the personas. Go out and take photos or cut out magazine pictures.

R7: Group personas as 'primary' (the majority, the most important) and secondary (very different from the primary personas but still very important)

Costs, Savings

What does it take to implement those rules? What does it give?

Side effects

Is there anything that happend or will happen as one implements the rules? This relates to both wanted and unwanted effects ('unwanted' does not imply 'negative').

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License