Another “Pay it forward” post. Someone asked this question today and after providing them with the answer I was grimly reminded of how little professionals fail to include these UX activities in their web or application projects. When I first started out in this industry I didn’t understand the power of how Storyboard, User Story and User Journey can influence your end product. I soon learned my lesson as I got to grips with animation early in my career and now, I include this stage as a default in my projects.
All three definitions, Storyboard, User Story and User Journey are crucial in my opinion to the planning and production of whatever it is you are creating in the web, web anime or video world. But what is the difference between them and do you need to include these in your projects?
Let’s briefly run through what each of these mean.
It’s a graphical representation of how your web app / video / or anime piece will play out. Visually showing what, when and how it happens.
This is a concise description from the perspective of the user of how they will achieve a particular task. For example; “As a ‘type of user’, I want ‘some goal’ so that ‘some reason’.”
This is a described series of steps that show how a typical user would interact with the web app that is being designed.
How a User Story is Different from a User Journey
Again this does depend on the context of its usage but a User Story in my experience is based on a specific user, so this could cater for a particular type of user to answer a specific problem whereas a User Journey can be a random user that may use the web app. This also includes Dynamic User Journey Scenarios.
Note: Based on context, a User Journey and Story can be one and the same.
Why do you need to consider including these activities in your projects?
For Storyboards there are a few good reasons:
- It’s a great way to visualise your plans to others
- It makes the production of your project easier
- It saves you time in the long run
A User Story has good supporting use cases as well:
- Useful for planning
- Great for time constrained projects providing only high level information
- Avoids including too much detail too early in the project
- Does not box in other team members (e.g., developers)
The same goes for a User Journey:
- Better understand perception and performance of a product
- Better understand user behaviour
- Identify possible high level functionality
- Helps in defining your taxonomy and interface
- Provides confidence that the end solution is created around and for real people
Ultimately when considering including these activities in your projects, also think about the creative people you will also need to include in the early on discussions, such as the Designers, the Information Architects and of course the User Experience specialists.