How we define a problem, build a solution and test it in 5 days

At Steps, we design digital tools for mental health using exposure therapy. Our goal is to help people, help themself, do more of what they want. There is no recepie for doing this, so we are always looking for fast ways to test if our ideas are worth building or not. I want to share with you examples of how we do.

We’ve launched the Steps iOS app. It has been downloaded and used by a lot of people all over the world. The tool is simple and give users inspiration to challenges that can improve their social life and confidence. It’s the user who decides what he/she wants to do, and also the user who are doing all the hard work.

To update and improve our products, we do design sprints, originally invented by Google. It’s five days where the team defines a problem to solve, build and test a solution. Below I’ll walk you through each day, based on an example from our last sprint.

Monday — Defining the problem

One should think that deciding on a key problem to solve in a specific area is easy? Even obvious? But try to gather people from your company from different backgrounds and ask them; “why are we not selling more?” You’d probably get as many problem-definitions as people in the room. Monday is the day to agree on what problem to solve. And the bigger the problem the better.

In our case, the goal is to get people to complete a Steps they chose to work on. The problem (rewritten as a question) is how to reward users before and after working on their challenge?

We then interview experts to understand the problem from different angles. A senior UX’er from the running app Endomondo was among these on Monday, giving input on what makes people continue to run AND use the same app for tracking?

Tuesday — Get inspirations to solutions

A very early idea..

By Tuesday the Sprint team are presenting solutions from other organisations who have similar problems. How do fitness apps make users exercise? How does Duolingo makes people continue practice on a language? After presenting several ideas, and writing down new ones based on the input, it’s time to get into drawing mode.

Everone makes simple drawings of a process flow, or a specific situations related to the problem. Different inspirational methods are used to get the team to deliver some great ideas, but no one shares their work.. just yet..

Wednesday — design a solution

On Wednesday each team member puts their best drawings in a pile and someone hangs them on the wall. Without knowing who has created which, a voting process starts. Soon different areas of the drawings are filled with little dots from other team member, who particularly liked that part of a flow. Without any presentations or discussions, it becomes clear where the good stuff is.

If you don’t think you can cover everything related to the problem from Monday, decide what part of the process to focus on. A final detailed solution is drawn, based on the ideas generated by the team. And that’s the end of Wednesday.

Our final solution; Give people personal rewards, in the form of tips, depending on who the user is and how they use the product.

Rikke drawing the final solution as the last thing on Wednesday

Thursday — Build the solution

Our prototype, clickable, but with no intelligence

And now we build it. No matter what idea we come up with Wednesday, if it is a psysical or digital product or an experience, we only have Thursday to build it. The product we build doesn’t have to be real, it just have to appear real enough to get users genuine response.

Technical skills are rarely needed, a bit of creativity and you’ll see even the most crazy idea turn into a testable product by the end of the day.

In our case, instead of cooding the analytics to give users personal rewards, another team member was simply just observing what the users typed and acted as the bot, and gave users inputs that look personalised to them. The solution is not scalable at all but perfect for collecting insights.

Friday — test it

Friday is testing day, so make sure you have invited 5 (potential) users to come and test the product, one at the time.

For our test, the user only needed to go through the prototype flow one time, for us to see their reactions, which we depended on, as we did not have a “back” option in the prototype.

Our testers tried to go back in the product, to pick other challenges, and clearly stating that they wanted to work on them also, to get new rewards. It wasn’t technically possible, but it looked like it was, and it was the clearest evidence, that they wanted to continue using the product, to get more rewards.

Sanne and Haik looking at notes from user testing

We also saw that all of the testers had difficulties understanding where they should pick a goal to work on. We never considered it to be hard to understand, but now we have the oppertunity to fix it, before building real, time consuming features.

— I hope you got some inspiration! :)

Overview of the week

For more about us at Steps, visit: www.stepsapp.xyz