Personas Help Drive Requirements.. Really!

Here is an example of this in action:

(yes, it happens to be snowing outside right now.. and I’m also thinking about all the work ahead of me and am not looking forward to it)

What do all of these have in common?

You guessed it… some representation of the person or thing that is interacting with the system. In UML this might be called an Actor. In the user story and in the BDD template <role> was used.

This may sound obvious, but I’ve seen software teams overlook this too often. It’s very easy to focus on “what the software does” versus “how to people interact with the software to achieve specific value”

Many teams have started to consider more than just roles and actors when designing software. In fact, I’ve found it very valuable to understand the personality behind the role – provide the role some character, some history, a face, and even a name. Why? Because by painting out these extra attributes, I now have an improved ability to empathize and build a personal imaginary relationship with this role so that I can design my software to best fit their needs. When we start decorating “roles” with a history and personality, they become personas – real people we’re trying to please.

Taking the time to define personas really helps you understand how the software you’re writing fits into the lives of its users and helps them do their job and provide them value. Starting with a persona, you can quickly decompose the types and flow of interactions that the software you’re writing should support. It’s the flow of the interaction that will truly provide value to the user – not features alone. Personas also allow you to truly focus on value from the eyes of the person (or thing) using the software.

Again, this isn’t really new stuff – but I’m shocked at how most teams value features, stories, requirements over personas. When I am asked to do a presentation, the first thing I ask is “who is my audience?” so that I can present in a language that has the most resonance and provide content that is the most valuable to that audience. When you write a story, you start by first thinking about the characters in your story – as their personalities grow, the story seems to write itself.

When sitting down to capture requirements in whatever form you decide to use, start with personas. You might start by simply identifying roles such as Customer Service Rep, or Delivery Manager, or Nurse. From there, give them a personality – assign a photo to them, give them a name, a brief history of their experience, make a list of what frustrates them, what makes them happy, what their goals are – build a bit of a personality profile. Why? Because, as with characters in a book, the more developed the character (persona) the easier the story will be to write (user stories). More importantly, your stories will reflect the value of the persona and the user experience will be impacted as well. For example, how I’d write software for a persona that closely matches my mother would be much different for a persona the more closely matches someone who may be just coming out of school and has grown up with software and technology in all parts of their life.

Just for fun, here’s a persona. In this example, I’m targeting a Customer Service Rep – and at a particular fictitious company (Corpx.com) they found that they usually hire people right out of school – and generally have a high degree of turnaround.

Persona: Deborah, Customer Service Representative

• Deborah, who is a Customer Service Representative at Corpx.com just graduated from college in the spring and is eager to make a difference.
• Deborah wants to please every customer, always has a positive and perky attitude with everyone who calls. Deborah was recruited right out of college by Corpx.com where she studied office management, specifically office computing and is familiar with most Microsoft Office applications.
• Deborah wants instant access to a customer’s name, account status, and Customer Service history. Only by having a complete picture of a customer can she work with them on their needs and find opportunities to go above and beyond customer expectations. In fact, if this information can somehow be on her screen at the same time as her answering the call, this would make Deborah really happy.
• Deborah was taught keyboarding skills in high school and college is quite good at using the keyboard, and finds that having to use the mouse to “click on things” slows her down.
• Deborah’s manager Cheryl requires Deborah to record the duration of every call in her paper work log. Cheryl has used this method for the past 10 years successfully, however, Deborah thinks this is quite wasteful and not a great use of her time. If Deborah forgets to set the timer on a call, then she usually guesses at the amount of time she spent.

I took a more verbose method of defining Deborah, I’m sure you can do this in fewer words – however, I think you get the picture.

What did her persona tell us?

1. We should strive to layout the system to give Deborah the most context about a customer when they call
2. We should try to make the system less reliant on mouse interaction, geared more for the use of keyboard to navigate and enter data
3. We might try to find a way to pre-populate Deborah’s screen with customer information before Deborah answers the call – perhaps based on the customer phone number.
4. We should strive to make it easier for Deborah to record her call times while still making Cheryl happy – perhaps by automatically capturing the call time of the system.

Now, if we didn’t have some additional characteristics about the CSR, we might have fallen trap into putting ourselves into that role – which could result in an entirely different set of expectations and resulting approaches. It’s much too easy to visualize ourselves as the people using our software. Perhaps, we might have ended up with the following if we would have viewed ourselves in this role:

1. Use a wizard to gather information from the customer
2. Extensive use of the mouse for screen navigation – using window panels, tabs, sliders, etc.
3. Use extensive popup dialogs to display different types of information about a user
4. Keeping the screen very Web 2.0 influenced – simple, clean UI – not overly cluttered – yet not a lot of information displayed at once
5. Place a start call/end call button on the screen.

So, before you jump into your stories or use cases or Gherkin syntax for BDD – stop and build a profile of the roles that participate in those stories.  This can help you better understand value and direction.

Personas help us stay in the role of the observer, not the participant.