Creating effective user stories

Thinking in stories

User stories are designed to give the designer more information about the audience and a specific user for use in critiquing and rationalising the project. They are high level and supply the designer with the basic information on the user. Detailed information is left closer to implementation of the story. The story should reflect the need of the user better later on in the process, hence deferring the details. 

The key thing to remember about user stories is that they are flexible. They can and should change as the app and story develops. They are placeholders for conversation and should be used in place of traditional checklist type systems. This user-centric story method will allow us to understand where user wants fit into the product and if they are solving actual problems. 

User story framework:

“As a…” (Role)

“I want to…” 

“So that…” (Goal)

When creating a user story there are two different methods; stickies vs project management software. Here are the benefits of both:

• Stickies are more tangible, more flexible and promote greater creativity. They can be moved, changed and interacted with in order to create a more physical and therefore realistic story.

• E-tools are better for archiving and storage but this is project dependant.

For me the biggest reason for choosing between the two is whether you are working in a team and what sort of team that is. I think stickies are the best way to create a user story and the method I would use. Photographing and saving these allows for archiving but flexibility. If you are working in a team then it will depend on the environment you work in but generally I would push to use stickies as the creation of journey maps and user stories is much more tangible.

Creating user stories

Creating user stories can be very useful for rationalising decision made throughout the design process. One key aspect to learn are roles and what they mean in order to make the user story much more powerful. 

Role: this represents a group of users rather than individuals. It is derived from characteristics of that group and their interest in the product. E.g. Owner, Customer, Service people etc.

Stories can be difficult to make; too little detail, too much details etc. Using the INVEST structure allows you to evaluate the story you have made and validate that it is good enough to use.

I.N.V.E.S.T:

Independent; the story is self contained and doesn’t require other stories or more information to stand on its own.

Negotiable; the story can be changed and rewritten.

Valuable; the story shows the value to the end user (role).

Estimate-able; This story should be small and defined enough to create a feel for what will be required to complete it. 

Small; This story should be manageable.

Testable; The story should be tested to prove that it can be implemented, end result is key to understanding where to go next.

Epics:

Epics are a combination of multiple user stories where each one has to be completed to achieve the end goal. Epics allow us to capture a large workflow of related stories that a single team can tackle. By breaking stories into steps it makes each one clearer and highlights gaps and deficiencies. Each step is a story under the umbrella of an Epic. Epics capture the complete workflow towards a goal, once all stories are complete you have solved that problem. This can also cater to multiple users.

Themes:

Themes are similar to epics but they are related by association and can be solved independently. These do not capture a workflow but are related to each other under similar themes.

Personas

Personas are fictional characters that represent the user of our application. Whereas roles represent a group of users personas represent an individual. They create a backstory for the role and can be used to differentiate between similar roles.

When you make a persona make sure that you only make them for frequently used roles as these are the most important. Relationship mapping to find who the key users are can help with this. You can identify new users, highlight interactions between users and show the influence between users and different spheres. Within this there are usually two different type of user; choosers who pay for the system/ product and user who use the system (i.e. service people).

Below is an example persona that I have created for a user of the sports app Strava.