One of the questions most asked is, “When should I do user research on my project?” There are three different answers :
- Do user research at whatever stage you’re in right now. The earlier the research, the more impact the findings will have on your product, and by definition, the earliest you can do something on your current project (absent a time machine) is today.
- Do user research at all the stages. As we show below, there’s something useful to learn in every single stage of any reasonable project plan, and each research step will increase the value of your product by more than the cost of the research.
- Do most user research early in the project (when it’ll have the most impact), but conserve some budget for a smaller amount of supplementary research later in the project. This advice applies in the common case that you can’t get budget for all the research steps that would be useful.
(source: Susan Farrell, Nielsen Norman Group)
The chart below describes UX methods and activities available in various project stages.
User modeling identifies the users of the application and their goals for interacting with the application.
I begin my research phase by developing personas to support the design process and to guide UX workshop brainstorming sessions. I identify and prioritize the roles and user characteristics of key audiences for a product, system, or website, then create a composite of individuals that represent the key audience. The product team can then form a unified vision of the intended requirements of a design through reference to agreed-on personas.
I begin persona development with assumptions about user profiles, based on data from initial market research. Through interviews and observation, I can expand and validate the profiles by identifying goals, motivations, contextual influences, and typical user stories for each profile. Having a fictional person (persona) representing a profile grounds the design effort in “real users.”
For each persona, my user modeling description typically includes:
- A name, age, and defined lifestyle and workstyle
- A catchphrase that distinguishes the persona from others
- Key attributes that affect use and expectations of the product, service, or website
- Frequently performed tasks
- Tools and resources used
- Pain points relevant to the design space
Between 5 and 8 personas are manageable for design projects. For lower priority user profiles, combination personas may suffice.
Personas help teams frame design questions according to more specific user considerations. They also suggest participant profiles for user testing. Organizations should plan to re-evaluate personas every 2 or 3 years.
User Centered Design User Stories
While personas tell me who the users are, user centered design (UCD ) stories tells me what they do. They are descriptions of how the users may interact with the system. Each UCD story represents one type of user performing steps to achieve a specific goal. Like a story in literature, a good user story should have:
- A well-defined character as represented by a persona
- A setup that establishes the goal of the user
- An exposition that describes the actions of the user and the system’s responses
- A resolution that describes the resulting state of the users and the system at the end of the story.
The UCD stories tell the UX team:
- When users will interact with the system
- Why users will interact with the system
- What users wish to achieve through interaction with the system
I then create storyboards of user stories that will serve as a visual accompaniment when executing wireframes.
It is important to not mistake UCD user stories and storyboards for user stories in Agile environments. In Agile, user stories are used to describe a specific function to be developed in a single sprint from a user perspective. Agile user stories are the product of good design, while UCD user stories inform the design. Of course, UCD user stories serve as an excellent source for creating Agile user stories once a design is ready.