Why visual user stories are better than the traditional user stories?

In the world of molecules and compounds, a user story is an atom. It’s the smallest part of product development from where things start taking shape.

A good user story is clear, concise, and focussed on the user’s pain points. It has the power to compel designers and developers to leave their assumptions and understand the problem.

One of the most common ways of writing a good user story is through words– write what you know about the product/feature. The purpose of writing a user story is to break down larger chunks into small stories so that they can be picked for development.

A typical way of writing a user story and its acceptance criteria is–

User Story: As a <persona>, I would like to <action>, so that <outcome>

Acceptance Criteria: Given that <persona> would like to <action>, when he/she performs the <action>, then the application should be able to <>.

The acceptance criteria accompany a user story to help the development and QA team visualize how the built feature would appear to the end-user.

On the surface, this looks very simple. But as the product’s complexity increases, user stories often fail to communicate well. I find the traditional form of writing user stories to be bland and ineffective. If not written well, it doesn’t inspire designers, engineers, or product managers to create something worth value. And when the team isn’t excited about understanding user stories, you can imagine what kind of product would be built.

To make sure the user story is well understood and ready for the team members to work on, we, at Quovantis, started a new way of crafting them. We call them- Visual User Stories.

Visual stories are low-fidelity workflow diagrams that reflect the who, what, and why components of the story. Some of the features of visual user stories are-

• They show the impact of a particular feature on different elements of the product.
• They show the flow of the interactions between the user and the product (Mobile/Web-App).
• They reflect on the various use cases that are needed to be handled.
• They are easy to split. In visual user stories, the feature can be divided into granular tasks that the team needs to perform before marking it as ‘Done’.
• The developers can envision the end-to-end interactions. It makes their job easier by defining the tasks that need to be performed on the frontend and backend, thus making it easier for them to formulate the implementation process.
• The QA team can reflect on the edge cases that may arise when users interact with the product. This proves helpful to them in writing clear and structured test cases quickly.
• Since the user story is visual, the team can easily estimate how much effort and time will be required to deliver the user story by looking at the workflow — helping them prevent any spill at the end of the sprint.
• They bring granularity to the feature and help developers understand the dependencies if any, and therefore, build the feature in increments throughout the sprint.

Here’s an example:

Textual user story

As an existing user, I would like to update my app, so that I can explore new offers and features in the app.

Visual user story

Whoever said a picture is worth a thousand words’ was right. Visual stories grab attention and developers are more likely to see the ‘why’ behind that particular feature of the product. They are especially useful when you’re writing down stories for a complex domain such as healthcare.

Consider this user story for an online pharmacy– as a pharmacist, I want to inform doctors about the refill of specific medicines at my pharmacy. In case they want to prescribe a particular medicine, I want to inform them about an alternative, so they can make better decisions while prescribing medicines.

The story mentioned above defines the who– the user, what– the action he/she wants to perform, and why– the benefit they will get out of that feature. But, sometimes, the old style of writing user stories lacks the following key components.

Value: It is hard to envision the value it is adding in a user’s life. How would it benefit the pharmacist? Why is this such a crucial feature to implement? What are the challenges that we will solve with this feature?

Dependency: Can it be implemented independently without other user stories? What is the impact of this user story on other stories?

Time and effort estimation: Can designers, developers, and QA understand the complexity level by reading the user story and estimate the time and efforts required to design, develop, and test it?

Scalable: Can it be delivered in an incremental way within the sprint?.

Testability: After reading the user story, can a QA think of every single use case/scenario to test it? Is the user story self-explanatory or does QA need more information?

Advantages of visual user stories

Keeps the team focused on the user- A single user-story can describe the feature, but they solve users’ problems only when they combine. Visual stories reflect the product’s vision, helping the team understand the overall goal and delivering a delightful experience to the user.

Promotes collaboration among the team members– When the goal is defined, it helps the team members rally together to build a product that can solve users’ pain points.

Leads to creative thinking- Visual user stories do not just define the feature but prompt the team members to think critically about different scenarios reflected in the story, the workflow, and the interaction. Sometimes, it also helps foresee gaps in the implementation.

Promotes small wins– Building small features of a huge product brings confidence in the team members, helps them gain momentum, and increases the team’s overall velocity of deliverables.

Developer-friendly– Visual user stories make it easier for developers to understand the vision of the product. Visual stories help reduce the dependency of the product manager in assisting them to understand the complete picture. In my team, visual stories have made it easier for the developers to write unit test cases because they can see the impact of one story on another.

I discovered visual user stories a while ago. And since then, there is no going back.

I use Whimsical or Lucidchart interchangeably to create visual stories. It’s more time-consuming than writing traditional stories, but also more rewarding. Visual storytelling has helped my team do more accurate estimations. I have also observed that the impact analysis has become a lot easier and efficient.

And when these small processes become efficient, everything else starts falling into the right place.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.