This post is part of a series discussing the process we’re undertaking to redesign our user interface and branding. We’re sharing in the spirit of “designing in the open” with the hope that it might be of value to our customers and others in our community.
In my previous post, I mentioned how we have utilised research methods to inform our practice (my talk on service design at last year’s Saasu conference, presented before I joined the Saasu team, expands on this somewhat). One of the challenges with using such research, whether it be qualitative or quantitative, is how to communicate and represent the data in a way that’s meaningful to the design team. While we can’t map every single one of our users’ requirements, our aim is to “package” our research findings in way that we can keep our customers front and centre in our design process.
Imagine that you’ve done some surveys (quantitative research) and you have some good information on your customers. Typically this information is presented in summary, for example:
- Age: 28–42 years of age
- Gender: 32% male/68% female
- Income: $50k–85k
As a designer, it’s very hard to design to that. What does it all mean?
Qualitative data can be added to the picture to help provide further insights. For example, through interviews or a mobile diaries study we might find that our participants really enjoy the outdoors and hold family to be very important.
This “richer” data can be very helpful, but we don’t want to design specifically for interviews. Plus, it can be very hard to connect the data-sets (qual and quant) together in ways that the design team, business stakeholders and other interested parties can use. This is one place where a tool known as personas can really help.
In my previous design practice I put together a short guide to personas (available under a Creative Commons license) that explains a little bit about what personas are and how they work. From the guide:
Personas are discussion documents that we use to help us see our work through the eyes of the people we aim to serve—our internal and external stakeholders: customers, suppliers, donors, staff, constituents, citizens etc. They represent archetypical (but importantly not stereotypical) users of the products, systems, and other business processes we are considering in our work.
There are a couple of key points in there. The first is that personas are only as valuable as the discussions they enable. The actual document/artefact is a small part of the value that they provide. The second thing is that we should not fall into overly simplistic caricature when we develop personas. For this reason, they are best based on research1.
I find the value of personas is difficult to get across in words alone, unfortunately. It is not until you experience them in the context of a project that their value becomes fully apparent. I had one client who worked with qualitative and quantitive research findings on a regular basis comment on how effective personas were at representing learnings in a way that’s meaningful and actionable, moreso than the reports and traditional communications they’d used in the past. This is the key value of personas, in my view.
I could write a whole series on personas—workshop and other methods to create them, dos and don’ts etc.—but I’ll skip that for the moment. (Please do drop us a comment if you’d like to learn more about this method, as I’d happily expand if there is interest.)
In brief, we find personas help us to:
- Keep the people we aim to serve at the centre of our attention.
- Imagine walking in the shoes of the people we aim to serve—to empathise and to see what we are working on from their perspective. Will it make sense based on their mental models and perspectives? (i.e. the way they approach problem solving and how they frame obstacles etc.)
- Discover new opportunities to service our customers—by thinking of our offering from their perspective we can find new ways of meeting those needs that we might have otherwise done considering things from an internal perspective.
- Focus our work—whether that be determining what features to build or where marketing and advertising would be best placed.
I find in practice that a “working set” of about 4 well-constructed personas works well for any given project. We have about 10 personas in total, which we re-organise/prioritise depending on the project we are working on. Our personas were based on the interviews with our customers and partners I’ve mentioned earlier, and no doubt will continue to evolve as our research practice expands. We combined these learnings with staff knowledge of our customers (e.g. from service calls, meetings with customers, conference conversations etc.) to develop a number of personas related to our business. We’ve found them to be particularly effective as a tool to focus the team and to communicate the needs of our customers.
Have you used personas in your business? What was your experience like?
Notes
- Some experienced practitioners take a harder line than I do, arguing that personas should only ever be based on research data, and should not include any creative license or information garnered from staff domain expertise. I’ve personally found that even semi-fictional personas based on the experience of staff can be very helpful at illuminating assumptions and perspectives. And sometimes they be surprisingly accurate (i.e. that further research supports the original assumptions), especially when they are based on interactions with the stakeholders we are seeking to represent. However, it is important to recognise what personas are based on and to treat them accordingly, and to verify/inform with research at every opportunity.