So what are these ‘simple user stories’ anyway?
It’s really simple. Imagine you want to design one particular important screen in a new app you are developing. Let’s imagine it’s an app for controlling time (just making sure that I’m not breaking any NDAs we might have by doing a totally made up thing).
You conduct your user research, competitive analysis, crystal ball divination – basically, you gather all the data about pain points, needs, requirements, hopes, fears and time vortexes and come up with something like this (let’s call it a simple priority list):
Homepage:
Date and Time
Time control
- forward
- backward
- pause
Bottom menu:
- home
- time travel log
- initiate time jump
- profile / settings
Now this sort of distilled list would be a better basis for your designs than just starting to sketch out ideas while trying to remember what you researched. I do however propose a simple technique that might help you out.
Use simple stories to approach your design requirements:
1. For the home page content:
As a time traveller my main reason for opening the app is to move time forward when I’m bored and back when I messed something up.
I also need to be able to stop time at a whim. This is usually spontaneous so I need this pause control to be big enough and reachable with my thumb.
I need to have absolute knowledge of what time and date it is right now so it would be nice to have it present at all times, so I don’t get lost in time.
2. To describe the main navigation:
When using the app I’m mostly interested in the main, simple time controls but more often than not I need to initiate a more precise time jump.
I’m also quite interested in what periods of time I have traveled so it would be nice to have this information available in a simple timeline (pun intended).
I also want to access my settings quite often, because my time traveling requirements change frequently.
And I want a quick way to log out so that my children won’t mess up the time space continuum by accident when playing games on my phone.
3. Even to describe some basic design principles:
When I travel through the time continuum vortex it is difficult to read because reality becomes super wobbly. The text and action buttons should be quite big so it’s easy for me to distinguish between them on the go.
After doing this you can have some of your users read the stories and ask them if there’s anything they would add or anything that does not resonate with them and adjust.
The main benefits of using the stories to design
You can test the story.
You can take the story and have some of your users read it and ask them if there’s anything they would add or anything that does not resonate with them and adjust it accordingly. This allows you to test even before sketching out a line.
It’s much easier to be understood by non designer stakeholders.
It’s simple language. It says what the user wants. Anyone – ranging from developers to C-level executives – should easily understand what you are about to design and be able to contribute their opinion.
It’s not as strict as a list and gives you more freedom when designing.
See how we put the profile / settings in the bottom menu in the list because it seemed like a good idea? Well maybe it isn’t. Maybe you could put it in the top right corner.
When doing the list you would be naturally inclined to have it structured and thus structure it too rigidly just because your brain wants the list to be more organized. The story is an evolving thing. It does not dictate form.
You don’t have to go back to your research notes and you don’t lose context.
Because we add context within the stories you have the reasons why something should be the way it is and you can naturally link it to what you found out in user research. We can call ourselves UX designers because we empathize with the users – and the users don’t speak in lists and spreadsheets. They use natural language. It’s much easier to cross check a requirement with the findings from our research if the language used is the same.
It’s more fun to write stories than to produce lists and spreadsheets.
Yeah. This one speaks for itself.
To finish this up
Try it out. Use your own style of language. Let your thoughts flow into the text and organize it later. You will also notice that this technique could also be applied not only to particular screens but to the application as a whole. You could even try to apply it to more abstract topics like strategy if you wish so.
I’m a huge proponent of simple language and we’re lucky to have cool clients that don’t care much about form. From my experience, rigid reports and lists are useless and boring to read (and I’m pretty sure they won’t be read), difficult to understand and thus a complete waste of time and resources.
