building a community of interest and practice in service design
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'.
Add a Comment