2. DEFINE – Establishing requirements of user through Personas + Scenarios

After analysing the raw data generated through in the empathy phase, it was now time to synthesis this data in a form that can be actionable and simply makes sense.  The define phase is important to the overall process as it results shared understanding of the problem that we are striving to address.

The were two key things we set out to define in the phase:

  • The users we are designing distilled into a persona
  • Insight into the user’s problem through a user scenarios

User Personas

Personas created were by Alan Cooper in the early nineties when he identify the need for a artefact that could easily encapsulate the observations by researcher and consolidate this information in an actionable form. Cooper, (2001) argues that personas engage a designers and developers when design software and help to create empathy when working towards users’ goals.

“Personas are not real people, but they represent them throughout the design process. They are hypothetical archetypes of actual users. Although they are imaginary, they are defined with significant rigor and precision.”

Taken from Alan Cooper’s  The Inmates Are Running The Asylum

Role

Persona development is a model that aims to encapsulate the qualitative data about our target user. Personas are an actionable image that act as a reference for designers that help them to guide them in making decisions when designing software. They illustrate various information about their target user in ways that other deliverables can’t.

Importance

Personas foster empathy. As a project team we could now replace ‘user’ with our personas name’s. We could talk about them with certainty of their motivations & goals. No longer were we designing blind but designing we the end user in mind. Personas allow designers to make informed design decisions.

Persona Creation

A outlined in a previous post, the persona was created through the analysis and synthesis of our user research data. You can read about this in detail in this post incase you missed it.

Introducing John, our Irish Rail leisure user.

Persona.jpg

This is John. He’s 26 and works in Cork as IT professional. John’s from Galway and goes home to visit family and friends usually once a month. John generally purchase his ticket in advance of travel often during work. He also does some planning through the Irish Rail website such as checking train times and prices. John also books a return ticket altogether he needs to flexibility because his plans might change. John expects booking a train online to be swift and simple, especially if he has to do it nearly every month. John is frustrated by the fact he needs to collect a physical ticket for a something he paid for online.  John also, finds it annoying when he does not get the seat he selected.

Putting our persona to use

We constantly referred to our persona when making various design decisions. Probably the most important time we referred to our persona was when we did our initial brainstorming session for coming up with new ideas.  For example, we being developed what we thought could be helpful features for John as a frequent user of Irish Rail.  Once we brainstormed all the ideas, we then assessed the how beneficial the feature might actually be or would it hinder his ability to carry out his primary task, which in our case was to book a return rail ticket.

IMG_8350.jpg
Our list of ideas that came from our brainstorming session

User Scenario

User scenarios are specific narratives of a personas in the context of your product.  Cooper et al, (2014) suggest that scenarios allow us to start our designs from a story describing an ideal experience from the persona’s perspective, focusing on people and how they think and behave, rather than on technology or business goals.

Defining a scenario through data

We began forming our user scenarios  once we had our survey results but we then refined the scenarios after speaking and observing our leisure users.

Scenario 1 – Booking a train

 

Scannable Document on 19 Jan 2017, 15_22_41.png
storyboard of the scenario 1 – John books his open return train ticket

“John travels home to Galway, to visit his family, one or two weekends a month. He’s always conscious that his plans may change last minute and he usually obtains a flexible return ticket to reflect this. He expects the train to be particularly busy on the weekends, and prefers to purchase a ticket online so that he can reserve his seat for the journey. He also likes to be able to plug in his laptop and to sit beside the window. He doesn’t like to spend more time than he needs to travelling, so will look for the express train. He finishes work on a Friday at 4pm and it takes him 30 minutes to reach the station. He doesn’t like to wait for long and so always likes to get the train closest to that time. He usually returns late on the Sunday evening, and likes to ride in a quiet carriage, hoping to catch a nap.”

Scenario 2 – Check return trains (live times)

It’s 5pm on Sunday evening and John hopes to catch the next train home. He wants to check when it is exactly, make sure that it is on time and he would also like to reserve a seat in a quiet carriage.

Defining Requirements from our user scenario

Now that we had our persona and our user scenario created it was then time to gather feature requirements based on the two scenarios.

Better seat selection

One of the major pain points of the existing website is the seat selection. Not only do users find the the process confusing, we learned that many find it frustrating when they select the wrong carriage or when the carriages are different layout to previous journeys.  With this, we redesigned the process of choose a seat by access the user to choose their seating preferences rather than a specific seat. We found through research our user interviews, that people often want a specific seat because they believe there to be power sockets at that seat for example.

Giving the users the freedom of an open return

From research we found, the open return is a ticket type that is commonly bought by leisure users, yet there is no facility to buy it only. When we look at our persona john and his scenario, he frequently travels Cork to Galway and often is unsure of his return plans. By giving the user the option of an open return ticket, the user gains a much better experience of the service.  

screenshot-2017-02-05-22-54-20

44% of our survey respondents say they would like to be able to buy open return tickets online

 

eTicket Facility

A common theme that appeared in our qualitative research was that it was necessary to collect a physical ticket for an online ticket purchase. We proposed an eTicket solution that could be accessed from the smartphone and would remove the need for John to panic about the queues for the ticket collection at the beginning of his Friday evening journey back to Galway.

eticket-outbound

We propose the ability to have an eTicket on your smartphone

Live Times

Live times was the top task carried out by our commuter user type. However, the link to that live departures is not given enough prominence on the page and as a result the users a forced to used the page purchase ticket form to view live times. This caused frustrations for some users as they said are presented with the entire times for that day, even for train times that have passed.

Our solution was to provide a jump off point that the user only needed to set the departing station and destination and then choose the ‘live times’ link. This brought them to a custom page with only the information they need i.e the next 4 trains and whether the train is on time or delayed.

By optimising this user task, we were able to answer needs of our commuter as well as our primary persona, the Leisure user.

This feeds directly into our scenario 2 as when John is about to make his journey back from Galway to cork and wants to quickly check the next train to catch and to ensure that to trains are running on time.

You can see the live times task in action here

Check Times & Save Journey

In our user scenario it’s evident that John would plan a journey before going ahead to book it. It is also evident that John makes the same journey monthly.  We came up with the facility of saving a journey so that that journey could be quickly accessed from the homepage when John is logged into his account.

 

You can view the video of this user task here

References

  1. Cooper, A. (2008) The Origin of Personas,  retrieved from https://www.cooper.com/journal/2008/05/the_origin_of_personas
  2. Cooper, A. (1999). The Inmates are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Indianapolis, IN: SAMS Press.
Advertisements