Poor Sir Clive Sinclair. He was a British institution in the early 1980s, yet things were about to take a bad turn for this successful entrepreneur. He had a radical vision, something we take for granted now, in a world full of tech visions. The “world’s first electrically powered car” was what he was about to unleash upon the unsuspecting British public in a glitzy launch in 1985. It was essentially an electrically assisted pedal cycle that took advantage of favorable new legislation that allowed electrically assisted two-and three-wheeled vehicles on UK roads.
“What could go wrong?” he thought. “Everyone will love a compact, smart, and cheap way of getting around British roads. Let’s just start building the things and everyone will see the genius of my vision. Look, I drew a sketch of it here. It’s sleek, gray, and can go 15mph with a range of 20 miles. All it needs is a small motor. Let’s have a big launch now, before production has started.”
You can see where this is going.
Product people love to innovate, don’t we? But do all design problems need innovation? How do we know if we are innovative? What problem is so low level that it can just be automated? Thinking about this can be overwhelming at the beginning of a large design project. Breathe….
I realized recently that design teams do not have many suitable tools to size projects from a purely design perspective. Both the development and product team have their sizing methodologies and all the big D’s like design thinking and Double Diamond don’t bother with this fundamental issue. We fall back on a standardized process and attempt to fit all design problems, big and small, easy and complex, into a narrow set of rules. Problems are all treated the same way.
Cynefin, pronounced “kuh-nev-in” is a Welsh word that means “habitat” or, more poetically, a “place of multiple belongings.” It’s an unusually lyrical name in a world dominated by imposing industry tools like design thinking, Double Diamond, Agile, and scrum.
Cynefin could only have come from the land of Dylan Thomas. Developed over many years by Dave Snowden, who worked in IBM during the 90s, he was interested in how he could apply complexity theory, a knotty area, to decision making.
The framework is a sense-making tool that helps to identify the nature of a problem, and therefore the best approach to solve it. According to Dave, understanding the world and making informed decisions is about having sufficient knowledge to act appropriately in context.
The Cynefin framework allows you to classify problems or issues into one of five domains: clear, complicated, complex, chaotic, and disorder. Each domain requires a different approach to problem solving.
One of the other ideas that comes out of this is in embracing ambiguity. Embracing ambiguity doesn’t give you the right answer, but it gives you better ones while showing you which are wrong, an important philosophy to keep in mind throughout your process.
If we assess a design problem as simple, such as creating a registration form, the product team can use best practices and established rules to solve it. Complex problems, such as creating a new product category, the team may need to experiment and iterate to find a solution.
The Cynefin framework has its differences from other design approaches:
It is important to note that the Cynefin framework is another tool and complements many other design methods we can employ.
At the beginning of any new initiative, epic or design project, you will hopefully be handed a well-structured product pitch together with beautifully crafted job stories. (A bit of dark product humor there.)
I list out some questions I need answers to, such as:
Then, I consult the framework and which one of the five domains this design problem might fit into. Let’s start with a few examples that cover the growing range of complexity.
Our company wants a new product live by yesterday. This product needs a robust login flow. These flows are standard patterns and luckily we have a design pattern at hand as we already built one. The flow includes standard components such as form fields, buttons, password rules, validation, and so on.
Clear problems, also referred to as “simple” and “obvious” problems, are those that are straightforward and easy to understand. The solution is obvious and can be found by applying best practices or consulting an expert. They have a clear cause-and-effect relationship. Knowledge and expertise needed to solve these problems are widely available, and the solution can be found by following established procedures.
Our solution is to select the most efficient login flow. This problem is straightforward, and the solution is obvious as the flow should be the most efficient and fast pattern we can find. Nothing exciting or difficult here.
The strategy is to “sense” by looking at the data, then “categorize’” by looking for patterns and best practices, and finally “respond” by taking action.
Since our business goal is to get users into a product quickly, our design goal is not to innovate, but to get users in quickly and safely. It is important here that we are not reinventing the wheel but using what we have at hand to solve the problem. Then we can use this same cause-and-effect analysis to identify if this solution is working or not. If not, then there is a clear solution. We can keep refining until we get a successful outcome.
Our next design problem is about fixing product performance issues. Things are slowing down on certain screens. We lack effective feedback when they do, and users are getting frustrated. Let’s start by asking questions.
Complicated problems are harder to understand. The solution to these problems is not immediately obvious, and it may require a more in-depth examination of the problem. They do still have a clear cause-and-effect relationship. These types of problems can be solved by breaking them down into smaller parts and using a more detailed analysis.
Our strategy here is a little similar to a clear problem, which is to “sense” by looking at the data, then “analyze” (we need to go further than simply categorizing) by looking for information from experts, and finally “respond” by taking action.
These performance issues will need the review of experts. As this problem touches so many parts of the product, we need to account for different scenarios. We can get our data from analytics, the customer service team can help us, and we have enough developer expertise to solve the issue. Again, we were not obligated to innovate here, as we want to get this job done quickly.
By redesigning how screens render their content, using standard loading patterns and feedback and monitoring the effects, we can solve this issue quickly. We need more input and thought, but we can still use standard design patterns.
Clive Sinclair initially thought that the British public would embrace a cheaper vehicle sounds obvious. Who wouldn’t want a cheap way of getting around city streets? Easy to park, easy to maintain. He applied similar patterns to this thinking, yet he only consulted with a few experts, much of which he ignored. The car was rushed into production, and relied too heavily on his instinct and a belief that enough marketing and some pizzazz would get his vision through to the public. He was the greatest British boffin, after all.
We are getting into thornier and more unpredictable problems now. We are building a mobile accounting app, and we instinctively know that this is a complex problem as our questions are getting longer and more involved. There might be room for innovation in this project.
Complex problems are those that are difficult to understand and have many potential solutions. These types of problems are often characterized by multiple interrelated factors and unpredictable outcomes. The solution to these problems is not immediately obvious, and it may require a more in-depth examination of the problem and experimentation to find the best approach.
Our strategy should be to “probe” by doing user research, then “sense” by looking at what data we’ve gathered, and finally “respond” by taking action.
We can solve these problems by experimenting and trying different approaches. This means that instead of trying to find a single solution, multiple solutions are tried and tested to see which one works best. These experiments can also lead to happy accidents where we learn something new and novel. This might spark a new idea, using the adjacent possible concept of combining existing features in new ways.
Testing different approaches allows for a deeper understanding of the problem and helps to identify the root cause of the problem to discover the most effective solution.
It’s crucial when experimenting to have clear evaluation criteria and to measure the results with good data, letting us understand immediately which approach works better.
I present a roller coaster of challenges. Let’s take a drastic and unexpected change in privacy regulations that affects a product. This new data privacy law changes the way a company can collect and process personal information. Again, there could be room for innovation.
Changing regulations is highly unpredictable and has no clear cause-and-effect relationship, because the new regulations can be complex and can change the way a product operates. These types of problems are characterized by rapid change, high levels of uncertainty, and a lack of structure. Without dealing with this issue, it might lead to significant compliance issues and financial losses.
In Organiszng Knowledge, Patrick Lambe puts it best when he says that “action — any action — is the first and only way to respond appropriately.”
Our strategy is to “act” by doing what we think needs doing as soon as possible, then “sense” by looking at what data we’ve gathered to see if it solves the problem, and finally “respond” by taking action.
So this problem requires immediate action and adaptation as the situation changes, such as reviewing the product and its infrastructure to ensure compliance with the new regulations, updating the terms of service and privacy policy, and providing transparency and control to customers on how their data is being used.
Having a flexible and adaptive approach can help to minimize the impact of the problem, such as creating a plan for dealing with unexpected situations and putting a team in place that can respond quickly and effectively.
Sinclair found himself in chaos during the middle of 1985. The C5 faced various challenges in its development and manufacturing, including inadequate battery life, poor handling and stability, and low durability. The choice to use unconventional materials such as a plastic shell and a lightweight frame made it difficult to manufacture the vehicle at a cost-effective price.
The complexities piled up, and he didn’t respond fast enough. He also failed to do proper market research. Was it a car? Was it a bike? Things didn’t get it off to a promising start when he launched the C5 into a drab and wet British winter. It was a complete disaster. Production ceased within a year, with only five thousand sold.
Finally, the confused domain, sometimes known as disorder, is when you are not sure which category a problem belongs to. Establish a shared understanding of the problem before deciding on a course of action. There is also a secondary term used here called aporia, which means doubt, uncertainty, or a difficult-to-solve problem or question.
When a problem falls into the category of confused, it means that the nature of the problem is not immediately clear, and it’s difficult to determine which category it belongs to. Take a step back and establish a shared understanding of the problem before deciding on a course of action. Without a clear understanding of the problem, it’s difficult to determine which approach to problem-solving is the most appropriate.
This process should involve asking questions, gathering data, and conducting research to gain a better understanding of the problem and its context. It is essential to decompose the situation into manageable chunks and categorise them accordingly. By breaking down the problem into smaller components, you can better understand and address each individual issue.
Keep an eye out for chaotic problems, as they can be detrimental if left unaddressed and without a proper solution. Your top priority should be to establish a method of categorizing the problem, moving it from unknown to known.
Sinclair’s C5 was a brilliant idea ruined by unforeseen and chaotic circumstances. Industrial designer Gus Desbarats, who worked on the C5, said that Sinclair “failed to understand the difference between a new market, computing, and a mature one, transport, where there were more benchmarks to compare against.” If he had not let the brilliant vision blind him to the rather unfortunate complexities that lay ahead, our roads might be full of smug tricyclers.
Next time when you’re feeling overwhelmed by a design problem, remember to take a step back and consult the framework.
The Cynefin framework will help you understand the nature of your design problems, staying flexible and allowing you to select the best approach to solve them.
I’ve only scratched the surface with this article, and if you want to learn more, Cynefin — Weaving Sense-Making into the Fabric of Our World is a great place to learn in more depth, and of course there are Dave Snowden’s copious writings on thecynefin.co.
Header image source: IconScout
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
