User Stories done by UX Designers

Initial Situation

When approaching the requirements engineering space (or workshops) it is indispensable to define and write down all user stories for any application.
A user story is a tiny piece of a stable fundament of a successful application according to design, function and its process.

Actually a story is just the written definition of a UX Designer’s first visualization of the first wireframes and prototypes.

First approach is visual

The better it is written the better you reach the full impact of a successful user experience. But who is in charge in writing these stories? What is the best role to understand and define users’ needs and wants?

First visual approach that needs to be transformed into an objective text

In our Requirements Engineering Workshop we visualize as fast as possible to create and define a common picture of all stakeholders. Of course this is often done by UX Designers ;)

“… while scribbling a first idea (screen) it is our task to see the functional and visual behavior of a screen back in your mind – you are the best in charge to live and explain it seamlessly!”

First Scribbles of Key Screens and its flow to create a common picture

And it is also up to you to turn this screen into a living context of the entire future application.

Sections of the future applications need to be explained in tickets

When the whiteboard is full of screens (scribbles) that combine and visualize a first user journey (made of many user stories) there is this moment to turn these picture into written words and to prepare the tickets for a future development.

The necessary Siblings of a User Story

A user story does not work alone – it needs additional information to understand the whole context of a process or just a small part of it.
The siblings are called “Acceptance Criteria”, “Dependencies” and “UX-Artefacts”.

When writing a UserStory-Ticket for the BackLog there is always the same structure – just see an example:

All other aspects of a successful User Story

User Story

The user wants to see a basic navigation of the application to reach every section of the app.

Acceptance Criteria

• The navigation is always on the bottom of the app
• It stays sticky when scrolling down and/or up
• It is visible on every screen except the “Onboarding”-Process
• See Customer’s Design-System for pattern behaviour (hover, (in)active, visited, …)

Dependencies

• Marketing of <Customer> needs to provide Icons for each section

UX-Artefacts

• InVision Flow:
  <Scribbles, Wireframes or Mockups Link>,
  Single Screen or Process-Prototype to understand the click-/process-flow
• Abstract Mockup:
  <Relevant UIs Link> for Developers to identify necessary code

This ticket structure helps to understand the full context of a user story.
It also creates a common picture for your customer, the designer and the developers. This ticket is only ready for a sprint when all sections are provided with useful content.

When writing the first ticket there will be more to follow

It could be that it took a few days to describe the whole app – but it’s going to be worth it!

Challenge (yourself) and Improve your concept

When explaining your scribbles of each screen in detail you will be able to challenge your concept;

Identify gaps between your customer’s expectation and your wish to focus the best UX. But make sure you get the support of your development and project management team before creating a utopian UX behavior – according to time, budget and man power. But by writing every story you will get a feeling of it ;)

When you get the support of the team the you are finally able to show/introduce this ticket to your customer without any bad feelings – and without any bad surprises in the future.

Now it is up to the customer to “sign” this ticket and make it ready for development or a following sprint.

It could be that you have to polish this ticket a few times to make this User Story successful. But it is worth it! Just make sure to reach the awareness of everyone.

The more detailed a User Story is written the more exactly you can estimate the efforts of development.

Small gap between Design and Development

We know developers are more into words and numbers ;) “just kidding!” but the earlier you challenge and proof your concept with the development the earlier you get this components implemented as you want.

Defined components in a Design-System

In one of my project I learned a lot in the famous “Frank-Gate”. Frank is a developer who transformed my designs into code. He asked every question that is possible to ask in every ticket. He also taught not only showing a happy path of a UI but also the worst cases of a display. This helped a lot to polish and define your tickets wisely to every tiny detail.

My Experience as a UX-Designer

What I like and love as a UX-Designer (and why I switched from an Art-Director into a UX-Designer) is having logical process behind every application.

It is not worth having an awesome and overwhelming UI without a logical process in the back. According to best practices of different UX behaviors and patterns the design is “almost” done. It is your design task to communicate the brand of your customer in these patterns and components. (As a former Art Director for brand communication an easy task to fulfill ;)

So in my opinion the best role to initially create user stories is a UX Designer –but he is lost without the support of his team.