Is it a Routine or a Novel problem?

Now that you have an idea to work on, is it a technical based one where scientific investigation and technical expertise is what you need? Does having a team of people who have done this type of thing many times before more or less guarantee success? If so I would class it as Routine. That is not to say it is easy, they can be very complicated and difficult; building a jet engine, a skyscraper, an aircraft, a nuclear power station are all routine problems. Because having the right team, enough time and resources guarantees a successful technical solution. People might not want it, but it’ll work. 20 years and £25bn built an incredible aircraft the likes of which the world had never seen. But sadly the economics of air travel had changed during that development cycle, or perhaps they never existed in the way they needed to, but either wait the Airbus A380 was an expensive commercial failure. Perhaps it shouldn’t have been treated as a grand (but routine) engineering challenge after all?

The alternative to a Routine problem is a Novel one.

If the problem is new to you that you don’t know where to begin or that through it’s very nature it has an uncertain and unpredictable outcome. Perhaps because its success is based on irrational human nature or complex unknowable situations. Then you have a Novel problem and need a different approach.

To solve a Routine problem, just follow the map, someone somewhere will have done it before and will have one. Success could be judged on it working or not.

To solve a Novel problem, there is no map, you need to be an explorer as well as a builder. Trusting in ‘experts’ who claim to have done this before is a potential trap. Their false confidence may lead you astray, handle them with care. Success could be judged on people wanting it or not.

Further links, notes and advice:

• More thoughts on Novel & Routine problems

• How to build the map for tracking a Novel problem and learning from your mistakes

• Different Leadership and management styles for Novel and Routine problems

Clarifying the Task and Investigating the Need with Customers

Whenever you’re given a design task, you need to clarify if what you think they want is what they actually want. Or what you think the user of your design wants is actually what they want. Solving the wrong problem doesn’t help, no matter how well you solve it.

For a Routine problem, the expectation is usually that a quick conversation with the client or the holder of the original idea will clarify the situation and you’ll be able to write it all down as a Design Specification, have it agreed and then off you go!

The problems arise when the client doesn’t actually know what they want or you’ve confused a Novel problem for a Routine one. Novel problems you don’t know what the objective is yet, you know you want to do something but it’s unclear how that helps and if that’s the best thing to do. Your understanding of the problem starts Fuzzy and takes the whole development process to be firmed up into something concrete and definite.

Further links, notes and advice:

• Some ways to try and better understand customers

• Finding ideas that are important but also not currently well served

• How and why to conduct market research

• Rapid testing of your understanding through a ‘Minimum Viable Product’

Design, Opportunity and Technical Specifications

Traditional engineering processes and teaching is centred around solving technical problems (Routine problems in my language). In that world of predictable problem solving you need to establish a design specification at the start so that everyone knows what the goal is.

This is not possible for Novel problems, the unpredictable nature of the problem means it’s an impossible task and will very likely lead to frustration and disappointment further down the line. So instead, try to establish an Opportunity Specification (a broad list of the customer pain points we’re trying to solve and will form the basis of the subsequent business case). The aim is to obtain management approval that trying to solve these customer issues is a worthwhile endeavour whilst leaving the technical details and method for solving them free and open. The designers are then able to solve it however they are best able without needing to constant get permission for changing the spec.

Once the project is finished, the design has been agreed, you can write up your conclusion into a technical document that details exactly the different elements (an essential step if you’re ever handing the designs over to a contract manufacturer to build for you!)

Further links, notes and advice:

• Different types of design specifications

Establishing the Business Case

Whatever you’re doing has a cost associated with it, your time, any resources used, any research conducted etc… So unless you’re doing the project as a hobby, someone is paying for it and thus a business case needs to be made.

What is the job / idea worth when finished? How much is the client paying for it or what might it be worth if we were to make and sell it? Does the time, effort and cost we’re putting into it make sense compared to what the project is worth?

Further links, notes and advice:

• How to write business plans, the approach I use and teach is what I call the WHAT, WHY and HOW method because you can adapt it to any situation. More advice on this will be coming soon.

Creativity, Idea Generation and Prototyping

The good bit every designer loves, the actual coming up with the ideas. For many everything up to this point is just boring admin…

Why do I start with Hunches rather than Ideas? It’s a little trick a designer friend taught me, for many people an idea is precious, like a new born baby. No one wants their new baby to be criticised or worse told that it’s ugly and horrible! This becomes a real sticking point for many teams and can cause ‘design fixation’.

The solution is very simple, change your language and refer to all the initial ideas (that a almost certainly ugly and horrible) as hunches. There isn’t the same psychological baggage with the word and everyone is happy for their hunches to be rejected. After all, it was just a hunch.

Prototyping is an essential part of the creative process, it is not a model making exercise at the end. Even more important for Novel problems to start prototyping straight away on day one.

Further links, notes and advice:

• How to generate ideas

• The dangers of design fixation and how to overcome it.

• Decision making and how to choose ideas

Embodiment and Detailed Design

Turning your idea into something real typically goes through some common steps where the workload gets greater and greater as the level of detail gets more and more precise. The initial design for a ship might take only 20-man-days, whereas the final detailed design ready for manufacture might take 60,000.

The process of moving from an early design to a more detailed one is very well documented and researched with many design processes out there to help you.

The method you use is personal choice down to you but be very careful if you’re working on a Novel project that you don’t lose track of the customer, don’t forget to regularly test your designs, at every stage, because you can’t be certain the idea is a good one until the end.

All traditional engineering design methods are designed for Routine problems… creative firms who deal exclusively with Novel problems, such as advertising firms often have no process at all. Which is fine for an advert but not ideal for a product where people might be harmed if it went wrong.

Further links, notes and advice:

• Creative processes

• The dangers of traditional processes when applied to Novel problems

• A new creative process for Novel problems

• Some extra resources to help you with Novel problems

• Reverse engineering other people’s ideas to give you a head start

The Final Reckoning

Unfortunately for Novel problems, you won’t know if you were right until after you launch the design and you see if anyone wants it. There’s just no way to be certain before hand, the challenge is too complex with too many unknowable unknowns.

But by following a balanced approach you will give yourself the best possible chance.

For Routine problems it is not uncommon for your customer to commit to the project near the start after the developer has assessed the brief and developed a deep understanding of the need. You pay the tour guide before you start the journey, but explorers and speculators are paid if they find something. With Novel problems, it’s highly unlikely the customer will pay for the work upfront for the simple reason they don’t know what they want yet. Only once you’ve done all the hard work will you know if you have something anyone wants.

Speculators and explorers are not gamblers, they are not guessing blind. To be effective they are logical and methodical, but their methods do not look like those of the builders or guides. It’s a different type of process.