How personas and scenarios can change your website for the better - Part 2

— Published March 31st, 2006  |  by John Wood

What are scenarios?

In a nutshell, scenarios are simply stories about what your users do on your website or about the context in which they use your website. Of course, there is much more to the technique than writing fiction.

In About Face: The Essentials of Interaction Design, Alan Cooper and Robert Reimann define a number of different types of scenarios used at different stages of the design process. The most important ones are:

• Context scenarios – these contain the important contextual details for each persona. Where is the persona using your website? What are they trying to achieve? Why? And what prejudices and mental models do they bring to the encounter?
• Key path scenarios - these are narratives that describe a persona using the website to accomplish the most common tasks in the most usual way.
• Key path variants - these narratives describe personas performing tasks in less common ways or with variant outcomes, for example what happens when log-in fails for some reason?

Together, these types of scenarios enable you to build a very comprehensive picture of user behaviour on your website.

What do scenarios look like?

A scenario is usually written in the form of a narrative. This format has a number of advantages, which I will cover below. Some people avoid writing narratives, using lists instead to describe a user path through a website or the characteristics of a persona’s context. Although lists are a handy shortcut, narratives offer advantages that make the little extra effort required worthwhile.

What are the advantages of using scenarios?

Scenarios enable you to explore what it is like to use your website (or what it should be like) in a quick and cheap format. This enables you to define the requirements for the website and design aspects of the user experience without writing a single line of code. This technique also enables you to find potential problems in a design or opportunities for improving the design before you have committed significant resources to design and development.

The narrative format also makes it easier to communicate and understand these requirements. People understand personas better than user profile data because they have an innate ability to relate to other people. Similarly, most human communication takes the form of narrative, so your team has an innate ability to digest narrative much more readily than pages of system requirements.

Case study 1: Drowning in data

Let’s look at a case study in which we applied personas and scenarios to help a customer who was drowning in data, one of the common problems we highlighted in part one . Our client was a large public sector body in the UK, who were planning the development of a multi-million pound web application to provide services to the public.

Our client’s goal was to reach members of the public who were less likely to avail of their services through more traditional channels. However, they were unsure whether the system they were planning would serve the people they wanted to reach. They had masses of data on the users of their services, including survey data, website traffic analysis, interviews with the public, reports on the experiences of their public-facing staff and so on.

We set about analysing this data to construct a set of personas and scenarios that would help them make sense of it all. This exercise helped them conclude that the people they wanted to reach were very unlikely to turn to the web to access their services. But we also helped identify a set of users who were in close contact with their target audience and who were likely to act as intermediaries. Our conclusions? Design the website for these intermediaries, not for the people you want to reach.

Case study 2: Casting the net too wide

Our second client was a public agency based in Ireland, providing scientific services to government, industry, universities and the general public. Their problem is an example of casting the net too wide, trying to design a website for everyone. As we saw in part one , this effectively equates to designing for no one in particular.

They approached iQ Content to discover why people found it so difficult to find anything on their website. As always, our first step was to create a set of personas that described the users of their website and their behaviours.

This exercise produced many useful revelations. Most importantly, we were able to show them that the information architecture of their website – the way the information was organised and labelled – was unsuited to serving the very diverse audience their website was aimed at. We were able to apply this knowledge during the redesign of the website to provide a navigation system that worked for the specific needs of each of their primary personas while actually reducing the number of categories and the complexity of the website.

Conclusion

The key challenge in designing a website – or any piece of software – is to separate the probable from the possible. There are many things your users might do and if you have no way of knowing which ones are more likely than others then your design process is reduced to mere guess work. Personas and scenarios enable you to remove that guesswork from the process and target your time, effort and money on getting the design right the first time.