How it works

An interactive walkthrough that writes itself

Most in-app guidance is a script someone wrote last quarter. Wayhint looks at the page your user is on, picks one step, and shows it. Then it looks again.

The loop, one step at a time

  1. The user says what they want

    From the Ask Pepper button, or from your own help link with Wayhint.ask("…"). Their words, not your menu names.

  2. The widget takes a snapshot

    Buttons, links, fields and menus that are visible right now, including inside open shadow roots. Each gets a short id. Labels only; input values are never read, and emails or long numbers are masked.

  3. The guide picks exactly one step

    Point at an element, say something, or finish. The server checks the element exists on this page, so Pepper can’t point at something that isn’t there.

  4. Pepper walks over and points

    The control gets a spotlight, the bubble says what to do, and Pepper stays beside it while the page scrolls.

  5. The user clicks, and it starts again

    Menus open, routes change, full pages load. The goal is kept for the browser tab, so the guide picks up on the next page.

What the guide actually sees

Not HTML. Not a screenshot. A short list of what can be clicked.

Sending a list instead of pixels makes each step cheaper and more exact: the answer is an element, not a guess at coordinates. It also keeps the request small enough to read, which is useful when your security team asks what leaves the browser.

what the guide receives (simplified)
goal: "add my daughter to my health plan"
page: /benefits  "Benefits 2027"
e3  link    "Benefits"            nav
e9  button  "Start enrollment"    main
e10 button  "Add"                 main  (Dependents)
e11 button  "Review"              main  (Beneficiaries)
e14 field   "Search"              header
what it answers
{ "action": "point", "target": "e10",
  "say": "Dependents are added here. Click Add.",
  "emotion": "happy" }

How it learns your app

A single page tells the guide what is here. An app map tells it what is behind each click.

Observe mode

While people use your app, the widget reports the masked page structure and which control led where. No input values, no user ids, a random id per tab. Turn it on before launch with the guide hidden to learn quietly.

The explorer

Point it at a staging tenant with a test account. It loads every page it can reach and clicks each safe control from a fresh load. It never submits forms or clicks anything that looks like save, send, delete or pay.

Your notes, optional

A product description, a few facts (“customers must exist before invoices”) and short flows in plain steps. Helpful, never required.

A label enters the app map only after several separate sessions have seen it, so text that belongs to one user, such as a customer name on a button, never reaches the guide.

You stay in control of the page

  • data-guide-private on any element: its text becomes “(private)”.
  • data-guide-ignore: the guide doesn’t see it at all.
  • Each site key only works on the domains you list.
  • Pepper never clicks for the user. It points; they act.
  • The widget lives in a shadow root: your CSS can’t break it and its CSS can’t leak into your app.

Start a guide from your own UI

page API
<button onclick="Wayhint.ask('download my tax statement')">
  Show me where
</button>

Also Wayhint.stop() and Wayhint.open(). Install guides →

Let Pepper take it from here.

Paste one script tag. Free up to 500 monthly active users. No card, no flows to build.