User-Centered Design / 7.3 /
Strategies for user research
User-Centered Design / 7.3 /
Strategies for user research
The designer needs to understand the reasons behind the behaviours, wants, and needs of the user. Designers should select research strategies based on the desired user experiences in the context of the product, service or system. The purpose of user research is to identify needs that reveal the complexities of personae. Real-life scenarios that simulate “actual” user experiences can generate new findings.
When considering strategies for user research, designers can group users into user populations. A product might be designed for a very specific user population or for multiple distinct populations. User populations can for instance be classified by age, gender, interests, experience, habits, emotional response or physical condition. This can allow the designer to gather detailed feedback to generate insights for design development that are particular to each group. For example, a group of users who suffer from arthritis in their wrists would have different concerns with the design of a new kettle and give different feedback than a population of students. A user population is to a designer what a market segment is to a marketeer.
Examples of user populations might be:
People with Arthritis, Partial paralysis, Parkinson’s disease or Repetitive strain inquiries.
People that are with eye impairments or loss of hearing
People with a reduced sense of touch.
Children.
Elderly or infirm.
A group of users that suffer from arthritis in their wrists would have different concerns with the design of a range of products and would give different feedback than a population of users with no arthritis.
Designers can observe and interview members of a user population in order to create fictional characters known as personae, secondary personae and anti-personae.
Personae development supports the design process by identifying and prioritising the roles and characteristics of key audiences for a product, service or system. They create composite individuals that represent the key features of the desired target audience. The product team forms a unified vision of the intended uses of a design through reference to agreed upon personas.
Development of personae begins with assumptions about user profiles, based on data from initial market research. Through interviews and observations, researchers expand and validate the profiles by identifying goals, motivations, contextual influences, and typical user stories for each profile. This is all done so the design team can target specific user needs for each ‘profile’ identified for their target audience - there can be multiple personae for products.
Personae are archetypical stakeholders. Personas are used to aid decisions about product features, use and design. Personas are presented to the design teams as a single human with a name, face, attitudes and goals.
Secondary personae are those who are not the primary target audience for a product, but who have needs the product should nevertheless meet. They are able to provide valuable alternative insights to the development of a product. Anti-personae are those for whom the product is not designed.
There are similarities between a UX persona as used in design and a marketing persona (topic ). Both personas are used for designers to empathize with real users. This helps them to understand their user's goals and feelings. Marketing personas however just represent people who buy products and services. You can buy a product but that doesn’t necessarily mean you’re going to use that product.
A scenario is an imagined sequence of events in the daily life of a persona based on assumptions or real-life observations by researchers and designers. Trying to simulate “actual” user experiences can generate new insights for a designer. Designers can consider best, worst and average case scenarios that provide a physical and/or social context for each persona they have developed.
While personae tell us who the user is, scenarios tell us what they do. They are descriptions of how the users may interact with a product or system. Each UCD scenario (sometimes called user story) represents one type of user performing steps to achieve a specific goal. A good UCD user story tells the designer:
When the user interacts with the product or system.
Why the user interacts with the product or system.
What the user wishes to achieve through interacting with the product or system.
A use case specifies the way a user will interact with a product. Use case specifications are formal documents, often with diagrams, that describe specific well-defined interactions between a user and a system. Use cases are often used in formal product testing to verify a product does what is supposed to do. Writing use cases requires user research.
A good use case should include several key pieces of information to ensure it adequately describes the required behaviour of a system or product.
It should include a brief description of the user's goal or objective. This helps to focus the use case on what the user wants to achieve.
It should provide a description of the actions or steps involved in achieving the user's goal.
It should describe what happens if something goes wrong or if the user deviates from the expected path. This helps identify potential issues that need to be addressed.
It should identify any dependencies or interactions with other use cases or systems.
It should include acceptance criteria that define the expected results or behaviour of the system.
These key elements will allow stakeholders to better understand the system's requirements and ensure that they are met.
User populations are defined in order to be able to create profiles of archetypical personas. These personas require a product to be of use in specific scenarios. A use case define the exact interaction between a user and a product in a particular scenario.