Point-and-click targeting
Anchor any step to any element just by clicking it. Wakeline locks onto the right spot and keeps it there — even as your app changes and ships new releases.
Click to anchor
No code and no developer hand-off — just click the button, menu, or field you want to point at.
Stays put
Wakeline keeps your steps anchored to the right element as your app evolves.
Placement & behavior
Choose where each tooltip sits, and advance the step when users click the element.
Live in three steps.
Pick an element
Click anything on your page.
Anchor your step
Wakeline attaches the tooltip or hotspot to it.
Set the behavior
Choose placement and what advances the step.
Anchoring a tooltip to a button buried in a menu.
The hardest anchors are the ones inside dropdowns and flyouts — the element does not exist until the menu opens. Here is how the picker handles a "Export" action hidden in a "···" menu.
Enter pick mode
In the step's Target tab, hit Pick. Wakeline highlights every element under your cursor on the live page with its matching selector.
Open the menu, pick the item
Click the "···" menu open, then click Export. The picker records a stable selector for the menu item — not just its screen position.
Tell the step about the menu
Turn on "Open this element first" and pick the menu trigger. When the tour reaches this step, Wakeline opens the menu before pointing at Export.
Choose the fallback
Set "if element does not appear" to skip — so users whose plan hides the Export item flow straight past instead of staring at a stuck tour.
What to expect: A step that finds its target reliably, opens the UI it needs on its own, and degrades gracefully when the element is not there. That last part is what separates tours that survive releases from tours that break.
When not to use point-and-click targeting.
No pattern fits every job. Here’s where we’d point you at something else — sometimes ours, sometimes not.
The element has no stable identity
If a button's classes are auto-generated on every deploy and it has no test id or aria-label, selectors will churn. Ask engineering for one data attribute — a single data-testid outlives any picker cleverness.
You are pointing at everything
If a tour needs eight anchored steps to explain one screen, the screen is the problem. Two or three anchors per tour is the sweet spot; past that, completion falls off a cliff.
Content that is not element-specific
Announcements, welcomes, and policy notes do not belong pinned to a button. Use a modal, slideout, or banner — anchoring is for "this thing, right here" moments.
What happens when my app changes and the selector breaks?
The step's "if element does not appear" behavior takes over: skip moves users past it, wait holds until the element renders. Your funnel will show the skipped step, so you will notice and re-pick in a minute rather than shipping a broken tour.
Can I paste my own CSS selector instead of picking?
Yes — the Target tab accepts a raw selector. Teams with stable data-testid attributes often paste those directly, which is the most durable anchor there is.
Does it work with dynamic, client-rendered UI?
Yes. Anchored steps wait for their element to appear in the DOM (or skip, your call), so single-page apps and lazy-loaded views work — the tour meets the interface when it is ready.
Can a step advance when the user clicks the real element?
Yes — "go to next step on click of" advances the tour on a real click of your actual UI instead of a Next button. It is the difference between telling users about a button and having them use it.
See it on your own app.
Ship your first guide in minutes. Free to start — no credit card.