Compare the visitor journey, ownership and maintenance work before integrating an experiment, linking a separate site or deferring it.
A useful experiment can become confusing when it occupies the same space as the business’s core offer. A visitor arrives to find a service and encounters an unfinished game, a prototype tool or a second brand with no explanation of the relationship.
Before giving the experiment a domain or a prominent navigation slot, decide what job it does for the intended audience. Then choose a home that makes its status, ownership and route back to the main business clear.
The examples below are fictional architecture choices. They do not report traffic, leads or learning outcomes from any existing AI Empower project.
Compare two very different experiments
Experiment A: preparation checklist. A repair studio wants visitors to work through three questions before bringing in an item. The questions explain the same service offered on the main site. Staff maintain the answers alongside the service page.
This has a strong case for integration. Place it where visitors prepare for the service, give it a plain title and keep the ordinary information available without the interaction. A separate brand could make a small preparation task feel like a different business.
Experiment B: pattern-matching game. The studio’s designer builds a playful demonstration of an interaction technique. It does not assess repair needs, accept enquiries or provide customer advice. Its development cycle differs from the main site.
A clearly labelled experiment area or separately hosted page may fit better. Explain who made it, what it demonstrates and that it is a prototype. Provide a clear route to the main business without presenting the game as part of a paid service.
Neither choice proves the experiment is worth maintaining. It only describes a plausible placement if the purpose and ownership are established.
Sketch the visitor journey both ways
For an integrated version, draw: service page, optional interaction, useful result, next service step. Ask whether the result helps the visitor answer the question that brought them there. If the interaction interrupts the task or requires unrelated data, reconsider its placement and scope.
For a separate version, draw: main-site introduction, labelled experiment, explanation of limits, return to the main site. Check whether the visitor can still identify the business, find ordinary contact information and tell whether they are in a demonstration.
Use text labels before visual styling. The W3C Menus Tutorial treats navigation structure and clear menu states as practical accessibility concerns. A novel visual treatment still needs understandable links and predictable operation.
Fill in the placement board
For your own non-sensitive concept, complete six entries:
- Audience: who arrives, and whether they are the same people as the main service audience
- Purpose: the specific question or task the experiment helps with
- Status: concept, prototype, limited trial or supported service, with evidence for the label
- Ownership: who reviews its content, code, feedback and broken links
- Dependencies: hosting, data, analytics, access and any external service it needs
- Exit: what happens if the experiment is paused, replaced or abandoned
Now make a reasoned decision:
- Integrate when the experience directly supports a main-site task and can meet the site’s maintenance and quality expectations.
- Separate and link clearly when the purpose or experimental status needs a distinct setting, with a visible relationship to the main business.
- Defer when the audience, owner or ongoing work is unresolved.
These are editorial decision options, not a weighted formula. Do not let a high score for “fun” cancel an unknown owner or an unreviewed data dependency.
READER WORKBENCH / WEEK 43
Give the experiment a reasoned home
Compare fit, ownership and dependencies. An unresolved owner cannot be cancelled out by a high entertainment score. This is a planning decision, not a cost estimate.
Fictional local exercise. No live AI, backend, business verification, analytics, accounts or paid services. Working state is kept in page memory; deliberate copies, prints and browser/device-managed data are outside this tool’s control. This is not a privacy guarantee, release approval, measured outcome or accessibility certification. Enter fictional, non-sensitive examples only.
Review pending · current working preview
Defer: resolve the open placement questions
- Proposed placement: integrate
- Reason: It answers the same preparation question as the service page.
- Visitor route: Service page → optional checklist → result → preparation instructions
- Visible ownership/return label: A repair-studio prototype. Return to ordinary service information.
- Owner: unknown
- No weighted score or invented maintenance price is used.
- This recommendation is conditional on the supplied fictional assertions; no hosting, dependencies, routes or actual staff capacity were verified.
Unresolved warnings
- Unresolved: Fictional maintenance owner
- Maintenance capacity is not established.
- Dependency and data-flow review is unresolved.
- Simulated proposal review has not been recorded.
Superseded evidence snapshots retained: 0. These are exported as historical records, never counted as current passes.
WEEK 43 — Give the experiment a reasoned home
Fictional local exercise. No live AI, backend, business verification, analytics, accounts or paid services. Working state is kept in page memory; deliberate copies, prints and browser/device-managed data are outside this tool’s control. This is not a privacy guarantee, release approval, measured outcome or accessibility certification.
Review pending: the current input preview has not been reviewed
Defer: resolve the open placement questions
Proposed placement: integrate
Reason: It answers the same preparation question as the service page.
Visitor route: Service page → optional checklist → result → preparation instructions
Visible ownership/return label: A repair-studio prototype. Return to ordinary service information.
Owner: unknown
No weighted score or invented maintenance price is used.
This recommendation is conditional on the supplied fictional assertions; no hosting, dependencies, routes or actual staff capacity were verified.
UNRESOLVED WARNINGS
Unresolved: Fictional maintenance owner
Maintenance capacity is not established.
Dependency and data-flow review is unresolved.
Simulated proposal review has not been recorded.
EXACT CURRENT INPUTS
{
"audience": "Repair-studio visitors preparing an item",
"task": "Understand what to bring to the repair studio",
"alignment": "direct service task",
"status": "prototype",
"statusBasis": "Fictional prototype; not offered as a supported service",
"owner": "",
"maintenance": "Content, dependencies, accessibility, links and ability to remove it; estimates not yet obtained",
"capacity": "unknown",
"dependencies": "Static example. No input collection is needed. Hosting and release review still required.",
"dependencyReview": "unresolved",
"exit": "Remove the experiment link, keep the ordinary preparation information, show a clear replacement note",
"route": "Service page → optional checklist → result → preparation instructions",
"brand": "A repair-studio prototype. Return to ordinary service information.",
"choice": "integrate",
"reason": "It answers the same preparation question as the service page.",
"approved": "no",
"note": ""
}
HISTORICAL EVIDENCE SNAPSHOTS (not current; preserved failed and superseded attempts)
[]
External verification not performed: live sites, actual services, source refresh, production integration, real browser/mobile, screen readers, physical keyboard, actual clipboard permissions, printing/pagination.Use the text-only exercise
The complete unchanged manuscript remains readable if the controls are unavailable.
Return to Fill in the placement boardGive prototype labels practical meaning
“Beta” says little by itself. Explain what the visitor can do, what the result means and where the experiment stops. For the fictional game, a useful note would be: “A pattern-matching interaction demo. It does not evaluate repair needs or submit a service request.”
If the experience collects information, review that data flow separately. Calling something a demo does not make uploads, analytics or account creation harmless. Prefer a fixed fictional example when personal input is unnecessary.
Keep the main service promise consistent wherever it appears. An experiment page should not introduce an unsupported guarantee or imply that a prototype is available to customers under the same conditions as a supported service.
Count the maintenance work before the pages multiply
List the actual recurring checks: content accuracy, dependency updates, accessibility, contact links, domain ownership, error states and the person who can remove an unsafe or broken entry point. Get real estimates for the relevant implementation. Do not assume a separate page has no ongoing cost because it was quick to make.
Finally, ask a colleague to enter through the proposed link and explain where they are, what the experience is for and how to return to the business. Record any uncertainty before polishing the visual treatment.
Your output is a placement decision with reasons and an owner. That keeps experimentation useful while giving the main website a clear, dependable service story.
Primary sources checked 4 October 2026
Sources & review
Primary sources checked on . The checklists and planning examples are AI-assisted editorial guidance, not source quotations or reported client results.
This AI-assisted guide uses fictional examples for practice. It does not report client results or establish that a live system will behave the same way.
Originally published: .