Context Design

The problem is rarely just the screen

Most design projects begin with an output already in mind.

A new website. A better checkout. An internal tool. An automated workflow. An AI assistant. A campaign that needs to perform better.

But the thing being designed is often only the visible part of a much larger problem.

A confusing customer journey may have started with the way the business is structured. A slow process may exist because several teams are working around an old system. Poor content may be the result of unclear ownership rather than weak writing. A new technology may fail because it has been introduced without considering the people expected to use it.

This is where I think about Context Design.

Context Design means looking beyond the immediate output and understanding the conditions surrounding it: the customer, the business, the technology, the operational reality and the decisions that led to the problem in the first place.

This is a method for analysing problems before deciding on a specific design solution.

Designing the thing is not enough

A product or service does not exist in isolation.

It sits within a network of people, systems, commercial pressures, habits, workarounds and competing priorities. Change one part without understanding the others and the solution may create a different problem somewhere else.

A new interface can make a task appear simpler while increasing the workload behind the scenes. Automation can speed up a broken process rather than improve it. AI can produce more content without solving the question of whether that content is useful, accurate or needed.

The quality of the final design depends on how well the surrounding context has been understood.

That means asking questions such as:

Who is this really for? What are they trying to achieve? What happens before and after they interact with it? Who maintains it? Which teams are affected? What commercial or technical constraints are shaping the decision? What has already been tried? What behaviour is the current system encouraging? And, perhaps most importantly, are we solving the right problem?

The visible problem and the real problem

Businesses often become very good at working around problems.

Manual tasks become normal. Spreadsheets become systems. Knowledge becomes concentrated in one person. Customers learn to tolerate unnecessary steps. Teams create their own processes because the official one no longer works.

Eventually, one of these symptoms becomes visible enough to require attention.

The brief might ask for a redesign, a new platform or an automated solution. But responding only to the brief can mean treating the symptom while leaving the cause untouched.

A content problem may actually be a workflow problem. A navigation problem may be an organisational problem. A conversion problem may begin much earlier in the customer journey. A technology problem may really be a confidence, training or ownership problem.

Context Design is about tracing the visible issue back through the system until the real opportunity becomes clear.

Sometimes the answer is a better interface. Sometimes it is a new process, clearer information, a change in ownership or the removal of something that should never have existed.

You should not measure the quality of a design by the amount of work produced. You should measure it by whether the situation improved.

Connecting customer needs with business reality

Customer-centred design is essential, but customer needs cannot be considered separately from the organisation delivering the experience.

A solution also needs to be commercially viable, technically possible and operationally sustainable.

That does not mean compromising the customer experience in favour of the business. It means finding the point where the needs of both can be aligned.

The strongest work usually sits between disciplines.

It connects customer behaviour with commercial goals. It connects creative thinking with technical constraints. It connects new technology with a genuine use case. It connects what a business says it wants with what its systems and processes are currently capable of delivering.

This is often where the most valuable opportunities are found: not within one department, but in the gaps between them.

Why context matters even more with AI

AI has made it easier to generate ideas, content, imagery, code and analysis at extraordinary speed.

But speed does not remove the need for judgement.

Without the right context, AI can produce an impressive answer to the wrong question. It can automate inconsistency, multiply poor decisions and create large volumes of work that nobody actually needs.

The value of AI comes from understanding where to apply it rather than simply using the technology.

That requires knowing what the business is trying to achieve, what information the system can rely on, where human judgement remains important and how the output will be used in practice.

AI works best when it is introduced as part of a considered system, rather than added as a feature because the technology is available.

The tool may be new. The need to understand the problem is not.

This is starting to be named

In July 2026, the Nielsen Norman Group published an article coining the term "UX-context design". It describes a shift in what UX work actually produces: away from documents written for humans (personas, journey maps, reports) and towards curated context that guides what AI generates directly.

I'm not claiming to have coined this or borrowing authority I don't have. The point is smaller and more useful than that: a respected UX institute has independently arrived at the same description of the shift, which suggests it's a real direction in the industry rather than a personal theory. Read the NN/g article.

None of this is new to me; it's what the projects on the Work page already were. The naming is what's new.

My approach

I tend to begin before the solution.

I examine the customer journey, the current process, the systems used, and the people who perform the work. I attempt to identify points of friction, information loss, and areas where the organisation has adopted practices that are no longer effective.

From there, the work may become a customer experience project, a digital product, an automated workflow, a content system or a broader operational change.

The output depends on the problem.

My role is often to connect areas that have previously been considered separately and turn a complicated situation into something people can understand, act on and improve.

That is what Context Design means to me.

Not designing an isolated screen, service or tool.

Designing with an understanding of everything around it.