Lean UX with effect map - from HeltSonika

Posted by Marcus Hammarberg on June 17, 2013
Stats
I ran across a great post by Dan Kindeborg that thought me a lot of about effect mapping (prequel to Impact mapping). "Sadly" it was in Swedish and I got to keep the material to myself... Or well no - that's not how I roll. So asked Dan for permission to translate the original post here on my blog. He was totally fine with that so here it is.
When you read stuff about UX and design below it's Dan's word. Don't worry - i still know nothing about that. But I learned a lot by reading this I hope you do too. So, from the next paragraph when you read "I think" it's actually Dan thinking. Just so you know. Over to Dan.
I ran across a great post by Dan Kindeborg that thought me a lot of about effect mapping (prequel to Impact mapping). "Sadly" it was in Swedish and I got to keep the material to myself... Or well no - that's not how I roll. So asked Dan for permission to translate the original post here on my blog. He was totally fine with that so here it is.
When you read stuff about UX and design below it's Dan's word. Don't worry - i still know nothing about that. But I learned a lot by reading this I hope you do too. So, from the next paragraph when you read "I think" it's actually Dan thinking. Just so you know. Over to Dan.

Lean UX with effect map

An IT-project is often started with an idea about how business impact can be created. Someone has invented a new way to make money, or a way to streamline their business to save money. But IT-projects are expensive and nobody knows if the idea will fly or not. The person that came up with the idea thinks that there's a customer-base that will use the perceived product. There's a big risk in investing 10 millions in realizing the idea. And how will the ideas be realized? A new Intranet can look and work in a myriad of ways.


Dated, technology driven organization hops to it and starts to develop directly, without putting any effort in examining how the product will be designed and styled.

One (of many) problems with traditional user-centric work

If you have come a bit further you might work user-centric in a traditional way (like waterfall or agile - but only in the development phase) and thinks that they have solved this problem. Instead of "guessing" who the user groups are and what they need we head out and collect information about the current situation by doing interviews, observations and data analysis. When this is done we create design specifications that is tested out on the target audience and then is handed over to the developer that implements it. 

The target audience needs are mapped out. That's great. But does that mean that we know that this product, that will set us back 10 millions will be useful and create an impact? Hardly. The methods we UX designers has picked up is far from fail safe. They work fine in answering the question: How should this product be designed to be as good [useful] as possible? but they have a hard time answering the question Will people pay for or use this product?

Lean UX

The Lean Startup is a product development approach created by Eric Ries, built around the idea that instead of spend the 10 million and hope that we will deliver the product in two years, we instead spend a smaller sum to build a minimal version of the product (MVP) that we can deliver in a month. The minimal version is used to gain insights about the target audience, insights that you then use to improve and build the next version. 

The benefits of this approach (compared to the traditional user-centric approach) is that you continuously will deliver business impact and that you gain insights from the target audience that deep interviews have a hard time to get at:
  • Will the target audience use / pay for the product?
  • How will the users adjust their lives after the product, when they have used it for several months? 
  • How will the usage of the product change over time? 
  • Will the users learn how the product works?
Since "building" might mean implementing as well as building a clickable prototype, UX designers and developers needs to work in parallell to be able to work in this fashion - which gives us a lot of amazing consequences, referred to as Lean UX. Lean UX is Build-Measure-Learn in cross-functional teams where developers and UX designers cooperate and gain shared understanding instead of producing, handing over and read design specifications. I've written about this before in my article series The waterfall swamp.

What is a MVP?

We will soon get to how this all can work in practice but first some more fluffy stuff, since it's important to define what a MVP (minimal viable product) is in Lean UX context. It's not easy either.

I think that it's valid to describe a MCP as an experiment that aims to validate a hypothesis. The hypothesis could be (for example): "I think more people would visit our intranet if it had more pictures of employees". To validate the hypothesis I need an experiment. The traditional UCD-experiment could be to send out a survey to the users and ask them to answer if the think that they would visit the intranet more if it had pictures of employees. A safe experiment could be to build that functionality into the intranet and measure if the usage is increasing or not.

The hypothesis is something that we thing will make an impact. The experiment is the smallest step we can take to validate if the hypothesis is correct. In the early stages in the project we want to find the hypothesis that creates the most impact - and that's where the effect map comes in.

Defining a MVP with an effect map

Since I recently started to define a MVP with the help of my old favorite modell the effect map I thought I would share how I did that via an example. 

The idea - The handyman service!

An IT-effort starts, as I said, with an idea, good or bad, about how you can earn or save money. Let's imagine that I'm an entrepreneur and that this is my idea:
People refurbish their houses and apartments like there's no tomorrow. But there's no real good services for instructions on how to install a washing machine or how to install parquet floor. I want to create a site where you in a simple way can get access to that kind of instructions.

1 -  Build an initial effect map - a hypothesis for the entire effort

Ideas and visions are great, they are often interesting but not seldom thought all the way through. I almost every time (regardless of working traditional or with lean) start a project with, together with the stakeholders (people with money, ideas or business knowledge) build an effect map during one or more workshops. The effect map covers the business impact (or the effect goal), our target audiences that we think help us reach the business impact, their needs or incentive and how we can support those needs. 

There's several benefits that can be reaped by building an effectmap together with the stakeholders instead of directly talk about the functionality of the system:
  • You reason, in a structured fashion, from business goals and target audiences (user centric) instead of having people sitting around and "make up" things without really saying why this is a good idea
  • The group creates a common understanding kring the campaign, summed up in a clear model that everyone can understand. 
  • When you talke about functionality you can easily end up sub-optimizing by forgetting a target audience group or incentive for them
  • It's soon clear how well you know your audience and areas where you need to get more information. 
The effect map that we create is initially built around guesses about who our target audiences are, their  needs and what we need to do to support them. It will make up a kind of base-hypothesis for the entire project. 

Effect goal - what do we want to achieve

The first step when building an effect map is to formulate an effect goal. What do we want to achieve or how will we make/save money with this idea? 
In our example we want people to pay for a service with instructions for DIY'ers. 

Target audiences - WHO will contribute to the effect goal?

Who will help us sell DIY'ers instructions? Well, firstly we have the people that will pay for the instructions. We think that both DIY'ers and professionals would pay for this, and we also think that these two groups is quite different from each other. There's also editors, someone have to write the instructions, right?


Driving forces - what does the target audience want or need?

What does the target audience need and want - which are the driving forces that will make them want to  contribute to the effect goal? We think that, for example, the DIY'ers want help where ever they are, even when they are standing bent over a washing machine with the screw driver in one hand. 

Measures - what can we do to support those needs?

This is the first time we talk about functionality, information and other things that will make our target audiences happy and successful. My entire example map looks like this:


2 - Encircle prioritized target audiences, driving forces and measures - what is most important?

In the next step the goal is to use this effect map hypothesis to prioritize. Which target audience, which driving forces and what measures is absolutely critical for us to succeed? We would like to break off a one small aspect of our service that we think will be the key to make or save money - and that will be tested with our MVP. But it's not that seldom that more than one aspect that cooperate to make a service  or product sellable.

In our example we think that the DIY:er is the absolutely most important target audience. My idea was a service that turns towards amateurs, the DIY:ers are abundant out there and they are the ones that will pay for the service. 

We think that the most important driving force in the example is Needs help fixing at home and the most important measure is that there are great graphical instructions on how to go about to fix something in your house. 

3 - Formulate a hypothesis - what is our prioritized goal?

To get the correct focus when we're building our MVP (an experiment that validates the hypothesis) we need to formulate what should be tested (what is prioritized) in the form of a hypothesis. When we do that it will also be clear that the effect map is just built around nothing than a bunch of assumptions that need to be validated. Our hypothesis:
We think that DIY:ers needs help with fixing their homes and will pay for instructions on how to do home refurbishing, if they get graphical descriptions on how to fix stuff around the house.
The hypothesis in general form:
We think that [target audience] [driving force] and will [effect goal] if they get [feature]
There! Now we have summed up this projects core as a hypothesis. The hypothesis is powerful since it's short and consice but also because it includes both the effect goal, the target audience, the driving force and the feature.

4 - Define a MVP - what is the smallest possible thing we can build to validate the hypothesis?

In the last step we define the MVP (or the experiment) itself, in order to start building. This can be done in different ways and in levels. The questions is what is the smallest thing we can build to validate the hypothesis? In the example with the DIY-service we can imagine a lot of different experiments. We would build an old-fashion interactive prototyp that we test on the target audience, but that doesn't deliver business value in a continuous fashion. The question, also, is if that really would be enough to validate the hypothesis? Let's instead go for implementing a first version of the service that let's amateurs pay for graphical descriptions for home fixing.  

How to the define the MVP is contextual. I like to start off from a number of scenarios that the service will support (step-by-step: how would the DIY:er get to the instruction?), draw wire frames on how the service would work based of those. Jeff Pattons story maps is an excellent way to interconnect the user scenarios with User stories and prioritize among those. Here are some example scenarios:
  • The DIY:er downloads and pays for the DIY:er application
  • The next the the DIY:er is about to install is newly bought washing machine
  • He picks up his mobile and open the app
  • Searches for "washing machine" and get's a list of instructions for washing machines
  • He choses the instruction for "install washing machine"
  • Reads the instruction
  • Goes back to the store to get more material
  • Open the app again to double check which pipe-parts that is needed
  • Goes back home again and installs the machine
When we have the scenarios and the user stories in place the team can start to take a look on how to implement them, and with a little developer magic we'll soon have a working DIY:er application. This application is not complete, as noted before, but there for us to validate the hypothesis and start delivering some business value.

Next step - measure, learn and improve

When the first MVP is built we can start to measure the usage of it, but also combine that with traditional methods as deep interviews and observations. Now we could take contact with and interview the users that's actually using our service, not just our potential users. And if we should end up with no users, well then we could get back to the effect map and change the base hypothesis or just abort the project all together. 
Every new thing we learn about the target audience is added to the effect map. When the next build-iteration is planned we can go back to the map and extract a new hypothesis. Next step maybe is to find out if we can make the service attractive to professionals, or we stay on our prioritized target audience. It all comes down to what we see give us the most business value, at the specific time. 

The new hypothesis is used to improve our product, so that the product in the next iteration becomes an experiment that is used to validate several hypothesis. When you run out of hypothesis to validate, or if someone says "Stop" for budget reasons, then you're done and have a guaranteed useful product that the users likes!

The best of two worlds

There's a lot of gain from instead of starting with traditional methods instead deliver business value early, improve continuous and cooperate in cross functional teams. But there's nothing that says that this way of working not can be combined with traditional UX-methods and models like interviews, observations, user surveys and building prototypes etc. 

When we have a hypothesis and before we start building the first slice of the product, for example, we could run a quick user survey to do a first check-up if the target audience and the driving force aligns with what we think.

You're allowed to cherry-pick from the both worlds and adjust to the current situation. I do that. 

Read more

There's so much to write about this way of working. Luckily there's more than I that have done that:


Published by Marcus Hammarberg on Last updated