Projects/Usability/HIG/Persona: Difference between revisions

From KDE TechBase
< Projects‎ | Usability‎ | HIG
No edit summary
(6 intermediate revisions by 2 users not shown)
Line 3: Line 3:
== Purpose ==
== Purpose ==


A ''persona'' is a representation of a fictitious user that 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.
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 abstraction or dissociation from the own point of view. In contrast to the alternatives lead user(s), panel of real users or sociological milieus
The advantage of personas is a common understanding among the development team and the dissociation from each contributor's personal point of view. In contrast to alternative methods like lead user(s) (usually the developer him-/herself), a panel of real users or a description per sociological milieus, personas are more representative, faster to access, and easier to understand.


== Guidelines ==
== Guidelines ==
* Always define personas based empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection 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 picture 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 16:42, 2 February 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 personas is a common understanding among the development team and the dissociation from each contributor's personal point of view. In contrast to alternative methods like lead user(s) (usually the developer him-/herself), a panel of real users or a description per sociological milieus, personas are more representative, faster to access, and easier to understand.

Guidelines

  • Always define personas based empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection 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 picture 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 scenarios.

Best Practice