FlavourCrusader

At Zumio personas are the starting point for much of our work. 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.

We strive to develop our personas from user research that either we, or our clients, have undertaken. But personas can also be a good way to collate and re-present internal domain knowledge. However, extreme caution must be taken when this latter approach is taken not to misrepresent the personas as reflecting the users' perspective. We've developed a client guide Introduction to Personas that describes in a little more detail how we develop and use personas.

One direct way that personas support our practice is in the generation of what we call "business user stories". This approach borrows the user stories method from agile development practice and applies them at the business/strategic level. Penny Hagen and Michelle Gilmore outline this concept ably in their Jonny Holland article User Stories: a strategic design tool. These user stories act as business requirements in our practice. In our web-centric projects these high level stories inform, and are cross-referenced against, the information architecture (content structure), content strategy, wireframes and other design documents outlining the functionality to be delivered in the project.

We find the approach works equally well for marketing/communications websites to social media strategy to web application design, but also for non-web projects. For example, we've used personas for a rebranding project to understand the needs of people our client was aiming to engage and develop marketing/brand positioning.

We then translate these business user stories into detailed functional requirements (the more common level where user stories are employed). The difference between these different levels of story are outlined in our client guide Introduction to User Stories.

Persona and User Stories help us keep the focus on value delivered to end-users. They help break decision deadlocks and avoid decisions being made on the basis of personal opinion. They also help avoid project stakeholders getting "off course" or too focused on internal requirements rather than end-user goals. Without solid prioritisation and understanding of personas, you can come up with (literally) thousands of user stories — so these tools help us to keep on track and focused on what's important for business + user benefit.

The particular personas we've provided as examples above were for the FlavourCrusader project. They represent and reflect the learnings from a small in-context study (5 "social media-savvy foodies" + 2 industry participants) which sought to understand the motivations for local fresh fruit and vegetable purchasing to inform the project. They were used to inform the feature set developed in a prototype web application 'seasonal produce and recipe guide'.  

Tips:

• The following tips are further to the tips included in our client guide Introduction to Personas
• Demographic data is usually not enough to develop an effective persona – we typically employ observational/ethnographically-inspired qualitative research to inform our personas
• It can be easy to fall into the trap of building personas around known "segments" from marketing or demographics etc. If personas split across these lines in our practice, this raises a red "warning" flag for us (although sometimes this is a totally valid approach). We find that splits across behavioural lines is usually more fruitful.
• The personas are designed to tap into different ways of learning/understanding. Its important to use visualisations + narrative, along with bullet points. For example, some of our team can't grok a persona unless there's a strong narrative element to empathise with first. Others much prefer the bullet points.
• We nearly always involve the client in the development of personas, using flip-charts, marker pens, collage and other lo-fi methods to collaboratively build up a picture of our persona, which are then evolved into the personas we've provided.

Pitfalls

• Rendering personas to this level of detail can cause people think they're "finished" or need to be "approved". We try and avoid this and keep them as living documents and continue to emphasise throughout the project that they can change to answer new questions and new learnings as they come to hand.
• If the client is not involved in their development, they often don't understand their purpose and importance. I've been pulled into a project late in the piece where the client confessed "we don't really understand what those persona things are for". So it was perhaps no surprise that we kept getting un-focused/un-targeted requests late in the project that didn't really relate back to user goals.
• Similarly, when personas are presented without sufficient context/introduction, people may not know what they mean — this can be a big risk if the client is re-presenting personas internally (e.g. to key decision makers) but are not adequately prepared in introducing to their purpose and form.