The dangers of assumptions

ServiceDesigners.be
theuxblog.com
Published in
5 min readSep 28, 2016

In our previous posts we talked about what we think is a good entrepreneurial culture and how to cultivate one. So now we laid the fundaments, we can build upon them and make things a little more tangible and practical. In this post we want to talk about the process and how to avoid the most common pitfalls and misconceptions.

Are assumptions really the mother of all fuck-ups?
Assumptions have become the basis for almost everything we do: we make assumptions about what people are interested in, what they need, what bothers them, what drives them and what we can deliver to fix all these problems for them. We have built whole frameworks and methodologies, like design thinking, around working with assumptions and in theory that is absolutely fine.

In practice though, there is a considerable pitfall that we all to often run into: we don’t test our assumptions (thoroughly), allowing them to turn into pre-dispositions. Depending on the skill and experience of the people involved, we mostly manage and we succeed in delivering something that is an improvement over the current situation. But in most cases it is just that, a marginal improvement on the status quo and never real, true innovation.

The project plan or as we like to call it, the predisposition guide
After receiving a briefing, usually one of the first things we do is create a project plan or roadmap. We define tasks, lead times, dates, milestones, deliverables, dependencies, and more. We have a start date and an end date and we fill the blanks with the methodology, workshops and tools of our choice. The problem with planning a project like this is that there is no room left for flexibility, creativity or do-overs and that we never really even had the chance to challenge ourselves or our teams to come up with really new or radical idea’s.

We understand that creating a planning is in our nature, we prefer order over chaos. We also understand that we need a project planning in some form to be able to communicate with our clients in terms of timings and budgets. So how can we do this, avoiding predispositions on the way and without limiting our chances to reach real innovation?

A quick recap of the process
There are a several design (thinking) processes out there, which are mostly variations around the same theme. At Boondoggle we currently use the LIME-model (Learn, Ideate, Make, Evolve) which is a variation on the Stanford User-Centered Design Process. Personally, we prefer the double diamond model because it visually encourages iteration by forcing you to diverge (explore) and converge (make decisions) while the UCD model more often than not seems to result in a waterfall process that lacks convergence and real decision points.

Double diamond model (British Design Council and addition by @sarahprag)

So using this model, let’s take a look at what we can do to ensure we are not falling into our old habit of mistaking pre-dispositions for assumptions.

Discover by observation
Research is often skipped in the discovery phase, often because of timings or budgets, or we use tools like surveys that might not necessarily give us real answers. In our previous post we already talked about validated learning. With validated learning we mean constantly looking for ways to test your interpretations before moving along. So how can we do this during our discovery phase? By observation!

Observation allows us to bypass assumptions and biased opinions, and not just the one we make ourselves but also those of our potential test and interview subjects: people think they know what they want, or why they do something the way they do. But in reality they often expose behaviour that they themselves are not aware of at all. Just think about how somebody is completely caught by surprise when another person asks them to stop biting their fingernails. So observe and learn!

Sprint to the finish
When starting the second diamond, we often employ brainstorming techniques. They bring your team (and ideally client) together, everybody feels involved and gets the chance to be creative and have their say. The thing with brainstorms is that they don’t provide actual solutions. They provide new assumptions and have 4 inherent problems:

  1. Brainstorms deliver quantity over quality. We assume that we will find a gem in this heap of superficial ideas.
  2. Some ideas are over-valued because of the personality or reputation of the founder. Introverted people rarely shine in brainstorms.
  3. Groups tend to look for consensus and as a result deliver watered-down concepts.
  4. There are no tangible results. Often a brainstorm ends with walls full of post-its, but no roadmap to get from abstract concept to implementation.

But there is an even bigger problem with brainstorms: we often forget to converge after we’ve massively diverged. And because of this, usually one of two things will happen: Either there is consensus over who had the most creative idea and everybody is excited so we run with that (without really testing it and thus creating a new predisposition), or more often, individuals worked some more on it and came with another solution, rendering the whole brainstorm pointless. So how do we think you should fix this? By employing sprints.

Sprints were developed by Jake Knapp at Google Ventures and granted, they probably need some tweaking to be deployed in a non-google venture environment but nonetheless, we believe sprints are the solution for the problems mentioned above. You can read all about sprints at the google ventures website, but in short: a sprints lasts 5 days and starts with mapping the problem, moves over to individuals creating solutions for part of the problem, converging to one storyboard that leads to a prototype and test scenario that is tested on potential users on Friday.

This means that your team, that observed during the discovery phase and is operating on valid assumptions can deliver a tested prototype to your customer in one week time. And it doesn’t matter if this prototype is close to your actual solution. If it is, even the better, but if it isn’t you failed incredibly fast and probably learned enough to do a lot better in the next week. This especially is the power of sprints: it’s a mandate and a controlled way to fail, encouraging you to leave your comfort zone and search for something radically new and truly innovative. And wasn’t that what we were trying to do in the first place?

This blog post is the third of the series “why our industry is failing and what you can do about”. If you liked it, please visits our website or subscribe to our newsletter so we can keep you posted when something new arrives.

--

--

ServiceDesigners.be
theuxblog.com

We are Service Designers who want to improve customer experiences by creating purposeful solutions that transform people and organisations.