Difference between revisions of "Projects/Usability/HIG/Persona"
| Line 3: | Line 3: | ||
== Purpose == | == Purpose == | ||
| − | A ''persona'' is | + | A ''persona'' is the representation of a virtual user, based on empirical data. The description includes a concise summary of characteristics of the user, their experience, goals and tasks, pain points, and environmental conditions. Personas describe the target users, giving a clear picture of how they're likely to use the system, and what they’ll expect from it. |
| − | The advantage of persona is a common understanding over the development team and the dissociation from the personal point of view. In contrast to alternative methods like lead user(s) (usually the developer itself), a panel of real users or a description per sociological milieus, persona are more representative, faster to access, and easier to understand | + | The advantage of persona is a common understanding over the development team and the dissociation from the personal point of view. In contrast to alternative methods like lead user(s) (usually the developer itself), a panel of real users or a description per sociological milieus, persona are more representative, faster to access, and easier to understand. |
== Guidelines == | == Guidelines == | ||
| + | * Always define persona on ground of empirical data. | ||
| + | * Add enough information to establish a good impression of the target user. But do not write a novel and stay concise. | ||
| + | * Common elements are: name, job titles and major responsibilities, demographics such as age, education, ethnicity, and family status, goals and tasks they are trying to complete using the application, physical, social, and technological environment. | ||
| + | * Add a quote that sums up what matters most to the persona and a casual pictures representing that user group. | ||
| + | * Discriminate between primary (the basic user) and secondary (additional users) persona. If it makes sense, describe the group of users that is explicitly not supported by a anti-persona. Respect the law of parsimony and have as few personas as possible. | ||
| + | * Make sure your persona can act in different [[Projects/Usability/HIG/Scenario|scenarios]. | ||
== Best Practice == | == Best Practice == | ||
| − | http://techbase.kde.org/Projects/Usability/Principles/KDE4_Personas | + | * Try to use the predefined [http://techbase.kde.org/Projects/Usability/Principles/KDE4_Personas| KDE personas]. |
[[Category:Usability]][[Category:Structure]][[Category:Task_Flow]] | [[Category:Usability]][[Category:Structure]][[Category:Task_Flow]] | ||
Revision as of 13:12, 28 January 2014
Purpose
A persona is the representation of a virtual user, based on empirical data. The description includes a concise summary of characteristics of the user, their experience, goals and tasks, pain points, and environmental conditions. Personas describe the target users, giving a clear picture of how they're likely to use the system, and what they’ll expect from it.
The advantage of persona is a common understanding over the development team and the dissociation from the personal point of view. In contrast to alternative methods like lead user(s) (usually the developer itself), a panel of real users or a description per sociological milieus, persona are more representative, faster to access, and easier to understand.
Guidelines
- Always define persona on ground of empirical data.
- Add enough information to establish a good impression of the target user. But do not write a novel and stay concise.
- Common elements are: name, job titles and major responsibilities, demographics such as age, education, ethnicity, and family status, goals and tasks they are trying to complete using the application, physical, social, and technological environment.
- Add a quote that sums up what matters most to the persona and a casual pictures representing that user group.
- Discriminate between primary (the basic user) and secondary (additional users) persona. If it makes sense, describe the group of users that is explicitly not supported by a anti-persona. Respect the law of parsimony and have as few personas as possible.
- Make sure your persona can act in different [[Projects/Usability/HIG/Scenario|scenarios].
Best Practice
- Try to use the predefined KDE personas.
This page was last edited on 28 January 2014, at 13:12. Content is available under Creative Commons License SA 4.0 unless otherwise noted.