The Visitor-Aware Design Manifesto

A practical argument for websites that respond to visitor needs, with examples, limits and a small first step.

On this page — choose a section

The idea in one sentence: a website should help people do what they came to do, rather than make everyone work through the same explanation in the same order.

You do not need to know web-development terminology to read this paper. If you want a quick demonstration first, try the workshop example. For a practical project, use the first-build guide.

Start with a familiar problem

Imagine a business that offers both team training and individual courses. A company buyer wants to know whether a program fits a team. An individual wants a date, a price and a way to enroll. Both land on the same long homepage and have to search past information meant for the other person.

A clearer page and better navigation may be enough. Another option is to ask, “Are you looking for training for yourself or for a team?” The site can explain that the answer changes which information appears first. Prices and essential facts stay the same, and both routes remain available.

That is a small example of Aware Design: using an appropriate piece of context to make the next step more useful. It is not a requirement to add AI, watch every interaction or build a profile.

What we mean by a visitor-aware website

A visitor-aware website can change the order, emphasis or next step based on a person's stated need or other appropriate context. A rule connects an input to a result: “When someone chooses team training, show team-program information first.”

A more advanced site might combine several inputs or use a model to suggest a route. A model's interpretation is a guess, not knowledge of a person's identity or intentions. More complicated machinery needs more evidence and safeguards—not more confident marketing.

Three distinctions matter:

  • A useful change is not the same as a visible change. Moving content is easy to demonstrate. Showing that the new order helps people requires testing.
  • Asking is often better than guessing. An explicit answer can be clearer than time on a page or a sequence of clicks.
  • A complete ordinary page remains essential. People who skip a question, reject an assumption or cannot run the script must still be able to use the site.

This overlaps with good navigation, personalization and human-centered design. The label does not make a solution better; the visitor's experience does.

What the visitor should notice

Ideally, someone finds a relevant answer sooner and understands why the page changed. They should not have to learn our terminology or discover a hidden “mode.”

Explain a choice beside the control that makes it: “Choose what you want to see first. You can change this at any time.” Afterward, explain the result: “Team programs are now first. Individual courses are still below.”

Keep navigation stable. Do not move a focused control, erase an unfinished form or hide essential information while someone is using it. A change intended to help can become a new obstacle if the person loses their place.

Different visits can have different goals

We use journey to mean the task or purpose of a visit—not a fixed personality type. Someone may be learning what a business does, comparing offers, trying to complete a task or seeking help.

A sales funnel describes steps an organization hopes people will take, such as visiting, inquiring and buying. It can be useful for reporting, but it should not force a support visitor through a sales pitch.

The journeys paper describes ten possible needs. They are prompts for design, not ten proven categories that every person fits. A visitor may change goals or have several at once. Keep a straightforward route for people whose needs you do not know.

What needs to be built

For the small training example, you need four things:

  1. Clear content for each offer.
  2. An understandable choice.
  3. A rule that changes the order without changing the facts.
  4. A useful default and a way to reset the choice.

A component is a reusable piece of a page, such as a price card or a list of course dates. Composition means choosing or arranging those pieces. You can use components without a language model, a persistent visitor record or an entirely new website.

A content management system, or CMS, lets a team edit and publish content. It may be part of this solution. Whether a particular CMS, plugin or custom build can support your rule depends on the actual implementation—not on a blanket claim that traditional tools cannot do it.

Optional detail: larger implementations

A larger system may need rules shared across pages, approved content variants, a record of permitted preferences and a way to explain each decision. Give every input a defined purpose, lifetime and recipient. Do not collect a full browsing history simply because it might be useful later.

Self-hosting means running software in infrastructure you manage, rather than using only a provider's ready-made service. It can change your control and responsibilities. It does not, by itself, make information anonymous, eliminate other providers or establish legal compliance.

Test both the rules and what people actually see. Correct code can still produce a confusing page. Missing information, a wrong assumption, keyboard use, a small screen and a failed script all need useful outcomes.

Where this may help—and where to be careful

Scroll sideways if needed to read the whole table.

Setting A useful starting point A boundary to keep
Business website Let people choose the service or audience they are interested in. Do not infer a job, budget or likelihood of buying from clicks.
Public service Organize instructions around a stated task, such as renewing a permit. Do not hide services or decide eligibility from browsing.
Healthcare Offer clear ways to find information, prepare questions or contact care staff. Do not infer a condition or replace professional advice.
Education Let a learner compare schedules, formats and requirements. Do not guess ability, age or financial circumstances.
Nonprofit Provide distinct routes for learning, volunteering and donating. Do not turn a guess about emotion into pressure to donate.
Publishing or community Let people choose interests and find what has changed. Preserve access to other topics and a way to start fresh.
Internal application Make a known, authorized task easier to reach. Keep permissions separate from what the interface recommends.

These are design possibilities, not measured customer results. The sector paper works through them in more detail.

How to judge whether it is worth doing

Start with a real problem: people cannot find prices, choose the wrong inquiry route or repeat information when they ask for help. Record what happens now. Then compare the clearer ordinary page with the proposed change.

Useful measures include task completion, mistakes, time to a relevant answer and the effort needed from staff. More clicks, longer visits or an impressive animation do not establish success.

A handoff is the move from a website to a person, such as a support agent. An optional summary may save repetition, but the visitor should review, edit and choose what to share with a named recipient. Their browsing is not something they deliberately told that person.

Claims about higher conversion, better sales predictions or lower costs need their own evidence. A system does not automatically improve with every visit, and a larger dataset is not automatically a more useful one. The business-case paper explains a grounded comparison.

Why we call this a design approach, not an AI feature

Web development has brought useful improvements: easier publishing, participation, layouts that fit phones, faster delivery and reusable components. Those improvements already serve people. Aware Design does not claim to have invented that goal.

The papers sometimes call the approach the “ninth paradigm.” Here, paradigm means a way of thinking about design. The phrase is the authors' historical framing, not an agreed industry classification or proof that everything before it was wrong.

Our practical emphasis is simpler: start with the visitor's task, then choose the technology. Adding a chatbot to an unclear website does not fix its navigation or explain its offer. Conversely, a small, well-explained rule can help without AI at all.

What changes when someone signs in?

Visitor-Aware Design (VAD) is our name for applying these ideas to websites where a person may not be signed in. User-Aware Design (UAD) applies them to applications with account context.

An application may already know a person's selected role, unfinished task or saved preference. That can help it offer a useful next step. Signing in does not authorize every use of account data, and it should not silently attach earlier browsing to the account.

The shared standard is understandable help with appropriate controls—not knowing everything about someone.

A sensible first step

Pick one visitor task and identify where the current site makes it difficult. Improve the ordinary page first. If one clear choice would help, write down its input, rule, result and fallback before building it.

Decide whether this fits your website or work through the small implementation example. You do not need to adopt a whole architecture to test one useful change.