How to write a UX Story
In 2006, Heidi Tran & Brianna Cry, two preschool girls, met on a dinner cruise in Hawaii. They immediately bonded for one night but lost touch for 12 whole years. It was on a whim that Brianna posted the photo on Twitter, with the hope of finding a long lost friend — and it went viral overnight.
Within 12 hours, there were over 1000 retweets and eventually Heidi and Brianna were reunited. With a little help from Ellen DeGeneres — who of course found the story interesting enough to make it to her show.
Stories like this are really inspirational, and interestingly enough they involve software products. But when we write user stories, do we think about scenarios like these?
Maybe we should.
Are our User Stories boring?
Writing out user stories and scenarios is an important part of the product development process. It is not possible to build a good user experience without knowing how the user will interact with the product. And there is no better way to do this, than by weaving a story around the whole process.
A well thought out UX process might include one or more of these stages:
User Studies
Persona Development
Stories and Scenarios
Wireframes
Visual Design
User Testing
While this is an excellent process for a linear development process, it may not really work well when the development process is designed to work much faster. Agile and Lean development methodologies demand much faster and iterative models for developing the user experience.
Enter UX-Storytelling.
Good beginnings — The Draft.
As with all stories, the UX-Story begins with a draft. A draft basically sets the premise on which the story would be built. You can hack out the drafts between the first meeting with the product team. Quickly discuss who you are building the product out for. The users, the target demographic, etc.
Is it a stressed-out marketing team? Or a distributed design team? Or is it just a businessman trying to get to his meeting on time?
Your draft is basically the reason you are building your product and should be able to in a short paragraph be able to get the need for the product across.
Do you need user research?
Yes you do. A lot of times, we you may know the reason why you are building a product, but it still is important to do the right research. It might be good to understand the day in the life of a busy salesperson who needs to rush from meeting to meeting. Or exactly how a media spread is decided by the marketing team. These are insights that help you add more details to your story and to the product.
And by the way, research need not be expensive. But do the desired research or search for relevant research that will keep your design informed.
Next, define the personas…
You story needs character. And that’s what personas provide.
Personas are important tools to keep the design from becoming too elastic and all encompassing. The persona brings the team back to reality by validating the needs and making sure the team does not stray too much from the core values of the product being built.
Personas are also good internal communication tools. Make your persona familiar enough and you just have to ask the question: “Will Alan (the persona) use this feature?” to get the team thinking about the need for the feature. And since developing the user experience is all about humanizing the development process, there is nothing like a persona to help the team develop empathy for the user.
There are a number of tutorials online about developing personas and you can read about it, but my personal opinion is not to make a big deal about the persona but keep it a broad work in progress. However come to a quick understanding on the user goals and values. Once you have focussed on the user values, don’t change them.
For example, you may have developed a persona for a leadership team member and one of the values being that she does not have a lot of time as apart from being a board member, she is the CEO of her own company. This is a core value and should not be changed even if you develop the persona at a later stage.
By the way, it is not just the basic demographic details that make up a persona. A vigilante who has not fallen into a bat cave does not become Batman. It is the backstory, the motivation and the goals that will bring your persona to life and make him relatable.
Once a persona is built, the next to build is the plot.
The meat of the story. The context and the plot.
Define the circumstances in which the story takes place. The place, the time and social context. Providing an environment for the story aids in understanding where the designed experience fits in. This context can also act as the starting point from which the plot can be built — it can be the source of story conflict or obstacles that the character must face before achieving his goal.
The right context gives your audience something concrete to buy into. For example, imagine a busy father. If this character is surrounded with context such as a barking dog, full hands, and a sick baby, the team can understand the environment that it must design for: chaos, high stress, and little time.
A plot describes a series of events along a timeline. Often, these events build tension and crisis as the main character (the user) heads towards the climax in the story.
The Value Filter
Run the plot through the value filter.
They context should fit in with the values that you are basing your design upon. Let’s say your value is to help the Salesperson communicate better, first ask WHY you would want the salesperson to be in the context you define. If it passes the WHY filter and then define the HOW. This is done by defining the UX scenario.
The scenario
Once the context and the plot is figured out you could have multiple scenarios that the main protagonists of your UX-story carry out.
You can add more literal flourish into your story but a skeletal story should include the following:
The intent: Why did you persona think about doing this in the first place. This gives you a good idea of what are the things going on in the character’s mind as they got to perform a task. Intents could be either explicit or vague.
Trigger: Explicit intents may not require triggers, however when the intention is on the back of a person’s mind it is usually an external trigger that could make them perform a task.
Action: The action define the next step taken by the user and usually will the starting point for the scenario
Path: The path will define the way the user finally achieves the task. There could be multiple paths that the user can take for a particular scenario.
Completion: Most scenarios end with the path, but it is good to define a follow up so that the scenario is complete and can lead to follow up scenarios if required.
Build multiple scenarios and use the Intent, Trigger, Action, Path & Completion framework to describe each scenario. And once these are do you have the beginning of a UX story.
The takeaway from the story
Now that you have the Why and the How for the story defined, you need to identify WHAT are the various elements you need to design. To do this list out the verbs and actions from the story. They become your items to focus on.
Iterative process
Start small, so that you can quickly get an idea of where you are going. Also share often so that everybody on the team is up to speed with where things are heading. If you want to be thorough with this you can make this into a novel or even a comic book, but remember this is just a tool to deliver the final deliverable which is the UI. So see how much of the bells and whistles you want to add to this part of the process.
