User stories: the best way to secure your requirements
in a user-centred way


You might have heard the term before: user stories. If you haven’t, I am sure this post will help you on your way in defining new digital solutions. Not only will user stories help you to recognize what factors are important for your business, but they will also enable you to map out the needs and demands from a user’s point of view.

I have watched projects fail when by all accounts, they shouldn’t have. In 90% of the cases, the reason is that the user requirements hadn’t been met. The cause for that could be budget-related, or the fact that people are not aware of how important it is to have a solid requirement specification from the beginning. User stories will help you gathering requirements in a structured manner. You have to look on user stories as drawings an architect prepares before the constructor actually builds the house. User stories can make sure that you, your stakeholders and your digital agency all align on how a new digital solution should be build. Therefore, the requirements should be as easy to read and understand as possible, and that’s why we recommend user stories instead of long functional specification documents that could be printed like heavy phonebooks.

We all think differently. While developers are often logical thinkers, designers might be more focused on visuals, while a project manager might focus on time and numbers. In order to help all of them to understand user requirements, I recommend using some time on the technique of user stories.

What is a user story?

A user story describes a small piece of system functionality in a simple sentence. A well-written user story will describe what the desired functionality is, whom it is for, and why it is useful. All key ingredients that differ greatly, and the final requirements of your ‘users’ will not only be different from patient to prescriber to payer, but will also differ from clinical areas to countries.

There are 3 parts to a solid user story, which in marketing are defined as the “3 C’s”: the card, the conversation, and the confirmation.

The card

A typical user story follows this template:
“As a [user], I want [function], so that [value]”

Having this easy of a template allows anyone involved with the project to help write them - from sales, business managers, to designers, developers and testers, all the way through to clients or users.

We refer to this as the “card” because they are usually written on 3×5 bits of plain cards, usually giving a physical constraint that limits the possible length of the story. You can also easily use post-its.

Here is an example:
“As a patient, I want to get an overview of my medicine consumption, so that I am aware of what kind and how much medication I take.”

The conversation

The conversation is an open dialogue between all the project members, ranging from developers, designers, to testers and business managers. Anyone can ask questions that need clarification. On this stage, you can re-evaluate your user story, and possibly split it into multiple stories if required.

“As a patient I want to get an overview of my consumption of medicine, so that I am aware of how much and what kind of medication I take.”

  • An ‘Overview’ or ‘History’ function should give the user an overview of the medication consumed
  • It should be able to split the overview into weeks and months
  • Medicine that is not being consumed should also be shown
  • Medication name and what it is for must be shown

The confirmation

Think of the confirmation as a test case, i.e. a series of steps that a user must undertake to formulate a user story. A test plan is a collection of test cases. With full coverage of your system in your test plans, you can easily test every core piece of functionality and tick them off as you go through them.

“As a patient I want to get an overview of my consumption of medicine, so that I am aware of how much and what kind of medication I take.”

  1. Click on the overview button
  2. Choose whether you want to see a week view or monthly view
  3. Confirm that the overview contains the consumption of medicine you have entered

I can ensure you that by using this technique you soon will find out how useful user stories really are. In addition, you keep the user in the center. User stories leave the waterfall development mentality of the last century behind and allow for new, more agile possibilities.

Good luck and all the best using user stories in your next project!

Mie Fink Nielsen, Senior User Experience Consultant