Personalisation begins with a journey problem
A service website often gives every visitor the same pages, proof and enquiry route. That may be exactly right. Clear information can help people recognise the relevant service and act.
Personalisation becomes worth considering when a specific visitor decision remains unnecessarily difficult. A person might need to identify the right service, see proof relevant to their situation or answer only the questions that apply. The site could change content, proof, questions or next steps using context supplied by that visitor.
Start with the journey problem. Name the choice that visitors struggle to make, the evidence for that problem and the improvement you expect to observe. A clearer page or short deterministic rule may solve it with less uncertainty than AI.
Adaptive journey logic is also separate from the interface that delivers it. A static form can sit on a personalised page, while a chatbot can give every visitor the same experience. If the interface is still undecided, first compare forms, chatbots and live chat.
Choose the least complex useful level of adaptation
A static journey is the first level. Everyone sees the same service explanation, proof and next step. It suits a focused offer, a small audience or a problem that good information architecture can resolve. Establish this version as the baseline before adding adaptation.
Deterministic rules are the next level. A visitor who selects commercial electrical work sees the commercial service route. Someone outside the service area sees a clear alternative. The same input always produces the same result, and the team can inspect every branch. Rules aren't AI, even when the experience feels responsive.
Declared-preference tailoring lets the visitor state what they want and change that choice. A goal, service type, location or project stage can shape the next content and questions. This can reduce irrelevant material without silently inferring intent from behaviour.
Bounded AI inference becomes relevant when inputs are too varied for practical rules. A model might interpret a visitor's free-text project description and suggest which approved service page to read. Its job should remain narrow, reviewable and reversible. It shouldn't determine a consequential outcome or infer sensitive traits as a starting use case.
Move up when verified variation exceeds the current level. Greater sophistication creates more work in data handling, evaluation, explanation, accessibility, monitoring and recovery. A feature earns that work by making a useful decision clearer.
Start with declared context before inferred intent
Consider a worked example for a fictional building-services consultancy. Its website serves owners planning new facilities, managers upgrading existing sites and builders seeking specialist input. Visitors regularly enter the wrong service path because the internal service names don't match the language used at the start of a project.
The simplest useful adaptation asks the visitor to choose their project stage. The site then brings forward the relevant service explanation, two approved examples and an appropriate enquiry route. The visitor can change the selection at any point, and the standard navigation remains available.
That declared choice is easier to explain and test than a silent prediction based on browsing history. It also gives the business a clear content task. Each variation needs accurate service facts and relevant proof.
AI may later help interpret a free-text description when visitors genuinely cannot choose among the declared options. The output could recommend a route and ask for confirmation. If the interpretation is wrong, the visitor must be able to correct it without restarting.
When adaptation begins to assess fit, route an enquiry or write to a CRM, it has moved into a wider operational system. At that point, design the qualification and system handoff as a separate controlled decision.
Set a boundary around data and inference
Start with the least information needed to produce the useful adaptation. Where the Australian Privacy Act applies, the OAIC APP 3 guidance updated in May 2026 says personal information collected by an organisation must be reasonably necessary for its functions or activities. It describes proportionality as implicit in that test and calls for data minimisation. Sensitive information has stricter requirements.
Ask what the signal reveals, why it is needed, where it goes, how long it remains useful and whether the same result is possible with less information. A service selection provided for the current session carries a different burden from a persistent profile assembled from behaviour across visits.
AI inference needs particular care. The OAIC guidance on commercial AI and privacy says inferred information about an identified or reasonably identifiable person can itself be personal information. For covered organisations, it recommends due diligence, transparent notices, accuracy controls, human oversight and lifecycle monitoring.
Privacy coverage depends on the organisation, activity and information involved. This article is practical design guidance, not legal advice. Obtain advice suited to the business before processing sensitive information or using personalisation in decisions that may significantly affect someone.
The choice becomes easier when expected visitor value and the data or trust burden are considered together. These two axes separate a useful bounded pilot from an idea that should remain a rule or be rejected.
Value and data burden determine the personalisation route
Visitor value increases
Pilot
High expected value with limited, declared data
Bound and review
High expected value with substantial data or inference
Use a simple rule
Modest value with limited data
Reject
Modest value with substantial data or inference
Data and trust burden increases
A high-value idea with a substantial data burden needs tighter scope, specialist review and evidence that a less intrusive route falls short. Modest value rarely justifies collecting more information simply because the technology can use it.
Keep the whole journey accessible and recoverable
Adaptation must preserve the visitor's understanding and control. Dynamic questions need clear labels and instructions. Validation should identify the problem and help the person recover. A changed result should be announced in a way that works with assistive technology.
The W3C WAI Forms Tutorial explains how labels, instructions, validation and feedback contribute to accessible forms. It doesn't establish complete accessibility conformance on its own. The full journey still needs keyboard, screen reader, zoom and mobile testing, including every adaptive state.
Keep a comparable non-personalised route. A visitor who declines a preference, withdraws a signal or receives a poor recommendation should still be able to find the services and make contact through ordinary navigation.
Plan for missing and incorrect signals before launch. If location is unavailable, show the general route. If an AI interpretation is uncertain, ask the visitor rather than acting as if the answer is known. If the system fails, retain the visitor's work where possible and offer a clear alternative.
Recovery may also need a person. Explain when staff become involved, what context they receive and what the visitor should expect next. The guide to designing a safe human handoff develops the disclosure, correction and escalation route in more detail.
Give AI a bounded job and an owner
A useful AI purpose can be written in one sentence. For the worked consultancy example, the model's job might be to map a visitor's project description to one of four approved service routes and ask the visitor to confirm. It cannot decide eligibility, alter pricing, infer protected characteristics or send information to another system without the visitor taking the stated next step.
The NIST AI Risk Management Framework Core places governance, context, measurement and management around AI risk. Applied here, that means documenting the intended purpose, affected people, approved inputs, output limits, evaluation method, owner, monitoring and response when performance falls outside the accepted boundary.
The Australian Government published its Guidance for AI Adoption on 21 October 2025. Its six implementation practices cover accountability, impact assessment, risk management, transparency, testing and monitoring, and human control. This is voluntary guidance rather than a new legal duty. It provides a useful operating structure for a pilot.
An owner needs authority to change or pause the experience. They need examples of correct and unacceptable outputs, a review cadence and an incident route. The business should also know which supplier handles each signal and whether that handling matches what visitors were told.
Personalised facts and proof must come from approved sources. If service definitions, locations, claims or case studies are contradictory, adaptation will distribute the inconsistency more efficiently. Prepare reliable business knowledge before asking a model to select from it, then put practical governance around the pilot.
Pilot one adaptation against qualified outcomes
Test one meaningful adaptation within the existing journey. In the worked consultancy scenario, the pilot could test declared project-stage tailoring on one high-intent service entry page. The tailored version changes the order of approved content and the recommended next step while the existing page and enquiry route provide the baseline.
Record completion and qualified outcomes using the same definitions across equivalent review periods. Also monitor correction, abandonment, accessibility failures, privacy incidents and staff effort. If AI is introduced later, sample its recommendations and the visitor's confirmations rather than relying only on aggregate clicks.
Vendor benchmarks often describe different audiences, products and definitions of success, so they cannot promise an uplift for this journey. The relevant evidence is whether the pilot improves qualified outcomes within its trust, accessibility and operating-cost boundaries.
Write the pilot boundary before live visitors encounter it so the later decision remains traceable to evidence.
Set the interpretation before reading the result. Continue when the adaptation improves the chosen qualified outcome and remains within the agreed data, accessibility and effort boundaries. Revise when a specific recoverable weakness is visible. Stop when it causes material harm, crosses an approved data boundary or fails without a reliable fallback.
The wider measurement guide explains how to measure reliability, outcomes and operating cost once a system moves beyond a focused website test.
Personalisation should make the next decision clearer
Static content remains the right answer when the journey is already clear. Deterministic rules suit known variation. Declared preferences suit choices that visitors can provide and correct. Bounded AI earns consideration only when variable inputs create useful work that simpler approaches cannot handle.
The standard is a clearer visitor decision within an operating boundary the business can explain, test and maintain. That boundary includes permitted data, accessible alternatives, approved knowledge, human control, monitoring and stop conditions.
When the work spans service content, interaction design, analytics, privacy choices and connected systems, it should be scoped as one lead journey. A website design and lead-journey engagement can bring those decisions together before the technology exposes visitors or staff to avoidable complexity.