A Map for Explorers
A new design approach for Novel problems
All the largest innovation failures have been failures of ‘why’ not ‘how’
Almost every design process I’ve come across follows the same pattern; “define what the problem is and then solve it with these simple steps”. They’re wrong.
Without meaning to throw shade on the incredible Albert Einstein, when he said “If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask… for once I know the proper question, I could solve the problem in less than five minutes” he wasn’t talking to product designers or entrepreneurs.
We can’t know what the real question is for a Novel problem until many attempts after we’ve started. So unless what they mean is that you do all this within that “Define the Problem” step 1, they’re selling you an illusion. So we need a new map to follow, a new process, one that recognises question exploration and is designed for Novel problems…
Novel problems require a frequent back and forth between asking yourself discovery questions of Why (“Why are we doing this?”) and delivery questions of How (“How are we going to do it?”) A balance between the two is needed.
I call this framework: Fuzzy to Finished.
For explorers, all initial problems are fuzzy, ill-defined and unreliable, no matter how confidently they might be presented or pitched. From this fuzzy starting position hunches as to what be a suitable solution appear. But they are only hunches at this stage, a good explorer knows not to be over confident in their ability to see the future.
From hunches a slightly deeper understanding of the problem can be obtained, but it remains still vague. Yes you know lots more, but the details are likely to still to be worked out. Even if things feel certain to you, it’s important not to skip ahead and believe you’ve somehow cracked it at the first attempt. Your knowledge will always get deeper still as you progress and test more.
If your discussions and tests with users means a hunch looks promising, start formulating ideas around it, start adding some flesh to the bones. But hold off a full embodied design. We’re still only working on a vague understanding of the problem. Test these ideas again before going any further.
Once your understanding is clear, you know what you need to do and can commit to a builder like design phase, using whichever approach you are comfortable with.
With your designs finished, you can enter customer trials with confidence, looking to uncover only minor subtleties that could lift your solution from good to great.
Congratulations you’re finished.
Novel problems need a constant back and forth between solving the problem and checking to see if the problem you’re solving is actually worth solving.
A few more things to add…
Now that we have the basic model, the basic framework and a basic understanding of the goals and objectives, some extra levels of detail would be useful. Like adding in more details to our instructions, it all helps to keep us on track.
Alongside the Problem Finding and Problem Solving channels we also have two additional columns that deal with different types of testing. Another Why column which looks at the “Three T’s of User Testing” and an additional How column for technical feasibility.
Fuzzy to Finished Explained:
All ideas and problems should initially be thought of fuzzy, no matter how confident you are.
The first solution ideas are not ideas but hunches, easily dropped, changed and disregarded without attachment if proven to be wrong.
Check to see if they are technically feasible and if the user shows interest in them, if not return to generate more.
Successful user engagement should improve your understanding of the idea. But it is still only a vague understanding at this stage, lots is still unknown or unproven.
Convert your successful hunches into ideas and repeat the process… can you make a functional prototype for users to try? Can you make usable designs for users to trial? The three stages of technical testing and the three ‘Ts’ of user testing.
Only once you’ve been through all of these stages can you say that your understanding of the need is deep and thus the idea is as ready as it can be for launch.
If either of the technical feasibility or user testing stages do not perform as required, then it may be necessary to go back and revisit your hunches, ideas or designs to find something more successful.
Additions for version 4 of the model… The “Track” stage in between the starting knowledge of a problem and forming the first “hunches”. Some, but not all, involve a study of users and/or their behaviours before the solution stages progress. It’s an important stage that was missing before but may not be in every future project you tackle. Feedback loops are more easily marked, if the outcome of Talk, Try or Trial is unfavourable then return to the previous level of understanding to check what went wrong. Finally important to remember that knowledge decays as time goes on!
Assume every project is novel and every brief is fuzzy until proven otherwise.
What Goes Wrong?
The most common mistakes I see on new development projects is almost always teams treating the project as routine when it isn’t. Taking the fuzzy problem definition at the start, assuming they (or their boss or client) know it all at a deep level and thus race through the engineering development or business implementation without ever revisiting or testing those starting assumptions.
Look at the Forbes list of recent product failures or Business Insider’s list of the 25 biggest product flops of all time and you’ll notice one common theme: They all worked, but no one wanted them. Great builders but ignored, rushed, superficial or absent explorers.
So whilst showing the steps on the Fuzzy to Finished process model can reveal big gaps in a projects management it is lacking the critical ingredient: A map.
A map from which you can see where you are, keep track of your route and learn from any mistakes. For that we need to find “innovation balance” in a Cost/Confidence Chart.
A false confidence in the understanding of the problem often means the process is all builder, no explorer…
“We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time.”
T.S. Eliot
Remind me what’s wrong with the existing design processes?
Nothing, if you know for sure that the problem you are trying to solve is Routine, i.e. very clearly defined and where the functioning of a technical solution is the determinant of success. As soon as some complexity creeps in, like getting a human to like that solution, it becomes Novel and a progressive period of exploration into the human’s desires, wants and perceptions is needed. It can’t all simply be worked out at the start.
The simplest way to know is:
Has the customer already paid for you to deliver something specific? Congratulations your project is Routine.
Is the customer waiting to see it before they pay for it? Uh oh, you’ve got a Novel one.
In defence of the traditional design processes, most engineering has been routine, it’s a modern idea to give engineers or developers the privilege of talking to customers. So it wasn’t their fault if the solution didn’t work. But this old method is just terribly inefficient. So we need a better approach.
Some issues I have with the traditional processes:
Only for builders?
From my experience I believe most of the traditional design development process models are created by “Builders” to help “Builders”. They presume the job is routine, or that the “Explorer” phase will be quick. A good problem to be solved identified and understood at the start.
Perhaps only the first stage is devoted to exploring and understanding the problem, usually described in terms around clarify what the customer wants in some form of a design specification.
Lets take the V-Model for example, a very common method for managing technical engineering projects, but designed for what I would call routine projects. Formation of specifications based on the proposal provided in step one leads to a logical sequence of development steps ending up with something that delivers on the brief.
But what if the customer doesn’t actually know what they want? Then you’ve successfully delivered something that is likely to fail once the customer tries it.
Traditional engineering design process models are designed for solving routine problems because that is where they came from, the world of building components… a shaft, widget, bracket, machine. All problems where a good dose of maths with a little fresh thinking will do wonders. But today many of our design problems are human-centred rather than machine-centred. Consumerism, globalisation and capitalism have given us enormous choice in what we want and buy and so the irrational behaviour of us is coming to the fore. Humans are complex and hard to predict. I believe we therefore need to treat designs of things for people as novel, even if they seem simple and obvious.
“The human mind does not run on logic any more than a horse runs on petrol… my assertion is that large parts of human behaviour are like a cryptic crossword clue: there is always a plausible surface meaning, but there is also a deeper answer hidden beneath the surface.”
- Rory Sutherland (Alchemy, The Surprising Power of Ideas that Don’t Make Sense)
No time / difficulty consideration
The second biggest problem I see is that none of the process models consider the difference in time it takes to perform different stages and how this will effect the outcome.
Pahl & Beitz Engineering Design method and the German VD2221 approach, along with many others, logically put stage 1 of their process as clarifying what the problem is, which as we’ve just discussed is really only suited for a builder scenario.
The Double Diamond shows two equal sized phases, a problem discovery phase and a problem finding phase. But this is to stress its importance rather than to be an accurate representation of the method in action.
Let’s suppose the idea for a project comes to the developer as a flash of inspiration, they then discuss it with their friends over a coffee and they all agree it’s a good idea. Discovery phase done? Then they spend 3 years building the project. A couple hours vs a couple years does not look like a particularly balanced pair of diamonds to me… And I’d bet the original problem all those years ago is not still valid today or in the way they imagined it.
Detailed design work, making sure all the tolerances are right, ensuring all the fittings work well together, correct choices of fastners and surface treatments etc… takes a long time, but is a relatively routine task for a professional. Problem finding on the other hand doesn’t fit neatly into a defined box. It is a complex challenge with many different factors, some you can control and some you can’t know. So from my experience it’s something that is uncovered slowly as you progress with your development, not something that’s done and dusted before you start.
Time also changes things, some in ways you can see and some in ways you didn’t think it could. We live in a complex world. The longer time passes the less confidence you should have that your starting idea is still valid.
Dizzy in circles? No one likes going back to the start, it’s demoralising.
The most common way to resolve any of the issues I’ve stated above is to turn the linear process model into a circular one… Discover the problem, solve it, test to see if that really was a problem worth solving, and either repeat or launch.
Sounds simple and it is. Repetition is the principle behind iterative progress. But psychologically I believe it’s troublesome.
A key benefit of process models is in their ability to communicate where you are in the process to the client, the boss or new team members. Once you’re two or three times round the same cycle how do you communicate this effectively? Your journey isn’t easily represented on the single model.
Going around the model, back through a problem discovery phase and to problem solving, for a second, third or even fourth times starts to look like incompetence to someone not deeply aware of the process.
Plus it’s hard to chart your progress. Most novel projects are an evolution journey of discovery and solutions. A circle isn’t in my opinion a satisfactory way to represent this forward progress.
Without a compass how do you know if the map is wrong?
How often have you been lost when following directions?
Back before Google Maps existed (or was reliable) trying to get to a hotel, for example, without a GPS tracker was usually communicated to guests through a series of written or drawn instructions… turn left at the traffic lights, then turn right at the shop, take the second right etc…
The problem with relying on these directions alone, is that if for some reason you don’t end up at the correct destination, it’s very hard to know which step was the one that sent you off course. Did we turn left or right at the lights? Did we miss the turn? Was it the second or third road we took? Have the landmarks changed since the map was drawn?
We’re lost and with little hope of retracing our steps. But having a compass with your map allows you to correct your course. You can find out what went wrong or even find a better route.
Ask any experienced design practitioner or entrepreneur and their journey of discovery was never clear or linear at the time.
So to me, traditional design development process models are like a collection of maps on the shelf. Great for their specific environments (traditional methods have been exclusively drawn for navigating Routine problems) but useless if used for the wrong situation (a Novel problem) and always at risk if used without a compass!
For more information on what you can use as a compass for Novel problems, check out my Jump & Dive project tracker.