top of page
  • Medium
  • Linkedin
  • Twitter
Search

Converting experiences into actionable backlogs

Updated: 20 hours ago

“Experience” in different shapes and forms becomes the key in developing new products and services. Developing a digital product with customer experience in mind proves to be a process very different to the more traditional development against requirements coming from business stakeholders. It requires a change in development process, as well as a change in what can be considered a “good enough” requirement to develop.


Why does experience matter?

It took hundreds of years for markets to evolve into their current state. Long time ago, the general lack of supply on markets reduced the purpose of marketing to defining the just prices for a product. The product in this situation would already be manufactured and ready to be sold. The economists were talking about land, labour, and capital as the only driving forces for the production [1] — who owns those owns the market. The physical and technical ability to create products was key to entering a market.


Over time, things started to change. The customers got power to select from a variety of products to satisfy their needs better. This was driven by the industrial revolution that resulted in mass production of goods and new inventions in logistics and storage solutions. Therefore, there were more goods on the market than ever before, and the goods could be delivered to the places where they could never be delivered before! This was the first important shift — the shift to the market of demand. For businesses it meant a shift to a new paradigm. Now, to sell in the market they need to design a product that meets the expectations.


The next big shift happened not so long ago. More and more often, it is not the good itself, but a solution to a problem that the people need.

Some don’t see a car as a status symbol it used to be for their parents. Instead, they are looking for a convenient way to get from point A to point B. It may be a public transport one day, bike ride during summer, and car sharing for trips to IKEA. [2]

So it was realised the people want to get a service, not necessarily to own a product. For businesses it means they need to understand a problem people try to solve and design a solution to that problem. That is the shift to the market of services that happened on the market.


However, with more and more services being introduced, people don’t always see how one service transitions into another. What they see is an end-to-end experience of getting a problem solved.


Take an Uber ride as an example. People rarely attribute this experience to the combination of services: mobile hardware, mobile network, Uber app, payment gateway, banking processing — all the things that let a single taxi ride happen. For consumers it is one single experience, whereas for the businesses it is a combination of complementing services. This is the latest shift we witness on the market — the shift to the market of experiences.


When interacting with a new service, the customers will base their expectations on previous experiences, even if related to a completely new type of product or service. This essentially makes the businesses compete against non-competitors in a traditional sense — as they do not compete for the market share or sales figures, they compete for the experience. People spoiled with the ease of use of Uber payment process (you take a ride, you leave a car, the payment happens on its own) may find it difficult to pay online via a multi-step payment form. This can escalate to a degree when they can easily abandon the product with such under-performing UX! More than that, they are likely to never come back and spread word-of-mouth about their bad experience. [3]


For the business, it means they not only need to understand the problem the customers are trying to solve — they need to understand that problem in a context and design a full end-to-end experience of solving it. Some people call this process “human-centered design”, some — just using common sense when designing stuff.


Think about your organisation. On which stage of the marketing evolution is it’s thinking? Has it reached the final stage of market understanding yet? If not, it may be about time to start thinking this way!


How do we design the experience?

People are good dreamers. If they have a problem, they can come up with dozens of creative ways to solve it. It is a huge waste not to use this ability of your customers. People are not generally so good in delivering the dream though, this is when professional project teams can help.


The idea of human-centred design is simple: when designing a product or service, design it for the individuals who are going to directly use or benefit from it. The dry definition from ISO is:

An approach to systems design and development that aims to make interactive systems more usable by focusing on the use of the system and applying human factors/ergonomics and usability knowledge and techniques [4]

A human-centered design process always starts with a research. It can be a field study, a series of interviews with potential customers, or a survey. Based on the results of the research, the team generates ideas and builds hypotheses on which solutions can and can not work.


As a tool, customer journey [5] helps the teams visualise the current state of the journey (how the customer interacts with the service today) and the future state (how the interaction will look like after the intended changes are introduced). The future state customer journey shows how the journey should look like to make the customer experience better.



Let’s have a look at an example. Imagine a mountain country with lots of remote areas and just a handful of offices that accept payment for electricity bills in cash with no other mainstream way to pay for your power. I was told this situation used to be the case in Nepal. If anyone from Nepal is reading it, please comment whether it is true or not? ;)


So to pay a bill on time, people have to travel long hours just to get to the office, then wait a long queue to get to the officer who can accept the payment.

People line up at a counter in a beige building. Text and numbers display on signs above. Some hold helmets, creating a busy scene.
photo credit: http://khalti.com

The service people are interacting with is “paying a bill”: a person gives money and receives a receipt, simple as that.


But the customer’s end to end journey is much longer, especially for people in remote areas: they receive a bill in a letter, plan a date to travel to the office, organise transportation or even walk, pay the bill, receive a receipt, get home and file the receipt in a cupboard.


Orange icons depict a flowchart: Bill, Logistics, Payment Channel, Logistics, and Filing. Sequential arrows connect each stage.
Steps of the journey for paying a bill

This can be broken down into key stages of the journey:

  1. get notified about the bill

  2. pay it via an appropriate payment channel

  3. get reassurance that the payment is processed


From the customer journey map perspective, for each stage of the journey we could tease out how people feel during the process, what are the key pain points and how they see the process improved.


Flowchart depicting bill payment steps with emotions: bill, logistics, payment, filing. Icons show frustration to relief. Includes pain points.
Customer journey map for paying a bill scenario

For each pain point or opportunity for improvement a solution can be proposed.


How do we measure the value of changes?

Working in modern business environments I often hear people talking about aiming to deliver value every iteration. This is a great concept, which comes from agile development. It does however have a pitfall.


In reality, when delivering new pieces of software or introducing other changes in the business, you don’t necessarily know if the value is going to be realised. What you deliver is a promise of value.


A great way to articulate such promises is to capture them in a hypotheses backlog. Basically, we say that we assume certain changes will deliver certain value. We also define measure of success, so when the changes are life we can collect reliable evidence that things work.


A good template for capturing hypothesis is:

We believe that <a change> Will result in <value> Because <research data/assumptions>


<This is how we are going to measure it>


Some of the hypotheses can be tested early with the help of prototypes and interviews. This knowledge will inform the future state journey used to design a new service. Some hypotheses cannot be reliably tested will a version of a service is on market. These rely on data collection and analysis from real life product usage.


How do we scope the change?

It is not enough to identify the opportunities for improvement and design the future state experience. Till now, all our artifacts were mostly drawings and mock prototypes. To make our work valuable, we need to find a way to hand this over to production teams and make sure the final product complies with the experience we have designed.


Introducing a change is hard, especially if the change is big and you try to implement it in one go. This is the reason we tend to break any solution into smaller components. Each solution component should be small and independent enough to be changed individually in a controlled manner. So that eventually we can compose a new experience out of them. Pretty much like using a set of Lego blocks.


Allocating requirements to solution components is a very important task. First thing one needs to understand is which solution component supports which part of the customer journey. For each component there are always two parts:

  1. Front-of-house: what the customer sees when interacting with a solution component

  2. Back-of-house: what are the business capabilities that support it from the inside of the business


Let us take for example a process of receiving a bill. What a customer sees is a printed bill in the mailbox with all the relevant data they need to action it. This is the front of house, and bill recipient will have a long list of requirements for what needs to be on that bill. But for the bill to arrive, the business needs to have a (preferably) automated reconciliation process that calculates the balances, a printing process, a delivery process, etc. All these form the back of house for the same component of the solution.


To finish this task, you will need to identify all the touch points on the customer journey (this are moments in time when the customer interacts with the business). For each touch point, you need to list all the business processes that support it, as well as information systems and data sources. This will produce a sliced view of the enterprise architecture through the lens of one particular customer journey.


There are always gaps between the current and desired states. A great way to highlight and document those changes is to use user stories. A user story is a very popular format for documenting requirements. It is a common knowledge it consists of three elements. The template looks like this:


As a <persona> I want <a capability> So that <value>


This format can be easily utilised for our experience driven situation:

  1. In the first statement focus on who benefits from the change. Try to also add context. Avoid using “As a user” all over the place, give the user some personality. For example, “As a user with an outstanding bill” or “As a user who has just paid a bill”. Context matters. Read more about it in my other article [6] if you are interested.

  2. In the second statement, describe what the change is about. Specifically, which capability is missing in the as-is state that this story will introduce.

  3. In the last statement, describe what is the value that the change will bring, why the missing capability is needed.


It is important the user stories describe the desired state rather than the steps to achieve that state. The actions taken to achieve the desired state are not a part of the solution scope — they form a project scope when the solution to be delivered is already understood. The logical order of steps is: first, define what you want to achieve (user stories), then understand how you will achieve it (actions). A healthy product backlog will mostly consist of the user stories, and not the tasks. This is how the team can properly scope the final product and track the progress in terms of delivered functionality and value, not the effort spent.


Let us have another look at our customer journey. Here are some examples of user stories connected to different solution components:


Bill (get informed)

As a customer who has an outstanding bill I want to see online payment options on the bill So that I know I can pay online


As a customer who is worried about missing bills I want to see a date when the next bill will be generated on a current bill So I know when to expect it to arrive


As a customer who doesn’t know how much the next bill may be I want to see summary statistics on historical energy consumption in my area for the next time period So I can get a rough idea of the amount of the next bill


Receipt (get reassured)

As a customer who paid online  I want to get a paper receipt and statement mailed to me So that I can store them for my records


As a customer who paid online I want to print a receipt  So that I can store it for my records


The user story is the main way to connect the customer we are helping (“as a”) to the need (“I want”) and the why behind it (“so that”).


An important side note is that you are most likely to create the user stories at least twice.


First, user stories will serve as a basis of validation process. You need a tool to scope the prototyping.


Second, once the solution is defined you need more detailed (“development ready”) user stories to feed the delivery process.


How do we ensure the solution delivers the expected experience?

How do we know if we have successfully delivered a user story in a way that supports the expected experience? Typically, a user story will be accompanied with acceptance criteria for this.


Acceptance criteria are used to check if a user story is done. The way I usually put it, they help prove that the story is delivered in full. What is important, acceptance criteria have to be agreed with interested parties before the story is delivered.


A good way to write precise acceptance criteria that are easy to communicate is to use examples. As a user story may have multiple acceptance criteria, it is not uncommon to have multiple examples for each story. Let us take this user story from above:


As a customer who paid online I want to get a paper receipt and statement mailed to me So that I can store them for my records


It may have an acceptance criterion like this:

  • After the user pays online, a letter with a printed receipt should be delivered to the user’s address.


This is a good starting point, but it can be noticeably improved. This criterion is declarative and very broad. Such a criterion is not directly actionable or testable, therefore it does not enforce the expected behavior and may even be out of scope of the solution control. With mail delivery, if the company does not own the delivery service they cannot guarantee the printed documents will be received. All they can control is that the envelope is sent to the proper address.


Let us fix this issue:

  • After the user pays online, a letter with a printed receipt should be sent to the user’s address.


We have replaced the word “delivered” with the word “sent”, which returned the criterion into the solution scope. Now, we can start adding examples to this criterion to make it actionable:


Given a user lives at 20 Main road

And has to pay $70 When the user pays online Then a message is shown that a receipt will be posted And a receipt is queued for postal delivery to 20 Main road


This is a great addition to the original criterion as it can be easily discussed with the stakeholders. Quite often these conversations are as important as the process to come up with the user stories in the first place, as they uncover lots of missed alternatives in the processes and missed requirements.


How do you create such examples? First, you need to prepare a list of user stories for the team. Second, each user story is accompanied with acceptance criteria. Third, the team explores the domain outlined in the story and collaborates to produce scenarios. It is important the three perspectives take part in the process:

  • Business — people who know the problem domain

  • Development — people who will be developing a solution

  • Testing — people who will perform quality control on the output


This meeting is often referred to as a Three Amigos meeting [7]. The main objective is to get people to talk to each other and get aligned before the start of development to uncover tricky cases that may appear on the customer journey and get an agreement on the scope of development for a particular story.


In the example above, one of the researchers may say that people she talked to mentioned they often pay a bit more than the bill amount so that the next bill comes smaller. This can get reflected in the reassurance story as a modified example scenario:


Given a user lives at 20 Main road And has to pay $70 When the user pays $75 online Then a message is shown that a receipt will be posted And that extra $5 will be accounted for in the next bill And a receipt is queued for postal delivery to 20 Main road


It always helps to relate the acceptance scenarios back to the customer journeys. This will help prioritise the ones that matter to the customer and not to miss important interactions.


Summing it all up

What makes the development driven by experience?

  1. Understand the expected end-to-end journey

  2. Base requirements on research not opinions

  3. Be clear about which hypotheses you have in mind

  4. Prepare acceptance criteria in the form of scenarios that may appear on your customers’ journey


If you don’t talk to your customers when developing requirements, you are probably designing something no one dreams about


Let the customers dream. Let the businesses ensure those dreams come true.


References:



Comments

bottom of page