Application Teams Can Deliver A Better User Experience (Part 2: Personas and Scenarios)

In the previous post, we talked about the importance of user studies as part of your overall UX framework. In the second part of this series, I want to focus on personas and scenarios. Developing this step in your framework can feel a bit silly at times, but believe me — it is absolutely vital. Afterall, only a small portion of the overall user experience is actually observable. The user brings a lot to the moment of digital engagement at the point of UI. However, the further in time we move away from the moment of engagement, the less concrete our understanding of the customer becomes. We can observe their behavior leading up to, during, and shortly after the point of contact, but there is a nearly endless array of external factors that influence behavior that we have very little insight into.

This reveals a major cause of poor UX: providers of the experience fail to understand, and therefore address, the needs and factors that affect their customers. Why? Because giving your customers what they ask for is easy — and often useless. But challenging that paradigm and figuring out what will actually improve outcomes is really hard. Personas and scenarios can help.

Most of you are probably pretty familiar with what a persona and a scenario is so I won’t go into great detail here. Let’s just briefly agree that at a high level, personas are generic descriptions of user types, and scenarios are simple stories designed to give context to why and how customers will use your application. Together, they attempt to help us understand all those external factors that influence user behavior and focus development on real user needs.


Essentially, personas exist to facilitate discussion about project focus. Without a shared agreement on the target personas for a given project, delivery teams will make many decisions throughout the design and development of a project without any consideration for a particular type of user.

To avoid this, personas for a project should be created by UX professionals as part of the ideation phase (before requirements) to provide clear direction for scoping and requirements gathering. Where data is light, UX teams can harvest information about users from marketing professionals and customer service groups. The results from your user studies (discussed in part 1 of this series) may also be used to refine personas. Understand that your personas should be loose, with room to change and adapt as necessary. That way, they can be constantly refined and honed as your understanding of your customers grows.

Good personas provide enough specificity to guide design decisions. Usually, this means they include information about a user’s occupation, age and device preferences, as well as any other information seen as valuable through UX activities. The goal is to capture enough detail to bring the user to life but also to remain general enough to make the details broadly applicable. As a politically incorrect saying goes, “stereotypes are real time savers!” An example of such a persona follows:

  • Mary is 34 years old, works from 9 a.m. to 6 p.m. and has three school-age children. She loves her iPhone and wishes she never had to use another device. She likes to play games, uses Facebook way too much, and actively keeps tabs on her kids.
  • Mary struggles with maintaining the balance between home and work. Her common feeling is one of guilt — guilt that she can’t dedicate more time at work and guilt that she isn’t spending enough time in the upbringing of her children. She loves both facets of her life but is resentful that she’s in a situation where she is doing both in a mediocre fashion — an anathema to someone who has dedicated her life to the pursuit of excellence.

As you can see, in the above example we give Mary enough definition that she seems like a real person, while simultaneously staying vague enough that she could represent a relatively large segment of your user-base. TIP:Giving each persona a real name will make discussions about users simpler and will help you avoid anonymous statements such as, “Users will never be able to figure this out.”

In fact, for teams new to creating personas, the value is often first made obvious when a sponsor requests a new feature and a stakeholder asks, “Which personas is that for?” By forcing the conversation to involve personas, and avoiding the tendency to talk about an anonymous “elastic user” (who wants anything and everything), teams gain valuable focal points for all discussions about features, designs and bugs throughout a project’s entire life cycle. TIP:Personas should be printed and posted in meeting rooms where these discussions take place. The names given to personas should appear in use cases, trouble tickets and even in source code comments. The value of personas is as much a factor of their publicity as their quality.


Good personas help by giving context to decisions. Scenarios take this a step further by placing a persona in a short narrative to provide additional context. These narratives should include the task a user wishes to carry out and why, the physical setting in which the task is performed, what the user is doing before the task is performed, how the user performs the task, and what the user does after completing the task. This seems like a lot of detail, but consider the following example:

  • Mary is paying her utility bill. Because she works until 6 p.m., she is accessing the website in the evening, after the support department has closed. She has kids and doesn’t want to bother kicking them off the computer, so she uses her iPhone to pay the bill, usually in bed while watching television. She doesn’t always pay from the same account, sometimes using a credit card and other times using a checking account. Once finished, Mary will probably head to Facebook or read a book.

At first, all this information may seem like overkill. But including this level of detail can really help you design an experience that meets the users needs and feels effortless and natural in the context of their real lives. The team knows that mobile capability and after-hours task completion will be critical. A workflow that eases the entry of account information will help with entering different payment details each time. The team might gather more information from the persona, such as the fact that Mary uses Facebook and might not have a personal email address for delivery of a receipt, or that favoring the mobile device might make certain payment options preferable to others.

Combined with personas, scenarios tell a story in a way that reminds stakeholders why they are building certain functionality and for whom. Personas and scenarios help to clearly tie project deliverables to underlying business value in a way that is rarely captured in requirements or use cases alone.

These artifacts can go a long way toward helping contributors both envision the user experience and uncover ways to improve it, as well as discover new opportunities for ROI that may not exist in typical requirements. Scenarios also provide a means of testing the work in progress: “Would Mary use this to pay her bill?” The inclusion of context before and after task completion can help identify ways to improve the findability of applications based on how users arrived at the applications.

Personas and scenarios offer benefits beyond design and development. Knowing how users arrive at an application and the setting in which they perform a task should guide testing of the application. For example, where scenarios expect most users to arrive at an application from a search engine, the behavior of searching, deep linking and subsequent task execution should be fully tested. Was the application easy to find? Once found, did it work as expected even though the user arrives from a search engine?

How Personas and Scenarios Fit In Your Frameword

Personas and scenarios can and should be used alongside the other practices described in this series. Prototyping sessions require that some understanding of users exist, and those sessions can often be a catalyst force for the creation of personas and scenarios. With pre-existing personas and scenarios, prototyping sessions can focus entirely on a single scenario and its persona. The resulting diagrams will represent workflows and layouts that benefit from information about the user and the story contained in the scenario, thus making the prototype far more targeted and thoughtful than a workflow created without such context.

Similarly, user studies should focus on real individuals that align with created personas, and they can re-create settings and stories that exist in scenarios. In addition, user studies can and should determine personas and scenarios based on the information found while teams engage with real users and observe their interactions with the software.

This post is the second in a five part series. Next: Application Teams Can Deliver A Better User Experience (Part 3: Managing Scope)