There are few tools that are used in user centered design. They are persona, scenarios, and essential use cases.
During the UCD process, a persona of the user's need may be created. It is a fictional character with all the characteristics of the user. Personas are created after the field research process, which typically consists of members of the primary stakeholder (user) group being observed on their behaviour, and additionaly answering questionnaires or participating in interviews, or a mixture of both.
After results are gathered from the field research, they are used to create personas of the primary stakeholder group. Often, there may be several personas concerning the same group of individuals, since it is almost impossible to apply all the characteristics of the stakeholder group onto one character. The character depicts the a "typical" stakeholder, not an "average" individual in the primary stakeholder group, and is referred to throughout the entire design process.
There are also what's called a secondary persona, where the character is not a member of the primary stakeholder group and is not the main target of the design, but their needs should be met and problems solved if possible. They exist to help account for further possible problems and difficulties that may occur even though the primary stakeholder group is satisfied with their solution.
There is also an anti-persona, which is the character which the design process is not made for. Personas usually include a name and picture, demographics, roles and responsibilities, goals and tasks, motivations and needs, environment and context, and a quote that can represent the character's personality.
Personas are useful in the sense that they create a common shared understanding of the user group for which the design process is built around. Also, they help to prioritize the design considerations by providing a context of what the user needs and what functions are simply nice to add and have. They can also provide a human face and existence to a diversified and scattered user group, and can also create some empathy and add emotions when referring to the users.
However, since personas are a generalized perception of the primary stakeholder group from collected data, the characteristics may be too broad and typical, or too much of an "average joe". Sometimes, personas can have stereotypical properties also. Overall, personas are a useful tool that can be used since designers in the design process can have an actual person to make design measure around other than referring to a set of data or a wide range of individuals.
A scenario created in the UCD process is a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story. The story should be specific of the events happening that relate to the problems of the primary stakeholder group, and normally the main research questions the design process is built upon.
These may turn out to be a simple story about the daily life of an individual, but small details from the events should imply details about the users, and may include emotional or physical characteristics. There can be the "best case scenario", where everything works out best for the main character, the "worst case scenario", where the main character experiences everything going wrong around him or her, and an "average case scenario", which is the typical life of the individual, where nothing really special or really depressing occurs, and the day just moves on.
Scenarios create a social context to which the personas exist in, and also create an actual physical world, instead of imagining a character with internal characteristics from gathered data an nothing else; there is more action involved in the persona's existence. A scenario is also more easily understood by people, since it is in the form of a story, and is easier to follow.
In short, a use case describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world.
It is represented as a series of simple steps for the character to achieve his or her goal, in the form of a cause-and effect scheme. A use case should:
- Describe what the system shall do for the actor to achieve a particular goal.
- Include no implementation-specific language.
- Be at the appropriate level of detail.
- Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.
Use cases are useful because they help identify useful levels of design work. They allow the designers to see the actual low level processes that are involved for a certain problem, which makes the problem easier to handle, since certain minor steps and details the user makes are exposed. They also convey useful and important tasks where the designer can see which one are of higher importance than others.