The popularity of Personas seems to have increased with the introduction of Agile methods like Scrum into many organisations. This seems to be because many are not satisfied with the generic ‘user’ reference in use cases and user stories and want to add a richness to their requirements that can only be found in applying user-centred design techniques. How to go about creating Personas without doing weeks or months of up-front design and research, though, is a common question on the lips of those UX practitioners who are turning to collaborative work with developers in Scrum. Nielsen suggests doing user-research in Sprint 0 (project initiation) while the project is being setup. That’s certainly an option if you’ve already brought your team onboard, however not everyone (and I’ve not experienced it in 20 years) can have their entire team participate in the project’s setup. So, when is the best time to create Personas in Agile environments and what can go into them in the short time you have available to you (most likely during Sprint Planning for Sprint 1)?
1. Use readily available data from trusted sources over embarking on user-research
Research takes time. Survey design takes time. Getting sufficient respondents to answers the questions to get clarity on an issue takes even longer. An Agile project isn’t suited to spending months to create documentation that crystalises people’s understanding of stakeholder and customer needs. It needs to get going in days so it can deliver on outcomes in a rapid fashion.
Instead of doing a lot of research up-front, I turn to the web. Forrester and Neilsen both blog and present their most recent data in an attempt to persuade you to buy their reports. The most valuable data, though, is typically in these free, open and easily accessible sources. Why spend tens and hundreds of thousands of dollars on reports when you can find out the essence of what you need in a day of Googling? Importantly, re-use Personas where existing data, research or stakeholder/customer knowledge is available. Zen Ex Machina has alot of persona data readily available and it enables me to get started as soon as Sprint 1’s planning starts.
2. Ask questions of users when you need them over exploration
During a Sprint, when a particular design or requirements question arises, go to users then. One of the best mechanisms to build this sort of readily available user-base is to blog and tweet about your projects. People who are interested in what you do will often be more than happy to spend a minute or two commenting, completing a poll, or answering a question. The trick is to keep their involvement to a 2-minute timeframe (the average time people spend on their smartphones interacting with an organisation) and reinforce that their involvement will help to realise outcomes at the end of the Sprint. Once the Sprint is finished, blog about what’s been accomplished. This will reinforce that people’s involvement results in valuable outcomes for them. Exploration, on the other hand, isn’t a time-boxed activity and often results in delays in projects.
3. Focus Personas on motivations over comprehensive narrative
Narrative is important because brings Personas to life and helps the team identify with their issues. Long stories about the persona’s life, though, take time to read and often distract the team from knowing exactly how to tackle products in order to deliver value to the customer.
This is important from a psychological aspect, but not in terms of requirements. Motivations help to answer the question ‘why’:
- Why does he want to do an interaction in that way?
- Why does he want that feature at all?
Psychological motivators are the most potent to leverage in this situation because of the science and research that sits behind it. Typically, I use the following and list them on my Personas:
Power Theory
- Expert Power – does this feature help them show to others that they have great knowledge in this area?
- Referent Power – does this feature help them to show to others that they are important to others?
- Legitimate Power – does this feature remind others that they are the boss?
- Coercive Power – does this feature remind others that if they don’t adhere to the rules then this person has the ability to deliver some form of punishment?
Hierarchy of Needs
- Safety – does this feature help them with health, employment, housing?
- Community – does this feature help them meet their need to feel a part of the group?
- Esteem – does this feature help to give them confidence, or show them some form of achievement
- Self-actualisation – does this feature help them be creative or spontaneous
Motivators stir people to action. Understanding what motivates someone, and embedding it into a product, means they will be more likely to use that feature.
4. Include values over wants and needs
Understanding what a person values helps the team and the Product Owner assess their logic behind the order in which products are delivered. Values should be traceable to the project’s aims, objectives and outcomes. Using these will help the team communicate when, at what stage in the project, a customer or the business is able to reap specific benefits or outcomes. Articulate needs only when the values are known — needs are a placeholder for a solution to deliver against the values.
5. Articulate trust relationships over generic interaction design preferences
Edelman‘s research clearly articulates that people trust some sources of information over others. For example, people trust those who they can identify as ‘like themselves’ (a psychological phenomenon known as identification). Putting this information into Personas reinforces that design must elicit a trust relationship between the user and the interface. Titles, reputation titles, and the ability to see an individual’s track record of interaction assist with establishing that trust.
6. Put it on an A3 over multiple written pages
As a point of reference, a Persona needs to be in a place where it constantly reminds the team who it is delivering value to. This way of using Personas ultimately favours graphical and visual display techniques. Put them on a single A3 page (nice and big!) and attach them to the wall so that they can be easily seen and easily referred to at a glance, rather than having to look through project documentation hidden in a network folder.
Conclusions
Personas are still a valuable tool to bring clarity to the planning and creation of products by a team, whether they are using Agile methods or not. Time and budgetary constraints, though, mean a full-blown exploratory user-research phase is just not practical. Data-driven personas, though, based on capturing existing knowledge and articulating it in a consise way, provides ‘just-enough’ information for the team to do what they need to do — deliver.
M
