Lean UX with effect map - from HeltSonika

· June 17, 2013

Tools   Lean   Agile

I ran across a great post by Dan Kindeborg that taught me a lot about effect mapping (prequel to Impact mapping). “Sadly” it was in Swedish, and I couldn’t keep the material to myself. So I 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 words. I still know nothing about that. But I learned a lot by reading this, and 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 often starts with an idea about how business impact can be created. Someone has invented a new way to make money or 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 million in realizing the idea. And how will the ideas be realized? A new Intranet can look and work in a myriad of ways.

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 think that you 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 are tested out on the target audience and then handed over to the developer who implements it.

The target audience needs are mapped out. That’s great. But does that mean that we know that this product, which will set us back 10 million, will be useful and create an impact? Hardly. The methods we UX designers have picked up are 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 spending 10 million and hoping 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) are that you continuously 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 using the product 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 need to work in parallel 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 reading design specifications. I’ve written about this before in my article series The waterfall swamp.

What is an 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 an MVP (minimal viable product) is in Lean UX context. It’s not easy either.

I think that it’s valid to describe an MVP 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 they 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 think will make an impact. The experiment is the smallest step we can take to validate if the hypothesis is correct. In the early stages of the project, we want to find the hypothesis that creates the most impact - and that’s where the effect map comes in.

Defining an MVP with an effect map

Since I recently started to define an MVP with the help of my old favorite model, 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. Almost every time (regardless of working traditionally or with lean), I start a project with, together with the stakeholders (people with money, ideas, or business knowledge), building 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 will help us reach the business impact, their needs or incentives, and how we can support those needs.

There are several benefits that can be reaped by building an effect map together with the stakeholders instead of directly talking 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 around the campaign, summed up in a clear model that everyone can understand.
  • When you talk 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 are quite different from each other. There’s also editors; someone has 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 wherever they are, even when they are standing bent over a washing machine with the screwdriver 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 are absolutely critical for us to succeed? We would like to break off 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 cooperates 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 fixing 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 need 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 project’s core as a hypothesis. The hypothesis is powerful since it’s short and concise but also because it includes both the effect goal, the target audience, the driving force, and the feature.

4 - Define an 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 question 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-fashioned interactive prototype 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 lets amateurs pay for graphical descriptions for home fixing.

How to 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 wireframes on how the service would work based on those. Jeff Patton’s 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 thing the DIY’er is about to install is a newly bought washing machine.
  • He picks up his mobile and opens the app.
  • Searches for “washing machine” and gets a list of instructions for washing machines.
  • He chooses the instruction for “install washing machine.”
  • Reads the instruction.
  • Goes back to the store to get more material.
  • Opens the app again to double-check which pipe parts are 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 at 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 are 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 altogether.

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. The 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 hypotheses. When you run out of hypotheses to validate, or if someone says “Stop” for budget reasons, then you’re done and have a guaranteed useful product that the users like!

The best of two worlds

There’s a lot of gain from instead of starting with traditional methods instead deliver business value early, improve continuously, and cooperate in cross-functional teams. But there’s nothing that says that this way of working cannot 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 align with what we think.

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

Read more

There’s so much to explore about this approach to working. Thankfully, there are many others who have delved into it:

Twitter, Facebook