Take a look at this common template used to describe User Stories:
"As a <role>, I want <goal/desire> so that <benefit>"
Here is an example of this template in use:
“As a Project Manager I want to view the status of my project so that I can understand if we need to change the plan in order to hit our goals”
Here is a template used in BDD that is part of helping to specify the feature and associated scenarios (as part of the Gherkin language)
Feature: <Feature Name>As a <role>I want <feature>
so that <business value>
Here is an example of this in action:
“Feature: Shovel SnowAs a Home OwnerI want to Shovel Snow
So that I can get out of my driveway to get to work”
(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
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 “
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
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?
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:
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.
Subscribe to be the first to get our expert-written articles and tutorials for developers!