We’re all familiar with the standard User Story format:
As a [user type], I would like [functionality] so that [business justification].
A good Scrum team is more than capable of interpreting the functionality requested by the Product Owner. Furthermore, a Product Owner in-tuned with the business’ initiatives can effectively articulate the business justification which influences, if not drives, the stories priority. Often times the first component, the user, is glossed over, generalized into vague categories such as Customer, Admin, Merchant, Shopper and never really given a second thought during the conversations in planning.
Why is to so important to look at the user? As the old adage states “The customer is always right,” and the customer should come first – even though they are not always right. User-Centered Design mandates that users and their desires, tendencies and limitations be given top priority when designing a solution. This attention should not end at design. Aren’t we really still designing throughout the process? We learn more as we elaborate on a story, test in code as well as QA then analyze and adjust accordingly. It’s no accident that these defined units of functionality are called User Stories and not Functional Stories or Business Stories.
So let’s take a closer look at who these silhouetted faces are that we call users and how they influence our design decisions through the use of personas.
Alan Cooper, Father of Visual Basic, developed the concept of personas in 1995 and popularized it in his book The Inmates Are Running the Asylum.’
What exactly are personas? In his course on Human-Computer Interaction, Stanford professor Scott Klemmer explains personas as:
A model of a person, an example
– includes demographic information, but should also capture a person’s motivations, beliefs, intentions behavior and goal
Professor Klemmer then instructs his students to:
Draw a picture of the persona or use a photo
– include a name, occupation, background, social situation, hopes, dreams, goals etc. give them a story to tell
Knowing what a persona thinks, does, and feel help build empathy
– to help us understand their state of mind, emotion, philosophy, beliefs, or point of view
Empathy leads to insight which leads to design opportunities
In User-Centered Design, personas help inform the design team of the appropriate screen layouts, interaction flows and even visual designs that are best suited to the persona. The personas are often times posted in a common area of the studio as a constant reminder of their target audience. Here’s where personas can help spread empathy into the Agile process. Tightly integrated UX and Agile teams share this method by posting personas near their Scrum or Kanban boards.
It then becomes a common practice in planning meetings and stand-ups to ask “How would Bob react to this change?” or “Would Margaret find this change in flow cumbersome?” In the end, conversations such as these have more merit towards a successful product than “Will we need to break up the web service for that feature?” or “The functionality will be there but can the UI be a shell in order for us to make the end of the sprint?” Don’t get me wrong, technical conversations are essential to releasable software, but not at the expense of user experience.
As an alternative to the default approach of casting our users in User Stories in vague descriptors as “Retail customer…,” try employing the persona.
“As Sr Manager Margaret, I would like to easily search for inspirational reference material on my mobile device so that I can offer suggestions to my editorial staff on the go.”
Using personas in User Stories during planning and stand-ups and posting the personas near the Scrum board can help reinforce to the team that their efforts and hard work are not for an end-user automaton. Rather it is for a real person with the same expectations, desires and frustrations as theirs.
Here are some references for designing meaningful and insightful personas: