In essence a persona represents an archetypal stakeholder, a ‘fictional’ character representing a group of users with similar characteristics, motivations, attitudes or behaviors. Each ‘persona’ is typically given a name, a photo and some basic characteristics and it is a great way of injecting the ‘voice of the customer’ into the definition and design of processes and IT systems. Stakeholders start to ask questions like “Hang on, have we forgotten Dave—he values personal advice by phone—how would he feel about this change?” or “Have we considered Natasha’s needs here? She spends a lot of time on the road so will probably be accessing our web services on a cell-phone… have we covered this?”. It can create some great debates and shows the tensions that can often exist: Building something that is just perfect for one group often makes things worse for another if we aren’t careful…
To be most effective, personas need to be built on some kind of insight or data. IIBA®’s Business Analysis Body of Knowledge (BABOK®) guide states:
“Research is conducted to understand the user group, and the personas are then created based upon knowledge rather than opinion.” (BABOK® v3, p.357)
There is of course room for personas based on a hypothesis, these are sometimes known as ‘proto personas’, but we ought to be very wary of personas built entirely on conjecture. If we build them based purely on what the project team thinks, there is a significant danger that we’ll end up building a solution that works for the users we expect rather than the users that actually exist. Even worse, we might end up building the solution that we would like, rather than one that our users would find useful...
Watch Out For Unsubstantiated Stereotypes
A warning sign to look out for is when the personas appear very broad and appear to be based on anecdotes and popular buzzwords. Perhaps you see “Paula the millennial” who is representing the tech-savvy, time-poor, impatient user group, and “Bob the Boomer” who represents a retiree who is less tech savvy. This might be appropriate in some situations, but let’s step back and think about it for a second. ‘Millennials’ is often used to mean anyone born between 1981 - 1996 — that’s a fifteen year window. What on earth would make us think that the life experience of someone in 1981 is anything like that of 1996? In the words of Cee Lo Green “I guess he's an Xbox and I'm more Atari….”.
Dig further and we’ll find even more inconsistencies. If we were defining services for a financial services company, someone born in (say) 1995 who grew up in the care system and has never had a bank account is likely to have a very different experience and knowledge of financial services to (say) someone born the same year who had parents who have paid into a trust fund. What on earth would make us think they have the same needs, just because they were born in the same year? The same is true, of course, of boomers—and the assertion that older people can’t use technology is a vast oversimplification. I’m sure many of us have seen our older relatives join the social media revolution.
A Key Question To Ask
A question that we should become comfortable asking is “What customer data or insight are we basing this decision on?”. Quite often this will be met with a blank stare—that’s OK. Sometimes our colleagues might not have had the opportunity to do any research yet. We can help them assess what data already exists, what questions need to be asked and how we might assemble any data or insight that’s needed. We can help spot the gaps in data and discuss how to address this, or if this isn’t possible we can at least ensure that the decision makers are aware of the risk. Either way, we can work with our stakeholders to build early customer validation into our delivery process so we get early and regular feedback so that we can adjust.
Keeping the various types of users and stakeholders in mind enables us to define a service that works well for the broadest range of people whilst also delivering the outcomes our organization needs. We shouldn’t be afraid to ‘raise the red flag’ and ask probing questions if the data is lacking.