Patterns Library — Aware Design in Practice

A pattern is a reusable approach to a design problem. These eleven patterns are options, not a required checklist or proof of a better experience. Start with one worked implementation if you need a first build. Use this catalog when you have a more specific problem.

Try these ideas in the working demonstration. The demo verifies visible behavior, not customer results or a calibrated score.

Start with the problem, not a pattern name. A default is the ordinary experience when no extra information is available. Context is information relevant to the task. An inference is a guess based on that information. The formal reference names are included below, but each section begins with the practical meaning. Effort depends on the scope; a simple choice may be enough where automation would require substantial work.

1. Suggest a likely next step

Reference name: Intent Inference Pattern.

An optional suggestion based on an uncertain interpretation of what someone may need. A direct answer such as “I need support” is often clearer than a guess.

For builders: Define the useful decision first, then the minimum inputs needed for it. Explain collection and obtain appropriate permission. Check interpretations against real tasks, let visitors correct them, and fall back to a neutral page when the information is insufficient. Temporary browser storage is still storage; do not collect mouse movements or other signals by default.

Avoid these mistakes:

• Over-inference from weak signals, leading to incorrect assumptions and frustrating "mind-reading" experiences
• Persistent tracking without clear consent
• Treating ambiguous behavior as a definite positive or negative signal

Example: A software pricing page offers a visible “Compare plans” route. With appropriate inputs and permission, it might also offer that route as an optional suggestion. Tab switching alone does not establish that someone is comparing plans.

2. Arrange content for a chosen task

Reference name: Dynamic Composition Pattern.

Choose or order pieces of a page to serve a task. The pieces might be an introduction, prices and available dates. A small rule can move one piece first while keeping every fact available.

For builders: Start with complete base HTML, named content blocks and an explicit rule connecting an input to a useful order or path. Test the rule and the default. Frameworks, server-side composition and model-based routing are options for more complex requirements—not prerequisites for the starter example. Bound any caching by the data’s purpose and permissions.

Avoid these mistakes:

• Moving sections repeatedly while someone is reading or using a control
• Treating every request as fully dynamic (a significant performance problem)
• Scattering the same rule across several places so it is hard to change consistently

Example: A project dashboard that reorders widgets, hides irrelevant sections, and prioritizes navigation based on the user's role and recent activity.

3. Start with a complete ordinary page

Reference name: Cold-Start Graceful Pattern.

Keep the page useful when the visitor has not chosen anything, declines adaptation or cannot run an enhancement. Missing information is not a failure the site must overcome by watching more closely.

For builders: Render the essential content and navigation before adding an enhancement. Missing or unrecognized inputs should select the ordinary default. Do not start silent observation to escape the default, and do not use an arbitrary signal-count threshold as proof of intent. Add a change only when its input is appropriate and its usefulness can be tested. Keep the page usable when scripts fail.

Avoid these mistakes:

• Showing a blank or generic "loading" state that feels broken
• Collecting extra information without a justified purpose or appropriate permission
• Treating a useful neutral experience as a failure that must be replaced

Example: A workshop page shows all essential information in a normal order. An optional choice can move the requested answer earlier. No answer, refusal or a failed script leaves the full overview available.

4. Limit what the site collects and uses

Reference name: Privacy-First Context Layer Pattern.

Use only information justified by the task. Explain collection, use, storage and sharing separately, and keep a useful route when optional use is declined.

For builders: Map each input, purpose, recipient and retention period. Collect no more than the task needs. The starter can use a choice only in the open page, with no saved preference. If you add memory, analytics or a handoff, make those separate, understandable decisions and enforce the resulting limits before collection or transmission. Managing your own server or storing data in a browser does not by itself guarantee privacy.

Avoid these mistakes:

• Dark patterns that make consent difficult to decline
• Silent fingerprinting or third-party data usage (see Anti-Patterns Gallery)
• Providing no fallback experience when consent is withheld

Example: A workshop page asks which answer the person wants first and uses the selection only on that open page. Saving a preference or sharing it with staff would need separate controls.

5. Remember a chosen preference

Reference name: Cross-Session Memory Pattern.

Let a person save a useful preference for a later visit, with a clear explanation and a way to remove it. Remembering on one browser is different from linking devices through an account.

For builders: If continuity is useful and permitted, retain the minimum relevant preference with a defined lifetime and a visible way to inspect, correct and clear it. Same-device storage and account-based cross-device continuity are different mechanisms. Replacing an identifier with a code does not by itself make the information anonymous. Do not add an identity mechanism merely to support this pattern.

Avoid these mistakes:

• Creepy "We remember you bought X last year" without context or user control
• Stale or incorrect memory leading to irrelevant suggestions (see Anti-Pattern: Stale Memory Syndrome)
• Heavy reliance on third-party identity providers for memory persistence

Example: A design tool offers to save a chosen “dark theme” preference. On return, it explains that the saved preference is in use and provides a reset.

6. Offer help without taking over

Reference name: Proactive Flow Adaptation Pattern.

Offer an optional shortcut or explanation at a useful point. Proactive means offering help before someone asks; it does not mean interrupting them or deciding their task for them.

For builders: Model the task and offer an optional shortcut with a clear reason. Rules may be sufficient; a model is not required. Idle time or back-button use can have several explanations and must not force a new flow. Keep the original route and an obvious dismissal.

Avoid these mistakes:

• Interrupting the user with unsolicited help (the annoying modal problem)
• Assuming intent too early and forcing the wrong flow
• Providing no "dismiss forever" option for proactive elements

Example: A travel booking site offers “Compare these flights side by side” beside the selection list. The visitor can choose that shortcut or keep the original list; the site does not need to guess whether they are hesitating.

7. Carry useful context forward

Reference name: Context Retention Pattern.

Keep selected task information where it remains useful—for example, an unfinished comparison or a reviewed summary for support. Do not retain an entire history just to avoid repeating one answer.

For builders: Let the person review the context worth retaining, its purpose and lifetime. Use an appropriate storage/identity mechanism only when needed and permitted; a substitute identifier is not a substitute for privacy controls. Before a handoff, show the summary and recipient and allow editing or refusal. On return, provide a clear reset and do not silently revive an old assumption.

Avoid these mistakes:

• Retaining irrelevant or outdated context (showing last year's promotions as if current)
• Zero transparency — user has no idea why something is being shown
• Over-retention that feels like permanent surveillance rather than helpful memory

Example: A support portal offers to retain a chosen billing task on the same device. On a later visit it offers “Resume billing help” and “Start fresh.” Cross-device continuity would need a separate, explained identity mechanism.

Emerging Patterns

The next four options include straightforward controls and more experimental automation. Letting someone choose a shorter explanation can be simple; generating new explanations or learning from behavior adds accuracy, privacy and maintenance questions.

8. Let readers choose the level of detail

Reference name: Adaptive Tone Pattern.

Offer a short explanation, more technical detail or another appropriate presentation of the same facts. An explicit preference is not a judgment about intelligence or expertise.

For builders: Start with an explicit choice such as “Short explanation” or “Technical detail.” Preserve the facts and let the visitor switch back. A language model is optional; generated variants need accuracy, accessibility and safety checks before use.

9. Offer different ways to interact

Reference name: Multi-Modal Adaptation Pattern.

A modality is a way to give or receive information, such as text, voice or touch. Offer useful alternatives with clear controls and equivalent access.

For builders: Offer supported formats with clear controls and request any required device permission when the person chooses that feature. Keep an accessible text alternative; do not assume a device capability is a preference.

10. Learn from task outcomes

Reference name: Real-Time Feedback Loop Pattern.

Use appropriate feedback to test whether a change helps, then improve or remove it. A feedback loop means using what you observe to inform a later decision; it does not prove the decision will be better.

For builders: Begin with bounded rules and a defined task outcome. Collect only justified, appropriately permitted feedback; do not call it anonymous merely because names are absent. Compare against the ordinary experience and allow the person to reset.

11. Enforce limits before acting

Reference name: Ethical Guardrail Pattern.

A guardrail is a rule or control intended to stop an unacceptable action. Define limits on data, content, access and behavior, then test whether the system actually enforces them.

For builders: Define enforceable rules for allowed inputs, content, actions and fallbacks. A safety model may supplement checks but cannot guarantee safety. Test actual rendered states and explain relevant limits without exposing sensitive information.

Using This Library

Choose a pattern only when it addresses an identified problem. Use the catalog to:

• Audit existing products against the Aware Design paradigm
• Communicate implementation priorities across design and engineering teams
• Evaluate vendors and tools based on which patterns they enable or obstruct
• Explain which parts are established in your implementation and which still need testing

See the Anti-Patterns Gallery for the counterpart reference — the common mistakes that undermine each of these patterns in practice.