Aware Design
A practical introduction for website owners — and what it means for your strategy.
For senior leadership. This is a design proposal, not a report of measured customer results. Follow the links for practical guides and optional reference.
Start with the person’s task,
not another technology layer.
Different visits call for different starting points. The person should not need to learn your organization’s structure to find an answer.
| What the visitor needs | A useful starting point |
|---|---|
| Understand the offer | A short explanation and example |
| Compare options | Scope, cost, evidence and limits |
| Complete a task | A clear action and what happens next |
| Get help | A direct support route |
A useful default. A relevant next step.
Start with a complete ordinary experience. A clear visitor choice and a small rule can make the next step more relevant; if the rule or enhancement fails, the website must still work.
Visitor-Aware Design (VAD)
For websites where a person may not be signed in. An explicit task choice can be enough; a persistent profile is not required.
User-Aware Design (UAD)
For applications with account context. Use only relevant, permitted context; signing in is not blanket permission.
Choose the simplest implementation that helps.
- AI capabilities may support advanced assistance, but are optional for a first rule.
- Activity reporting on your own servers is one option, not a privacy guarantee.
- Guesses based on browsing need testing; a clear answer from the visitor may be better.
Do not collect data or add a model just because the architecture can. Begin with an actual task and a useful ordinary route.
What do your current website tools cost?
- Content management
- Analytics
- Marketing automation
- Personalization
- Tools that record or map activity
- Chat / conversational
- Search visibility tools
- Hosting and content delivery
These are categories to inventory, not costs we have measured for your organization. Compare actual spend, integration work and task outcomes before proposing a replacement.
A handoff can lose useful context.
A visitor spends minutes — or hours — on the site. They contact the organization. The person who answers knows nothing. "How can I help you?" The conversation starts from zero.
A person may choose to review, edit and share a task summary with a named recipient. Browsing alone is not something they deliberately told a staff member, and a blank request must remain available.
Keep useful context only when it is appropriate.
Avoid asking people to repeat information they have chosen to share.
Aware Design asks a simple structural question: what context would help this person, and do they want to carry it forward?
Measure whether a reviewed handoff helps. Do not save a full behavioral history merely because it might be useful later.
What did this person come to do?
People may arrive for different reasons. These quoted needs are illustrations, not facts inferred from clicks.
Discovery
"I didn’t know this existed."
Evaluation
"I’m comparing options."
Decision
"I’m ready to act."
Support
"I need this NOW."
A “journey” means the purpose of a visit. Help the person with that task rather than forcing everyone through the same sequence.
One website.
Three different needs.
A fictional leadership-development organization illustrates three possible audiences:
- Corporate buyer — comparing training for a team.
- Individual learner — looking for a course with a suitable date, format and price.
- Aspiring certified facilitator — checking the requirements to become a certified trainer.
The proposal changes emphasis for an explicit need and offers an optional reviewed handoff. It is not a measured customer result or a guarantee that discovery is no longer needed.
Make relevance understandable and controllable.
A pattern to avoid
Unexplained targeting, sensitive identity guesses and controls that are difficult to refuse. Personalization is not inherently surveillance; the actual design and data use matter.
Aware Design
Use explicit needs and appropriate context, explain changes and preserve a useful default. Separate a choice made now from permission to remember or share it.
Potential benefits to test.
- Can people find a relevant offer more easily?
- Does a reviewed handoff reduce repeated questions?
- Does optional assistance give accurate, useful answers?
- Do useful outcomes improve against the ordinary experience?
Costs and trade-offs to measure.
- Time needed for discovery and handoffs.
- Support effort, including errors introduced by adaptation.
- Content maintenance and accessibility across every state.
- Actual implementation, hosting, model and ongoing review costs.
Choose one useful technique, not every feature.
Start with one task, one explicit choice and a small rule. Test whether the change helps before adding inference, memory or an assistant.
Your existing content management system may support the change. Choose technology that fits the task and that your team can maintain.
The Library includes practical options and more experimental proposals. Neither a pattern name nor a model is evidence of effectiveness.
Shared ideas. Professional services.
The guides and papers are free to read. Professional assessment, design and implementation are paid work.
You can use the ideas with your own team. If you need help, agree on the problem, deliverables, evidence and budget.
Confirm current service availability and scope. A technique described in the Library is not a promise that a product or course is available.
Three concrete next steps.
-
Consider your website.
Compare three situations, including when a simpler site is enough.
-
Choose one small experiment.
Work through a first build: input, rule, result and fallback.
-
Talk to us.
Talk through a first build with the task, proposed change and open questions in view.
The slides are an overview.
Your next step can be small.
Use the guides to decide and build. The longer papers explain the reasoning and limits; they are not independent proof of customer results.
Choose the question that matters to your website.