Introducing Cognitive Support UX: a framework for designing interfaces that help people actually figure things out.

There is a moment every product designer knows exists, but rarely gets to witness in real time.

A user sits in front of something you spent months building. The navigation is logical. The copy has been tested. The colour contrast passes WCAG 2.1 AA. And yet — the user stops. They scroll back up. They read the same line twice. Their mouse drifts toward the back button. They are not confused about where to click. They are confused about what any of it means for them, right now, in this decision.

They are stuck. And your interface — despite being technically correct — is not helping them get unstuck.

This is not a corner case. It is, increasingly, the central design problem of our time.

The problem has a name, but not yet a method

We have been designing for usability for decades. We have frameworks for findability, accessibility, task efficiency, and error prevention. What we have not had — until now - is a rigorous, end-to-end method for detecting cognitive friction, understanding what a user is actually trying to figure out, and designing interfaces that measurably help them think.

That gap is what Cognitive Support UX was built to close.

This is Part 1 of a five-part series introducing the Cognitive Support UX Framework — a research-to-design system for teams building complex, AI-augmented, or high-stakes digital products. This first article covers the origin of the framework, the theoretical foundations that make it work, and the closed-loop model at its core.

“Users do not fail because your interface is ugly. They fail because your interface does not support the cognitive work they came to do.”

Where this came from: the pattern we kept seeing

Across products in fintech, healthcare, enterprise SaaS, and e-commerce, the same friction pattern kept appearing. Teams would run usability tests, watch users struggle, fix the navigation, and still see the same drop-off. They would A/B test copy, reduce steps in the flow, add tooltips — and the metrics would barely move.

The problem was not usability in the conventional sense. The problem was that users arrived at these products in the middle of a sensemaking process. They were not just trying to complete a task. They were trying to figure something out: Is this the right plan for me? What happens if I choose this option? Am I about to make a mistake I cannot undo?

And the interface — no matter how well-designed — was treating them as if they already had the answers.

This is where the research started. Not with heuristics, but with a question: what is the user trying to figure out right now?Followed by a harder one: how would we even know?

The theoretical ground: why this framework stands on solid science

Cognitive Support UX did not emerge from intuition alone. It draws on four bodies of research that, taken together, explain both why users get stuck and what kind of design actually helps.

Cognitive load theory (Sweller, 1988) tells us that working memory is finite and precious. Every unnecessary element in an interface — an extra option, an ambiguous label, a process users cannot predict — consumes mental resources that should be spent on the actual decision. When interfaces pile on what researchers call extraneous load, users do not just slow down. They give up, choose poorly, or abandon.

Sensemaking and information foraging theory (Pirolli & Card, 2005) describes how people search for and construct meaning. Users do not navigate linearly — they forage for information, follow “information scent,” and cycle between gathering and interpreting until they feel confident enough to act. When that foraging loop breaks — when the scent goes cold, when the information gathered does not add up — users stall.

Situation awareness (Endsley, 1995) decomposes cognition in dynamic environments into three layers: perception (do I see the relevant information?), comprehension (do I understand what it means?), and projection (can I predict what happens next?). Users can fail at any of these layers. Fixing one rarely fixes the others.

Distributed cognition (Hutchins, 1995) shifts the unit of analysis from the individual mind to the whole system: the person, the interface, and the context together. This legitimises designing external scaffolding — checklists, summaries, calculators, progressive disclosure — not as nice-to-haves but as genuine cognitive infrastructure.

These are not abstract theories. They are the diagnostic tools that make the framework precise. When you understand which layer of cognition is failing, you can design an intervention that actually addresses it — instead of guessing.

The framework: a closed loop, not a checklist

Cognitive Support UX is structured as a continuous cycle. Crucially, it is not a waterfall — each stage feeds into the next, and interventions are treated as hypotheses to be validated, not solutions to be shipped and forgotten.

The loop has five stages:

Here is what each stage does — and why the order matters.

Stage 1: Cognitive Awareness

What is the user trying to figure out? Where does comprehension break down?

Before you can detect friction, you need to understand it qualitatively. Cognitive Awareness is the research layer: moderated think-aloud studies, intent-capture prompts, NASA-TLX workload profiling, cognitive task analysis. The goal is to build an Intent and Uncertainty Map — a structured picture of users’ goals, unknowns, decision criteria, and the precise moments where their mental model fails.

This is not standard usability testing. The tasks are decision-focused and scenario-driven. The probes dig beneath “what are you doing?” to “what are you trying to decide?” and “what would you need to know to feel confident?”

The output is a Stuckness Taxonomy: a categorised evidence base of where and why users lose comprehension.

Stage 2: Behaviour Detection

How do we detect the same friction signals at scale?

Qualitative research explains stuckness. But it cannot scale. Behaviour Detection is the instrumentation layer that translates Stuckness Taxonomy findings into measurable telemetry signals: pause patterns, navigation loops, error cascades, repeated help-seeking, drop-off at specific steps.

The goal is not surveillance. The goal is to build reliable friction indicators — validated against qualitative ground truth — that can trigger support at the right moment, for the right user, without requiring a researcher in the room.

Stage 3: AI Intervention

What assistance do we deliver, and when?

This is where cognitive scaffolding becomes active. AI Intervention is the design of user-facing supports — contextual hints, next-step suggestions, layered explanations, error recovery guidance — delivered precisely when Behaviour Detection signals elevated cognitive effort.

The AI layer must be designed with two principles that are often in tension: reduce friction without removing autonomy. The user must remain the decision-maker. The interface is there to clarify, not to choose.

Stage 4: Adaptive Interface

How does the interface itself change to reduce complexity?

Where AI Intervention is about adding support, Adaptive Interface is about removing extraneous load from the UI itself. Progressive disclosure, complexity tiering, flow simplification based on friction evidence — these are not guesses. They are design decisions grounded in Cognitive Awareness data and validated by controlled experiments.

Stage 5: Validation and Governance

Did it work? Is it safe? Is it fair?

Every intervention in this framework is treated as a hypothesis. The validation layer closes the loop: A/B experiments, sequential testing, qualitative follow-up, equity audits across user cohorts, and safety checks on AI outputs. Governance ensures that what is shipped is trustworthy, transparent, and reversible.

Why now? The AI urgency

Two things have changed that make this framework not just useful but urgent.

The first is the complexity of modern products. Users now navigate AI-generated recommendations, dynamic content, multi-step decision flows, and personalised experiences that shift beneath them. The cognitive demands have increased — but the design methods have not kept pace.

The second is that AI is being deployed as a UX layer without the research infrastructure to support it. Teams are building AI interventions — chatbots, copilots, suggestion surfaces — without knowing what users are actually trying to figure out, without measuring whether the AI is reducing or increasing confusion, and without governance for what happens when it gets it wrong.

Cognitive Support UX is not a framework for designing AI. It is a framework for designing for people, using AI as one possible tool in a larger system.

“The question is not whether to use AI in your product. The question is whether you understand your users’ cognitive state well enough to use it responsibly.”

Who this is for

This framework is deliberately platform- and industry-agnostic. The principles apply equally to:

• Fintech products where users are making high-stakes financial decisions under uncertainty
• Healthcare interfaces where clinicians or patients must interpret complex, consequential information
• Enterprise SaaS where onboarding complexity drives churn before users ever reach value
• Consumer products where drop-off at key decision points is misread as a copy or design problem

The common thread is not the sector. It is the presence of users who arrived at your product in the middle of figuring something out — and an interface that is not helping them get there.

What comes next

This series is structured to be both readable and actionable. Each part builds on the last:

• Part 2 — Cognitive Awareness and Behaviour Detection: the research methods, instrumentation design, and how to build a Stuckness Taxonomy your team can actually use.
• Part 3 — AI Intervention: designing cognitive scaffolding that supports agency, calibrates trust, and measures whether the help actually helped.
• Part 4 — Adaptive Interface and Validation: running experiments that prove your simplifications work without harming expert users or specific cohorts.
• Part 5 — The Practitioner’s Playbook: the consent templates, study protocols, dashboard templates, and toolstack that make the framework deployable in real teams.