Focus: how to build the right thing, right away
You‘ve got your goal, you’ve got some ideas; you’re ready to design.
Quite often, a Design Sprint is filled with excitement and creativity. Everyone is full of ideas and the prototype that rolls out of the process is exactly what we were looking to create.
When the team shows the prototype to their colleagues, their excitement is confirmed. That looks pretty cool indeed.
The roll out of the Minimum Viable Product is a success, it works as designed. The team celebrates, but the product doesn’t quite hit the right tone. The result seems complete, but the essence might be missing…
For me, a Design Sprint should have at least two high-level deliverables:
- Potential solutions to the design problem
- Validation of one or more of those solutions
After setting our goal, it might be tempting to directly jump into the solutions. Perhaps not by directly designing the interface, but at least defining the to-be process.
Stop right there!
Before we do that, we have to ask ourselves why we took the time to define our goal. We carefully looked for the right words and tried to incorporate multiple perspectives into one sentence. By diving into the solution before turning the goal into the right focus points, we might lose the direction that we just set out with our stakeholders.
In my article about creating a User eXperience, I briefly mentioned this step as ‘Getting your priorities straight’. In this step, the Design Sprint method suggests us to define Sprint Questions, which should help us in validating our prototype. However, I believe that some extra context can explain why we generate those questions and how they might help getting to the Design Sprint deliverables.
During this post, I will refer to the approach that AirBnB took when designing their platform. Why? Because they have succeeded in achieving a seemingly impossible goal, “making people feel at home around the world”. Additionally, they have given this must-see Ted talk about how they did it.
When have we hit our goal?
This is the first thing we should ask ourselves after having set a clear goal. Answering this question will give us some sub goals, which will make it easier to turn the goal into concrete actions.
When can AirBnB truly say that they have made people feel at home?
- People are hosting visitors in their house
- People are staying in someone else’s house
- Visitors feel at home during their stay
Often, this exercise will clarify that the long-term goal has a supply side and a demand side. For AirBnB, these are the hosts and the visitors. For a news application, you need to make sure that you can both offer relevant news and reach an audience to consume that news.
What are the success & fail factors for these sub goals?
Here comes the step that will make the difference. Acknowledging that multiple elements have to be considered to reach our goal is often quite obvious. Understanding what will make or break the experience for the involved parties will determine the success of our product.
What if AirBnB would have skipped this step? They would have probably just made a BnB listing platform. People would be able to offer their house on the platform, while others could respond to the listing.
“Understanding what will make or break the experience for the involved parties will determine the success of your product”
Luckily, AirBnB recognized why this would fail. For most of us, our house is very personal, too personal to share with people we don’t know. For a user of the platform to host visitors, they would need to trust the visitors. Trust of hosts in their visitors is a clear fail factor.
Similarly, we can ask ourselves how we can be successful in achieving one of our sub goals. One way to make people feel at home is by making them familiar with the surrounding area. This familiarity is an example of a success factor.
Let’s turn these into questions
Sprint explains us to distill Sprint Questions from our goal. For the above two success/fail factors this is rather easy:
- Will our hosts trust the visitors?
- Do our visitors feel familiar with the surroundings of the house?
The reason that we define these questions is three-fold. First, it provides us with some potential focus points of both our Design Sprint and our product. Second, it’s encouraging. Finding an answer to these questions seems a lot more achievable than coming up with a solution to our design problems. And finally, the questions will allow us to validate our solutions.
Amazing! Those are exactly the deliverables we were looking for!
Focus points and validation. Yes, almost. Let’s take this one step further.
How Might We’s and Metrics
During a Design Sprint, it’s often rather difficult to explain the usage of How Might We notes to our participants. However, when explained and used well, they can be very effective. As HMWs can be an such a powerful tool, I will give them their own article in the future. For now, a short explanation will do:
How Might We’s (HMWs) are worries, ideas and challenges translated into constructive questions that can be answered by solutions.
The reason why I bring them up here is that HMWs are the bridge between our focus points and the solution that we are looking to build.
- How Might We verify the trustworthiness of our users?
- How Might We communicate the trustworthiness of a user to other users?
- How Might We allow hosts to validate a good experience?
These are just some examples of HMW questions that the team of a Design Sprint can come up with when discussing the Sprint Questions. The questions directly tickle our creativity and invite us to come up with solutions. But how will we validate those solutions?
Metrics
In tailor-made application development, many companies want to measure their success, but very few actually do. It seems like a daunting task to quantify your success into money to be made. However, now is the moment that we have not built our prototype yet. Now is the moment we can define the questions we either want to ask experts, before building the prototype, or users, after using the prototype.
Setting up metrics is not as difficult as it seems. When it comes to a goal that relates to ease-of-use, we could measure how many testers successfully completed the tasks we have set them out to do.
When it comes to a goal that you cannot be measured through direct usage of your prototype, we can ask our users some questions.
This is what AirBnb did. Their team recognized that the concept would only work when the host trusts the visitor. Perceived trust is a very easy metric, that could be compared for multiple designs.
The AirBnB team asked hosts to rate the acceptance of a visitor, based on their introductory text. The introductory text is just one design element of the solution, other elements include previous ratings of the user and an icon to show that their identity is verified.
The important thing here is to define our focus points and metrics before designing the solution. Thereby, they will be based on our goal and focus points, instead of on assumptions and first guesses. If done well, the proposed solutions will directly contribute to the success of our product.
So how does this help us to build the right thing, right away?
You got your goal, you got some ideas; you were ready to design.
The problem was, the crucial factors that determine success and failure already existed. So did the metrics. They allow us to measure, in retrospect, why we succeeded or failed.
By taking the time to understand what your goal actually means, you identify what will define your success. You’ll come up with ways to measure your chance of success before having built and invested effort into your prototype.
After designing any of the Design Sprint deliverables, you can look back at the Sprint Questions and validate whether you are on the right track. After validating the prototype, you can pivot in your approach, sharpen your metrics or, when successful, set out your next milestones.
This way, the Design Sprint helps you to build the right thing, right away.
