Persona development
From BasKetUsabilityWiki
Contents |
[edit] What are personas?
Personas are detailed descriptions of imaginary users of a program. These descriptions serve as a basis for discussing who to design for, and later which features serve his or her goals. They form a basis for informed decisions in the development process. Personas are described like a real person would be described, including personal details and preferences and their goals. This is done to help developers imagine them as real persons, making a decision if a specific feature helps a user group achieving their goals a lot easier. Instead of talking about "the user", we are talking about "John, the 35-year-old telephone engineer", and discussions can be much more concrete.
[edit] Where do personas come from?
Personas should always be based on data collected about users. As Alan Cooper, who developed the concept of personas for software design, formulates it, personas and their goals are not "made up", but they get "discovered as a byproduct of the investigation process. In the case of the BasKet Usability Project, there have been two surveys in which users of BasKet were asked about personal informations, their computer experience and their general computer and BasKet usage habits. These informations were structured and categorized into different groups of users, from which skeletons were formed. Skeletons are lists of distiguishing details for each category of users. They are handy for making a preselection of user groups to design for, prioritizing them and discussing about target groups. Not every skeleton will be develop into a persona, and skeletons may be merged if appropriate. It was not possible to conduct user observations or interview users one-on-one because I simply do not know anyone who is using BasKet for a longer time. And since a questionnaire has its limitations, we have to make assumptions about the users. These are marked with an [A] in the skeletons.
[edit] Workflow
The workflow is as follows. It is not to be seen strictly linear, there can loops if necessary.
- Collect data: this was done with the two surveys; there are also two scientific articles about note-taking (see ???).
- Process data: the replies to the open questions in the survey were written on cards, put on a wall, grouped and categorized into groups (a so-called affinity diagram). The groups were pre-defined based on statistical findings from the survey.
- Identify and create skeletons: The skeletons are created by summing up the grouped facts from the wall. For each identified user group, one skeleton is created. This is the phase where your involvement can begin.
- Prioritize, sort out and/or merge the skeletons: The skeletons must be prioritized, and it must be discussed for whom to design and for whom not.
- Develop selected skeletons into personas: from the skeletons personas are developed (there will probably be two or three personas at most). Users will be able to discuss these as well. This also serves as a validation of the personas, but especially
- Validate personas: The user discussion serves as a form of validation. Misconceptions, errors and missing important facts can be fixed in this way. The personas are refinded iteratively.
- Use personas: Once we have validated, complete personas, we can use them. They make design decisions easier because we have easy-to-handle summaries of data. We lessen the problem that we would have to ask users all the time when thinking about new features - we just think if Sophie or whoever would need it or not. Personas can even be sources of inspiration, if we think of users and their goals in another way.
[edit] More about personas ...
- Wikipedia article about personas
- Personas at usability.gov
- Cooper, Alan. The Inmates are Running the Asylum. SAMS, 1999. ISBN 0-672-31649-8
- Pruitt, John & Adlin, Tamara. The Persona Lifecycle : Keeping People in Mind Throughout Product Design. Morgan Kaufmann, 2006. ISBN 0-12-566251-3
