4 min read

Paradigms and Patterns: The Idea and the Technique

Plain definitions for two terms used in the papers, with examples and a guide to the pattern catalog.

On this page — choose a section

A paradigm is a way of thinking. A pattern is a reusable way to solve a problem. For example, “start with the visitor’s task” is a guiding idea. “Let the visitor choose which answer appears first” is a technique for applying it.

You do not need these terms to use the guides. This page explains them for readers who encounter them in the longer papers.

What Is a Paradigm?

Here, a paradigm means an organizing approach—not a certification or proof that previous design was wrong. Different approaches draw attention to different questions:

Scroll sideways if needed to read the whole table.

Paradigm Core Question
Static Design "How do we publish information digitally?"
Responsive Design "How do we make experiences work across different screen sizes?"
Material / Flat Design "How should interfaces look and feel?"
Aware Design "How do we build experiences that truly understand and respond to each individual person?"

Aware Design asks what the person is trying to do and whether an appropriate choice or piece of context could make the next step easier. Screen size, accessibility, clear writing and ordinary navigation remain important.

We use two names for applying the approach in different settings:

  • Visitor-Aware Design (VAD) — Public websites where a person may not be signed in.
  • User-Aware Design (UAD) — Applications with relevant, permitted account information.

What Are Patterns?

A pattern gives a team a name for a possible solution. It should explain the problem it addresses, how it works and where it can go wrong. A named pattern is not a requirement or proof that the technique will help your visitors.

For example, a useful-default pattern says the page must still work when no choice is available. A memory pattern asks how a person can save a preference and later clear it. These solve different problems; a project may need one and not the other.

The relationship is simple:

  • Approach: decide what a visitor needs and what would help.
  • Setting: a public website or a signed-in application.
  • Techniques: choose only the solutions the task calls for.

This is a vocabulary for discussing decisions, not a reason to make a simple project sound complicated.

Visual Hierarchy

Aware Design Paradigm Hierarchy Aware Design is the umbrella paradigm. Two specializations branch from it — Visitor-Aware Design for websites and User-Aware Design for applications. Eleven named patterns describe optional techniques and safeguards, not a required stack. Aware Design Start with the person’s task Visitor-Aware Design For public websites A stated need or appropriate context User-Aware Design For signed-in applications Account history · continuity 11 named patterns 1 2 3 4 5 6 7 7 common design concerns 8 9 10 11 4 additional capabilities and safeguards
The approach gives the direction; patterns are possible techniques. Numbers refer to the list below, not a maturity score.

The Patterns of Aware Design

The pattern catalog includes the following options. The first seven cover common design concerns; the last four discuss additional capabilities and safeguards. None is a tested result merely because it has a name.

  1. Intent Inference Pattern — Suggest a likely next step, while admitting uncertainty.
  2. Dynamic Composition Pattern — Choose or arrange content for a stated task.
  3. Cold-Start Graceful Pattern — Keep a complete ordinary page when information is missing.
  4. Privacy-First Context Layer Pattern — Limit what information is collected, used and shared.
  5. Cross-Session Memory Pattern — Remember a preference the person chooses to save.
  6. Proactive Flow Adaptation Pattern — Offer an optional shortcut without taking over.
  7. Context Retention Pattern — Carry forward only useful, reviewed context.
  8. Adaptive Tone Pattern — Offer a choice of language style or detail.
  9. Multi-Modal Adaptation Pattern — Provide alternatives such as text, audio or touch.
  10. Real-Time Feedback Loop Pattern — Check task outcomes before changing the experience further.
  11. Ethical Guardrail Pattern — Enforce limits on data, content and actions.

Explore the full Patterns Library for detailed descriptions, implementation notes, and anti-patterns to avoid for each.

Why This Distinction Matters

A team can add many features without making a task easier. It can also make a useful improvement with one small rule. Judge the result, not the number of patterns or the size of the architecture.

Start with a real question, choose an appropriate technique and check whether it helped.

Next: Websites and signed-in applications