Practical reference library
Implementation contracts for onboarding, contextual support and in-app engagement.
Guide 01
Define checklist completion from the underlying product action, not merely a click on the checklist item. Record the user or account, task identity, completion event and checklist version. The interface should reflect the stored state and recover correctly after refresh, sign-out or a change of device.
Read the guide →Guide 02
Test a product tour without a mouse from entry to dismissal. Verify that the trigger is reachable, the current step is understandable, controls work from the keyboard and focus returns to a sensible place when the tour ends. Choose modal or non-modal behavior deliberately; not every tour should trap focus.
Read the guide →Guide 03
Trigger in-app support from a specific unresolved problem, with an eligibility rule, cooldown and clear next action. Use the current page and failure context to offer relevant help. Avoid showing the same prompt repeatedly after dismissal or claiming a problem is solved merely because the help widget was opened.
Read the guide →Guide 04
A daily streak needs an explicit qualifying action, day boundary, timezone policy and recovery rule. Count a qualifying action once for the relevant day, handle delayed events deliberately and explain resets to the user. Test travel, daylight-saving changes and repeated events before attaching rewards to the streak.
Read the guide →Guide 05
An onboarding experiment exposure log connects assignment, actual component display and the later value event. Store these as separate stages. A user assigned to a tour may never see it, and a user who sees it may not activate. Keeping the stages distinct makes implementation failures and outcome analysis easier to diagnose.
Read the guide →Guide 06
Score candidates 1-5 on seven weighted criteria: implementation effort in your actual codebase, targeting depth (segment, behavior, lifecycle stage), experience quality on your real UI (not the tool's gallery), analytics that answer 'did onboarding cause activation', performance cost on load, maintenance burden when your UI changes, and price at your MAU. Weight before trialing; score only from a build in your own product.
Read the guide →Guide 07
Run a two-week structured trial: week one integrates the tool on your three highest-support-volume screens and verifies rendering, search quality against your real docs, and performance cost; week two ships to a user cohort and measures assisted-resolution rate against a control cohort. Pass gates are written before the trial starts. A trial without a control cohort measures usage, not support impact.
Read the guide →Guide 08
Evaluate popup software on the four capabilities that separate respectful from reviled: targeting precision (behavior and lifecycle, not just page URL), dismissal memory (dismissed means dismissed, across devices and sessions), frequency capping across all popup types globally, and measurement that includes the cost side — rage-closes, immediate bounces, task abandonment — not just conversions. A tool that only reports conversion rate is measuring half the transaction.
Read the guide →Guide 09
Before procuring a mobile onboarding SDK, verify six things: binary size added per platform (measured, not quoted), cold-start impact, crash isolation (the SDK failing must not take the app down), offline behavior, how content updates ship (over-the-air versus app release), and the SDK's own update cadence and breaking-change history from its changelog. Mobile mistakes ship in binaries and un-ship in weeks — the checklist front-loads what the web version of this decision lets you fix in an afternoon.
Read the guide →Guide 10
Test a tour tool's performance cost in four measurements: bundle and script weight added to first load, main-thread blocking during tour initialization, CLS when steps mount and highlight targets, and interaction latency while a tour is active. Set budgets before testing (e.g., no measurable CLS, blocking under a defined ms), measure on real mid-range devices, and re-measure with your actual tour content — an empty demo tour is not a measurement.
Read the guide →Guide 11
Branch onboarding on role only where the first-value action actually differs. Spec it in four parts: the fork point (one early question or an inferred signal — never both), per-branch first-value definitions, the shared trunk every branch returns to, and a branch budget (two to four; each branch is a product you now maintain). If two roles share a first-value action, they share a branch.
Read the guide →Guide 12
Design the invited-user path as its own flow, not a shortcut through the signup flow: land them inside the inviting workspace with context (who invited you, to what, why), skip every setup step the workspace already did, take them to a live artifact (the document, board or report they were invited to) within one screen, and defer account-completion chores until after first value. The inviter chose your product; the invitee is deciding whether to care — treat those as different problems.
Read the guide →Guide 13
Write an explicit resume policy with three time bands: under 48 hours, resume exactly where they left (same step, same data, one-line 'picking up where you left off'); 2-14 days, show a compressed recap then the next step (they've forgotten context, not intent); past 14 days, treat as effectively new — fresh entry point, prior data preserved but not presumed, and any dated checklist quietly reset. Onboarding state must persist server-side per account, never in local storage where a device switch resets everyone to zero.
Read the guide →Guide 14
Every empty state in a new workspace must answer three questions in one glance: what belongs here, why it's worth creating, and the one action that creates it. The checklist: a primary CTA that starts the artifact (not a docs link), an import path beside it for users with existing data, sample content that's clearly labeled and one-click removable, and empty states for second-order surfaces (search, filters, reports) that inherit the same rules. 'No items yet' with a lonely plus button is a shrug, not a design.
Read the guide →Guide 15
Admit a question into onboarding only if it passes three tests, in writing: it changes the user's next experience (branches the flow, configures the workspace, personalizes genuinely), it can't be inferred from data you already have (email domain, invite context, SDK usage), and it's asked at the moment its answer is used — not stockpiled at signup. Everything else moves to later prompts, enrichment, or the bin. The worksheet scores each candidate question against all three; most teams' signup forms fail their own audit by half.
Read the guide →Guide 16
A failed-action recovery prompt needs four specified parts: a precise trigger (the specific error event plus context — which action, which object, first failure or repeat), copy that names what happened and the exact next step (never 'something went wrong'), one primary recovery action in the prompt itself (retry with the fix applied, not a link to docs), and a frequency guard (the same prompt at most once per session; repeat failures escalate to human help instead of repeating the tip). Specify these per failure mode in a table — the five failures that generate most support tickets first — and wire the prompt to the error event, not to the page.
Read the guide →Guide 17
Set a hard budget — at most two unrequested interruptions per user per session, at most four per week — and make every prompt spend from it through priority classes: P0 failures/security (always shown, don't count against budget), P1 activation steps for the user's current stage (count), P2 feature announcements and surveys (count double, because they serve you, not the user), P3 everything else (queued to the help hub, never interrupt). One owner arbitrates the budget across product, marketing and support — because the user experiences all teams' prompts as one product, even though no one team ships more than 'a couple'.
Read the guide →Guide 18
Fill five fields before any in-app NPS ships: eligibility floor (user has completed activation AND 14+ days tenure — surveying users who haven't experienced the product measures onboarding, not loyalty), moment rule (show at a natural pause — after task completion, never mid-flow or on login), response cooldown (90 days after answering), dismissal cooldown (30-45 days after dismissing, and the dismissal persists across sessions and devices), and exclusion list (users in open support escalations, users who hit an error this session, brand-new payers in their first week). Sample continuously in small random slices within eligibility rather than blasting quarterly — the trend line smooths and no single week's mood dominates.
Read the guide →Guide 19
Test seven cases against any survey tool (or your own layer) before trusting it in production: dismiss then reload (prompt stays gone), dismiss then new session next day (still gone — the cooldown is server-side, not a cookie), dismiss on desktop then log in on mobile (gone there too — persistence is per-user, not per-device), dismiss then re-qualify for the same survey's audience (cooldown wins over re-targeting), dismiss then a DIFFERENT survey targets the user (the global frequency budget arbitrates, not each survey independently), respond then re-qualify (response cooldown wins), and clear cookies then return (logged-in users stay suppressed — only anonymous users may legitimately re-see). A tool that fails case two or three treats dismissal as a UI event instead of a user decision, and it will spend your users' patience to fill your response quota.
Read the guide →Guide 20
Report four cohorts rather than one completion percentage: users who completed the tour, users who started and dropped, users who were eligible and never started, and users who were never shown it. Then compare activation rate across all four. Completion rate on its own is a vanity metric because completers are self-selected — they were more motivated before the tour began, so they would have activated at a higher rate regardless. The honest comparison is completers against eligible non-completers, and the only way to remove selection bias entirely is a holdout that is never shown the tour at all.
Read the guide →Guide 21
Specify four things: the start event (account creation, first login, or first session — they differ by days for self-serve and by weeks for sales-led), the value event (the single action that means the product worked for them, not a proxy like 'completed onboarding'), the exclusion rules (test accounts, users who never returned after signup, accounts created by your own team), and the statistic (median, not mean — a handful of accounts that activate after six months will drag a mean into meaninglessness). Then report the distribution alongside the headline, because a median of three days made up of half the users in one hour and half in a week is two different products.
Read the guide →Guide 22
Deduplicate exposure events on a key of user, component, and a defined window — then test six cases that produce duplicates: a component re-rendering on state change, a user navigating back to the same screen, a modal reopening after dismissal, the same component mounting twice in different layouts, a page refresh, and a session resuming on another device. Decide the window deliberately: per session for most in-app components, per day for recurring prompts, per lifetime for one-time announcements. Duplicate exposures are worse than merely noisy — they inflate reach and deflate conversion rate simultaneously, so a component looks both more seen and less effective than it is.
Read the guide →Guide 23
Score in-app assistance on five measures, none of which is raw usage: resolution rate (sessions where the user completed the task they were stuck on, not just opened help), escalation rate (assistance sessions that became support tickets — lower is better only if resolution is high), time-to-resolution compared with the support path, coverage (the share of top support topics with in-app assistance available at the point of need), and repeat rate for the same topic by the same user, which signals the answer did not land. Deflection counted as 'help opened and no ticket filed' is the metric to avoid: it counts silent abandonment as success, and abandonment is the most common outcome it hides.
Read the guide →Guide 24
Specify what the tour does in four situations, because all four will happen: the target does not exist yet (wait, with a bounded timeout, and say what happens when the timeout expires), the target never appears (skip the step or abandon the tour — decide which, per step), the target exists but is off-screen or covered (scroll into view, then re-measure before drawing), and the target moves after the step is drawn (re-anchor, or accept drift and say so). The default behaviour of most libraries is to fail silently or to anchor to the wrong element, and both look to the user like a broken product rather than a missing step.
Read the guide →Guide 25
Model every guided surface as four states rather than a loading boolean: loading (nothing to point at), empty (rendered, but no data — guidance may differ or should not run), ready (the real thing, guidance may run), and error (guidance must not run). Then write the contract: guidance only evaluates in ready, and a surface must expose which state it is in rather than leaving guidance to infer it from the DOM. A boolean isLoading collapses empty and ready into one state, which is why tours so often point at an empty table and explain a feature the user cannot see.
Read the guide →Guide 26
Assert six things in an automated test: the server HTML does not contain the overlay (guidance is a client concern and rendering it server-side leaks it to crawlers and to users with JavaScript disabled), no hydration mismatch warning appears in the console, the component mounts only after hydration completes, targeting decisions that depend on browser-only state do not run during server render, the overlay's portal container exists before the overlay mounts, and a full page reload mid-guidance behaves identically to a soft navigation. The common thread is that in-app guidance is client-only state layered over server-rendered markup, and the seam between those is where it fails.
Read the guide →Guide 27
On every teardown path — completed, dismissed, navigated away, component unmounted, error — release eight things: event listeners, resize and mutation observers, timers and intervals, the focus trap and the previously focused element, any scroll lock, the portal node, the body class or inline style you added, and the subscription to application state. Test teardown by repeating the guidance ten times in one session and asserting that listener and observer counts return to baseline. The failures here do not appear on first use; they appear after repetition, which is why they reach production.
Read the guide →Guide 28
Treat onboarding progress as local-first state that syncs, not as a server call per step. Write each completed step locally the moment it completes, queue the sync, and reconcile when connectivity returns. Then specify five interruption cases explicitly: no connectivity at start, connectivity lost mid-flow, the app backgrounded mid-step, the process killed by the OS, and the app updated mid-onboarding. For each, say what the user sees on return. The default behaviours — a spinner that never resolves, or silently restarting from step one — are both worse than an honest 'you completed 3 of 5, continue?'.
Read the guide →Guide 29
Decide what back means at every point in the flow and write it down before implementing: back on step one (leave onboarding, or exit the app), back on a middle step (previous step, with state preserved), back on the final step, back from a modal inside a step (close the modal only, never the step), back during an in-flight network call, back after a deep link jumped into the middle, back with predictive back gestures enabled, and back after process death restored the flow. Test each on both the gesture and the button, because devices differ. The case that costs most is back on step one exiting the app entirely — the user is gone, and on a first session they often do not come back.
Read the guide →Guide 30
Test onboarding at six text sizes rather than one: the smallest, the default, the largest standard size, and the three accessibility sizes. At each, check that no text truncates, no control falls off screen, no two elements overlap, every tap target stays at least 44 points, and — the one specific to onboarding — every coach mark still points at its target. Anchoring guidance to a view rather than to a coordinate is what makes the last one pass. A layout that only holds at the default size is not a layout; it is a screenshot.
Read the guide →Guide 31
Store completion server-side per user and per step identifier, with the device as metadata rather than as part of the key. Merge by union rather than by last-write-wins: if any device completed a step, the step is complete. Completion is monotonic — it does not un-complete because an older device syncs later — and union is the only merge rule that respects that. Then decide two things explicitly: whether a genuinely platform-specific step (enable push on iOS) counts as complete when done elsewhere, and what a user sees on a second device that is partway through, which should be a resume prompt rather than a silent skip or a silent restart.
Read the guide →Guide 32
Write eligibility as an ordered decision table rather than as independent rules per flow. Each row is a condition set, a flow, and a priority; the first matching row wins and evaluation stops. Then add the two things independent rules cannot give you — a guaranteed-exhaustive default row so every user gets something, and an overlap check proving no user can match two rows at the same priority. Independent per-flow rules feel simpler and produce the two failures that define this area: users matching nothing and seeing no onboarding at all, and users matching three flows and seeing whichever the code evaluated first.
Read the guide →Guide 33
Put a cap and a priority order in front of every prompt rather than letting each one decide for itself. Three parts: a per-user limit per session and per week, a priority order covering every prompt type, and a suppression rule that blocks prompts while the user is mid-task. Then define what a losing prompt does — defer to the next eligible moment, or drop. Without a central policy, each prompt is individually reasonable and collectively a product that interrupts constantly, and the team that ships the most prompts wins the user's attention regardless of what matters.
Read the guide →Guide 34
Validate eight things before publishing: the resolved audience count computed now, five real sample accounts from it, entitlement (can every recipient actually access what you are announcing), plan and region availability, whether the feature is fully rolled out to that audience or still behind a flag, exclusion of internal and test accounts, the display window with an end date, and what a recipient sees if they click through before the feature is live for them. The single most common failure is announcing to an audience that includes people on a plan without the feature, which converts an announcement into an upsell nobody consented to read.
Read the guide →Guide 35
Keep exclusion separate from targeting and evaluate it last, at display time. Targeting answers 'does this user look ready'; exclusion answers 'is it appropriate to ask right now'. The list is short and mostly obvious once written: an open support ticket, a recent failed payment, a feature already included in their plan, a recent declined upgrade prompt, an active outage affecting them, a user in the middle of a task, and anyone who has dismissed this prompt twice. Log which rule excluded each user, because an exclusion layer nobody can audit is indistinguishable from one that silently stopped running.
Read the guide →Guide 36
Write four rules before shipping a streak: the grace window (how late an action still counts for yesterday — typically a few hours past local midnight), the freeze allowance (how many missed days a user can absorb, how they are earned, and whether they apply automatically), the recovery path (what happens after a break — reset to zero, restore on return within N days, or keep a longest-streak record alongside the current one), and the timezone rule (streaks are evaluated in the user's local day, fixed at their profile timezone, not the server's). Streaks exist to reward returning, so a policy that punishes a single missed day in a way the user experiences as unfair converts your most engaged cohort into churn.
Read the guide →Guide 37
Test nine cases before any reward is payable: same user claiming twice, two sessions claiming simultaneously, a retry after a timeout mid-claim, a claim after the reward expires, a claim by an ineligible user, a self-referral through a second account, a refunded or reversed qualifying action, a claim during a rule change, and a replayed webhook or callback from the payout provider. Every one of them is normal traffic rather than an attack. The rule underneath all nine: a reward grant must be idempotent on a claim key, and eligibility must be evaluated inside the same transaction that records the grant — checking first and granting after is a race, and concurrency will find it.
Read the guide →Guide 38
Specify four things: the scoring window (all-time leaderboards stop being winnable within weeks — rolling 7 or 30 day windows keep them live), the cohort (global boards demotivate everyone outside the top ten; segment by tenure, team or league), the reset rule (when it resets, what carries over, and whether prior winners are archived), and the visibility rule (show every user their own position and the gap to the next place, rather than only the top ten). A leaderboard's job is to make the next action feel worth taking to a median user. Ranked by lifetime totals, it tells the 400th user that the game ended before they arrived.
Read the guide →Guide 39
Reconcile five numbers monthly: rewards promised (qualifying events that met the published criteria), rewards granted (records created in your system), rewards paid (money or credit actually delivered by the payout provider), claims blocked (with reasons), and the unresolved difference. Promised should equal granted plus blocked; granted should equal paid plus pending. Any other result is drift, and drift is what ends referral programs — not poor performance, but finance losing confidence that the number is knowable. Investigate the difference monthly while it is small enough to explain.
Read the guide →Guide 40
Check twelve things before releasing a component that runs inside a customer's application: bundle size against budget, main-thread time against budget, no new global namespace or prototype modification, CSS scoped so it cannot leak either direction, no console output in production builds, graceful behaviour when the host page blocks network requests, correct teardown on unmount, behaviour when the host uses a conflicting framework version, no unhandled promise rejections escaping to the host's error tracking, accessibility of any focusable element, the two most recent host framework versions supported, and a smoke test against a real customer-shaped build rather than only against your demo page. The last one is the check that catches what the others miss.
Read the guide →Guide 41
Detect it yourself rather than waiting for a report: a step whose target resolution rate drops sharply is the signal, and it is available before any customer notices. Then contain first — disable the affected step or tour, which must be possible remotely without a deploy — establish scope by counting affected sessions, and only then fix. The fix is usually not yours: the target disappeared because the customer's application changed, so the durable answer is a stable selector attribute in their markup rather than a more clever selector in your code. A tour that survives one refactor by guessing harder will break on the next one.
Read the guide →Guide 42
Commit to four numbers and publish them: gzipped bytes for the initial load, additional bytes loaded lazily, main-thread time attributable to your script, and the maximum shift in the host's Core Web Vitals caused by loading it. Measure the fourth with a controlled comparison — the same page with and without the script, repeated — rather than by reading a page score, because a page score attributes everything on the page to the page. Enforce the first three in the build so they fail rather than drift. Publishing the numbers is the part that matters: an SDK vendor who will not state a size budget is one whose size is not budgeted.
Read the guide →Guide 43
Split ownership by decision type rather than by component: content and targeting belong to growth, integration and performance belong to engineering, and three things need a named joint owner — the selectors that connect guidance to the application, the performance budget, and anything that can be changed in production without a deploy. Those three are where the failures cluster, because each sits between the two teams and is therefore owned by neither. Write the matrix down with names, not team labels, and review it when either team reorganises.
Read the guide →Guide 44
Specify seven states before the survey ships: a required answer left blank, a free-text answer over the limit, a submit in flight, a submit that failed, a retry that succeeded, a survey dismissed halfway, and a survey whose host element disappears. For each one, write the text the respondent sees, where it appears, where keyboard focus goes and how assistive technology hears about it. WCAG 2.2 sets the floor: 3.3.1 Error Identification (Level A) wants the item in error identified and described in text, 3.3.3 Error Suggestion (Level AA) wants a known correction offered, and 4.1.3 Status Messages (Level AA) covers messages announced without moving focus. Passing those checks for these states is a test result for one widget. It is not a conformance claim.
Read the guide →Guide 45
Every way out of a product tour is a focus decision: Escape, the close button, Skip, Done on the last step, a click outside, a route change and the target element disappearing. For each exit, name the element focus must land on, then check it with a keyboard and a screen reader. For modal steps, the WAI-ARIA Authoring Practices dialog pattern gives the default: return focus to the element that opened the dialog, and pick another element that fits the workflow if that element no longer exists. A tour that starts itself has no opener, so the plan must declare a fallback in advance. Focus ending up on the document body fails the plan.
Read the guide →Guide 46
Offer three distinct choices and store each as its own decision: 'Not now' snoozes one flow for a set period, 'Don't show this again' ends one flow for that user, and a global onboarding opt-out stops optional tours, checklists and tips that the product starts. Write down what the opt-out doesn't cover, such as security, billing and legal notices, and deliver those through a channel the opt-out doesn't govern, so the two rules can never contradict each other. Guidance the user explicitly asks for, like replaying a tour from Help, still runs. Store every decision per user on the server, show the current state in settings, and make turning guidance back on as easy as turning it off.
Read the guide →Guide 47
Give each gamification notification type its own preference and channel setting instead of one on/off switch: streak-at-risk reminders, badge and milestone celebrations, leaderboard rank changes and challenge invitations behave differently and bother different people. Default the competitive ones, like a rank drop, to off or in-app only; respect quiet hours in the user's own time zone; and let a celebration be acknowledged without an animation. Then test every type on every channel, because a setting that stops the push but still sends the email is exactly the failure this checklist exists to catch.
Read the guide →Guide 48
For every attribute your application sends to an in-app guidance or survey layer, record which targeting rule, personalization token or report uses it. If nothing uses it, stop sending it. If a rule only needs a derived value (plan tier rather than billing details, 'signed up more than 14 days ago' rather than a signup timestamp), send the derived value. Then set retention for prompt responses and free-text answers. GDPR Article 5(1)(c) describes personal data as 'adequate, relevant and limited to what is necessary' for the purposes of processing. This worksheet documents your reasoning against that principle; it isn't a legal assessment, so check with counsel.
Read the guide →Guide 49
Collect the evidence while the onboarding change is live, not when someone asks for a story three months later. The packet needs the before and after flow (captures with version IDs and dates), an exposure log showing who saw which version, an outcome metric declared before launch, the comparison design, the result with its uncertainty, a list of everything else that shipped in the same period, and written customer approval for every number and quote you plan to publish. If the comparison was before-and-after rather than against a holdout, the case study has to say so and avoid causal words like 'drove' or 'caused'.
Read the guide →Guide 50
Define deflection as the reduction in support contacts per active user caused by in-app help, measured against a randomized holdout that doesn't get the help, over a window declared in advance. Don't count 'viewed an article and didn't open a ticket' as a deflected ticket: many of those people would never have contacted support, and some contacted support through another channel. Count contacts across every channel you can attribute, check that problems were actually resolved rather than postponed, and report the difference with an interval. Without a holdout, report a before-and-after association and label it as one.
Read the guide →Guide 51
Judge a gamification feature on a value outcome you'd care about without it, such as projects shipped, lessons finished or invoices sent, measured against a holdout. Treat daily logins, streak length and badges earned as mechanism metrics that show the feature is running, not results. Then check four things: did the value outcome move against the holdout, are streak-keeping sessions shallow (open, tick, leave), does the effect survive past the first weeks, and did the feature push some users away through notification opt-outs or churn. A feature that raises logins and leaves the value outcome flat improves the dashboard, not the product.
Read the guide →Guide 52
Log every task on the path from 'we want a tour' to 'the tour survived the next release', with start and end times, who did it and whether it was rework. Split one-time setup (SDK install, identity, stable attributes on targets) from per-flow work (build, targeting, QA, publish) and from maintenance (repairs after interface changes), because a no-code builder mostly shortens the middle part. Record engineering time even when it's small and scattered, since that's the part no-code claims tend to leave out. Time at least three flows, because the first includes learning, and report medians with the range.
Read the guide →Guide 53
Walk the flow as a new user on a fresh account, record every screen, then score eight criteria from 0 to 2 with one line of evidence each: time to the first value event, steps before value, whether questions asked change anything, clarity of the next action, skip and resume, keyboard and screen reader basics, handling of errors and empty states, and whether guidance points at real product actions or at the interface itself. A score without evidence doesn't count. For a competitor's flow, score only what you observed, record the date, and don't guess at their metrics.
Read the guide →Guide 54
Spend week one on plumbing and internal users: SDK installed behind a flag, identity and one value event verified, stable attributes on every target. In week two, show one flow to a slice of new signups with a holdout kept aside. In week three, widen that flow and add a checklist only if week two's gate passed. In week four, review the result against the metric you declared on day one. Every week ends with a gate that can stop the plan, such as broken targets, a performance regression, a focus or keyboard failure, or a missing exposure log. One flow measured properly in a month is worth more than five flows nobody can evaluate.
Read the guide →Guide 55
Before anyone builds an in-app announcement or tour for a new feature, the shipping team hands over, in writing: the feature flag and who has it on, stable selectors for every element the campaign will point at, the eligible audience and who must be excluded, the adoption event and its definition, copy constraints (names, limits, what not to promise), a support briefing, what happens to the campaign if the flag is rolled back, the campaign's end date, and a named owner on each side. Test the handoff with the matrix below before launch. Every failing row is a campaign that will point at something users can't see or promise something the feature doesn't do.
Read the guide →Guide 56
List every library that renders in-app guidance (tours, tooltips, positioning, toasts, surveys, celebration effects), then record for each where it's used, its licence as published on the npm registry, its size and its focus behavior. Pick one per job and retire the rest, starting with the least used. Check licences first. As of September 2026 the npm registry lists Shepherd.js and Intro.js as AGPL-3.0, and both offer commercial licences according to their npm readmes; Driver.js, React Joyride, Reactour and Floating UI are listed as MIT. Consolidating onto an AGPL library in a closed-source product without checking the terms swaps a maintenance problem for a legal one, so check with counsel.
Read the guide →Guide 57
Review every onboarding experiment that reached its planned end date this month in the same order. First confirm the observed split matches the planned split; a mismatch blocks the readout until it's explained. Then confirm exposure was logged when users could actually see the variant. Read only the metric declared before launch, with its interval, check the guardrails, and look at the effect by signup week. Finally record one decision: ship, stop, or extend under a rule written before launch. Experiments still running get a health check, not a decision. Keep the log, null results included.
Read the guide →Guide 58
Start from one activation goal defined as an event, write down what this quarter's experiments and reviews actually showed, and fill the quarter with at most three bets. Each bet names the evidence behind it, the metric it should move, the engineering dependency it needs and the date it will be judged. Reserve capacity for maintenance (broken targets, library updates, accessibility fixes) before adding new flows, and write a stop list of guidance you'll retire. A roadmap that only adds prompts makes the product noisier every quarter.
Read the guide →
