What am I actually fixing?

One of the most valuable lessons I learned during my time in QA was that, no matter how thoroughly you test a piece of software, someone will eventually do something you never thought to test. You can define the happy path, cover a reasonable range of edge cases, simulate different conditions and spend considerable time trying to break the system and then someone uses it in a way nobody anticipated.

Not necessarily incorrectly. Not necessarily maliciously. They simply approach the software with different expectations, different information or a combination of circumstances that never appeared in your testing. That's the reality of building software for people and it taught me something that has stayed with me throughout my career: good preparation isn't about anticipating everything that could go wrong. It's about understanding what matters, reducing the most significant risks and making sure that, when something does go wrong, the consequences are as limited as reasonably possible.

Years later, that thinking has become an important part of how I approach product design. It's also one of the reasons I've been developing a reasoning framework to help me navigate the complexity of projects. At its centre is a question that sounds almost too simple:

What am I actually trying to fix?

The problem behind the problem

Product work often starts with a brief that already contains a proposed solution. We need a new dashboard. We need to redesign the navigation. We need to introduce another component. We need to simplify a particular workflow.

Sometimes those requests are entirely appropriate, but sometimes they describe a symptom rather than the underlying problem. Imagine going to a doctor because you have a persistent cough. You ask for something to suppress it, and the doctor gives you exactly that. The treatment might work beautifully at suppressing the cough, but if the cough is caused by something that requires a different intervention, we've treated the symptom without addressing the cause.

Product design can fall into the same trap. People might struggle to find information, so we introduce more navigation options, but perhaps the information was organised around internal business structures rather than the way users actually work. People might abandon a form, so we simplify its interface. But perhaps the real problem is that they're being asked for information they don't have available at that point. We can implement the requested solution perfectly and still fail to address the problem that made someone request it.

That's why I want to understand what is actually happening before deciding what needs to change and sometimes the investigation confirms that the original request was exactly right. The objective isn't to challenge every brief for the sake of challenging it. It's to establish whether the proposed intervention addresses the problem we need to solve.

The smallest reasonable intervention

Over time, I've developed a preference for finding the smallest reasonable intervention that produces the greatest reasonable impact.

Both uses of reasonable are deliberate. This isn't about always choosing the cheapest, fastest or smallest possible solution. Sometimes changing a single operational rule removes a substantial amount of friction without requiring any interface changes, sometimes a small adjustment to an existing interaction is enough and sometimes the problem is rooted so deeply in the product's architecture that a substantial redesign is the most appropriate response.

The objective is to understand the scale of the problem before deciding the scale of the solution. If we can solve something effectively without introducing additional complexity, that's usually worth considering, but if a series of small fixes would merely disguise a fundamental problem, the larger intervention may actually be the more reasonable one.

What I'm trying to avoid is spending time perfecting a solution before establishing whether that solution is necessary, because there's a difference between making a proposed feature better and determining whether the feature deserves to exist.

Experience should make the questions better

I've been thinking quite a lot about what actually makes an experienced designer faster. It isn't necessarily the ability to produce screens more quickly. Experience helps us recognise patterns, anticipate complications, identify familiar problems and understand which questions are likely to matter.

That can reduce the number of iterations needed to arrive at a sound solution, but experience also introduces a risk. When something looks familiar, it's tempting to assume we already understand it.

We recognise a pattern, remember what worked previously and begin moving towards a solution before checking whether the circumstances are genuinely comparable and that's where I wanted some help.

Not help making decisions for me, but rather help remembering what I should question before making them.

I wanted something that could remind me of relevant considerations, surface assumptions, identify unanswered questions and point towards previous situations that might offer useful context. Something that would make the reasoning I've accumulated through experience more explicit and that's how the ConScept framework began taking shape.

Building a framework that asks, rather than answers

The framework isn't intended to prescribe a particular design process or produce a recommended solution at the end of a sequence of steps, its purpose is to support investigation and judgement.

It starts by examining the problem, the evidence available and the assumptions behind our current understanding. It helps identify questions that may need answering, including questions we might not have thought to ask. Some answers may be sufficient immediately. Others might reveal a need for deeper investigation. And some may expose entirely different explanations for the original problem.

The framework should also help distinguish between a question that materially affects the decision and one that is interesting but unlikely to change the outcome.

That's an important distinction because asking more questions isn't automatically better. A framework that encourages endless investigation without helping people decide when to proceed would introduce another problem rather than solve the original one.

What I want is something that helps me establish whether the answers to the questions we've identified are sufficiently developed to support an informed decision.

Not whether every possible uncertainty has been eliminated and not whether we've anticipated every scenario that might emerge in the future. Just whether we have enough relevant context to understand the available options, recognise the trade-offs and proceed responsibly.

Knowing enough doesn't mean knowing everything

No framework can guarantee that a decision will be correct, but it doesn't need to. The objective isn't certainty. It's informed judgement.

We make decisions using the information available at the time, while recognising that some assumptions may later prove incorrect and that's perfectly reasonable. A well-informed decision can produce an unexpected outcome. A poorly informed decision can occasionally produce an excellent one.

Neither outcome, on its own, tells us whether the original reasoning was sound. What matters is whether we understood the problem sufficiently, considered the relevant alternatives, recognised the significant risks and consciously accepted the trade-offs.

The amount of investigation should also reflect the consequences of getting something wrong. A minor, easily reversible interface adjustment doesn't require the same depth of investigation as a change affecting sensitive data, critical operations or a fundamental part of the product architecture and even with extensive investigation, some uncertainties can only be explored once the system encounters real-world conditions.

That's not an argument for inadequate preparation. It's an acknowledgement of the limits of controlled environments.

The real world doesn't follow our test scenarios

Development environments, staging environments and usability studies are all valuable. They allow us to verify intended behaviour, explore foreseeable edge cases and observe how people interact with a solution, but they cannot exhaustively reproduce real-world conditions.

Even usability testing, which introduces actual human behaviour into the process, takes place within some form of controlled setting. Participants are generally given a task or placed in a particular scenario. They know they're participating in a study, even when the researcher carefully avoids influencing their behaviour.

Real users don't operate within those boundaries. They start tasks with incomplete information. They get interrupted. They change their minds. They return days later. They encounter unusual combinations of data, use features in unexpected sequences and develop approaches nobody thought to include in a test plan.

These aren't examples of people using the software incorrectly. They're the conditions in which the software actually needs to work. We can anticipate categories of disruption and design appropriate safeguards. We can preserve progress, support recovery and prevent isolated failures from causing disproportionate harm, but we cannot predict every possible sequence of circumstances.

That was one of the most important lessons I took from QA and it means that good preparation must include not only preventing foreseeable problems, but also limiting the consequences of unforeseen ones.

Prepare for consequences, not every possibility

Consider a system handling sensitive information.

It isn't enough to test whether the expected workflows operate correctly. We also need to understand what could happen when something fails, particularly when there may be people deliberately trying to exploit weaknesses. The objective is to establish protections that make serious consequences as difficult as reasonably possible to reach.

That requires identifying the highest risks, preventing them where possible and introducing safeguards so that an individual failure doesn't unnecessarily compromise the entire system. The same thinking applies beyond security. A temporary connection failure shouldn't automatically erase hours of work. An unexpected input shouldn't unnecessarily compromise an entire workflow. A problem in one area shouldn't bring down unrelated capabilities if the architecture can reasonably prevent it.

Not every failure deserves the same level of preparation. We need to understand both the likelihood and the consequences, then allocate attention accordingly and that investigation doesn't end when the product is released.

New evidence, changing conditions and unexpected behaviours will continue to reveal things we didn't know. The important thing is to remain capable of learning and responding without treating every new discovery as a reason to stop everything else.

Fail fast, and fix just as fast

A former director I worked with at a previous job had a saying that stayed with me:

“Fail fast and fix just as fast.”

I think the second half is particularly important. Failing quickly isn't valuable by itself. If the consequences are severe, difficult to contain or impossible to reverse, discovering the failure early may offer little comfort. The ability to respond matters just as much as the ability to discover what isn't working.

For me, the principle is about preparing sufficiently to act, learning from what happens and responding proportionately when reality challenges our assumptions. It also means recognising that not every discovery requires reopening a decision immediately.

A critical vulnerability or a finding with potentially serious consequences may demand immediate reassessment. A minor usability issue might be important, but it can reasonably enter the normal prioritisation process.

The urgency of reconsidering a decision should reflect the significance and potential impact of the new evidence and sometimes a decision that was entirely reasonable when it was made will need to change because the circumstances around it have changed.

That doesn't make the original decision a failure. It means our understanding has evolved.

Decisions should remain open to scrutiny, but they don't need to remain permanently under scrutiny.

There is a time to investigate, a time to commit, a time to observe and a time to reconsider. Knowing the difference is part of good judgement.

The unexpected role of AI

AI has played a substantial role in helping me develop this framework. I've used it to explore relationships between questions, identify overlaps, challenge assumptions and translate parts of my intuitive reasoning into something more explicit.

It's been particularly useful when examining whether a particular question should lead to further investigation, whether similar questions serve different purposes and whether the overall structure remains coherent as it grows, but the more I developed the framework, the more convinced I became of something that might sound slightly contradictory.

I don't want it to depend on AI.

AI can make the framework easier to navigate. It can help surface relevant questions, examine alternatives and accelerate parts of the investigation, but the underlying reasoning should remain understandable and usable without it.

If a framework only works because a sufficiently capable AI can compensate for unclear relationships or missing logic, then I haven't really captured the reasoning effectively. I've simply moved the dependency somewhere else.

I want the framework to be useful whether someone works through it manually or uses AI to assist them which led me to a rather amusing realisation.

I used AI to help build a reasoning framework that doesn't need AI.

And I'm perfectly comfortable with that because AI was never supposed to be the foundation. It was a tool that helped me develop the foundation.

Something that should work without me

There's another principle behind the framework that has influenced much of my work over the years.

I don't particularly like building things that depend on their creator remaining involved. A design system should be understandable and maintainable by the people who inherit it. Governance should help teams make appropriate decisions without constantly asking the original author for permission. A product architecture should make sense beyond the person who first designed it.

I want the ConScept framework to follow the same principle. It may originate in my experience, but its value shouldn't depend on someone sharing that experience. The reasoning should be explicit enough that other people can understand it, challenge it and improve it.

In fact, I would consider it a positive outcome if someone finds a question I overlooked or a relationship that doesn't work as intended. That would mean the framework is being tested beyond the limits of my own perspective and that's exactly what it needs.

I don't want it to preserve my judgement as something unquestionable. I want it to make that judgement available for examination.

Back to the original question

Ultimately, I'm not building this framework to introduce another mandatory process into product development. I'm building it to help make better-informed decisions and to identify the problem before choosing a solution. To recognise which questions need further investigation. To understand the trade-offs we're accepting. To prepare for the consequences of failure without pretending we can anticipate everything and to know when we have enough information to move forward.

The framework itself will need to evolve as it's used. It will encounter situations I haven't anticipated, expose assumptions I didn't realise I'd made and require adjustments as new evidence emerges which is fitting, really, because the same question that started the whole exercise applies to the framework itself.

What am I actually trying to fix?

If the framework helps people reach a clearer understanding of their problems, make more defensible decisions and avoid unnecessary work, then it's serving its purpose.

If it simply adds complexity to something that already worked well enough, then I've created another problem to solve.

And I should be willing to recognise that, too.