A working document for Product and Engineering teams of BUs and Platform. Advisory by nature—recommendations grounded in user research, not code-enforced rules.
What AINH is, why it exists, and how to read the rest of this document.
Today, help is something products make. Every BU writes its own onboarding, its own Guided Tours, its own in-product tips — shipped in a release, maintained until it goes stale. When the product changes faster than the help can be rewritten, customers fill the gap themselves.
AINH closes that loop. Help is no longer content shipped with a feature — it's a system response generated at runtime from sources, contexts, and triggers. BUs define what their content is and where it applies; the framework decides when, what, and how to surface.
If a rule conflicts with one of these, the principles win.
A working taxonomy of why a nudge fires. The visual pattern can be the same across all five — what differs is intent and trigger.
These are the patterns observed in research that the framework is designed to prevent. Each problem is grounded in a concrete user scenario, mapped to the rules that address it, and anchored in a design principle.
A new user opens AINPX with a dozen nudges queued — from the platform, from CSM, from ITSM, from Workspace. Without prioritization and pacing across BUs, these stack on the same surface. The user can't tell which matters, dismisses the pile, and the framework loses credibility before it earned any.
A user drafting an incident response under SLA pressure gets a nudge mid-task — the interruption kills the suggestion, no matter how useful it would have been. A well-intentioned mastery nudge fires offering to show them how to save the response as a template. The suggestion is technically useful, but it lands mid-thought. The user dismisses it as friction. Repeat many times across a day and the user starts dismissing everything reflexively, including the nudge that would have mattered.
A BU ships a nudge for a new feature with copy that reads like a press release — "Powerful new automation. Streamline your workflow today." The user wants to know what the feature does and how to use it; the marketing framing reads as noise. They dismiss without reading. The team interprets the dismissal as a signal to write the next nudge more aggressively, and the cycle deepens.
A user opens the platform to triage urgent escalations and gets a nudge about something unrelated — the mismatch turns even useful content into noise. A nudge fires recommending they try a new report template. The content is fine; the moment is wrong. The user is task-loaded with a specific intent — anything that doesn't serve that intent reads as system noise, regardless of how valuable the suggestion would be on a different day.
A user encounters a nudge about a feature they don't have time to explore right now. They click the X to dismiss it and move on. Two weeks later they realize that feature is exactly what they need — but it's gone, and they don't know how to get it back. The action vocabulary collapsed "no, never" and "not in this moment" into the same outcome.
A user who has been creating incidents confidently for six months gets a nudge offering to walk them through it. The system ignoring accumulated competence reads as not paying attention. The system surfaces a nudge offering to walk them through how to create an incident. The user reads it as the platform not paying attention. Trust in the system's ability to read context erodes — and with it, attention to future nudges, including the ones that would have been useful.
A newly-onboarded user is doing their work the long way because they don't know the platform has a shortcut for it. They can't ask for help with capabilities they haven't discovered. But proactive surfacing of every capability would recreate Problem 01 — so the framework has to introduce the right capabilities at the right moments, not all of them at once.
The synthesis from research that shaped these guidelines. Each insight points to which rule or principle it informed, so the reasoning is traceable back to source.
The 10 insights cluster around 4 patterns. Each detailed insight below maps to 1.
Trust erodes from accumulated volume and from opaque sources. Both have to be managed — restraint at the per-day level, transparency at the per-nudge level.
Users miss capabilities they can't see — and, in the framework's data-dense interface, our preference for peripheral placement isn't always enough.
Mastery, mode, and intent change over time. Guidance, format, and suppression controls all need to respond to that — not a one-time setup, but continuously.
When products don't generate help, the authoring cost moves to customers — colleagues writing step-by-step guides for each other. Runtime generation removes that cost.
Volume of nudges across a day matters more than the quality of any single one — Users tolerate one well-timed nudge but dismiss patterns of nudges en masse.
Across sessions, the problem isn't whether a single interruption was good or bad — it's the volume across a whole day. Users tolerate one well-timed nudge; they dismissed patterns of nudges en masse. This is why per-user volume matters more than per-nudge quality.
As AI takes more autonomous action, users become less aware of what the system can do — making capability surfacing both more valuable and more easily ignored.
Capability awareness and feature blindness are the two most consistent friction points in AI-native onboarding.
AI guidance reduces cognitive load, but also reduces feature discovery outside the guided path — a structural tension, not a bug.
Once AI starts guiding users through workflows, users explore less. The same mechanism that reduces cognitive load also reduces discovery of features outside the guided path. This is a structural tension, not a bug — nudges shouldn't be the only way users learn the system.
Without visible sources, customers default to dismissing or disabling AI-generated help entirely.
When shown AI-generated definitions and explanations in AINH help patterns, customers asked where the source data came from. Without visibility, users defaulted to dismissing or disabling the AI-generated help entirely. "If there's a doubt, they're more likely to turn it off." Relevancy and HITL control are the other two foundations of trust.
Dismissal is a strong signal, but not a permanent one — if a previously dismissed nudge becomes relevant again, the system should listen to the new signal.
Users dismiss for many reasons: bad timing, irrelevant content, or just wanting to focus. But ignoring dismissals to keep retrying degrades trust faster than any single irrelevant nudge would. Treating every dismissal as "permanent off" overcorrects. The recovery-path pattern matters: if a previously dismissed nudge becomes relevant again because the user is struggling, the system should listen again.
Jumping directly to AI-native experiences risks user disorientation — onboarding from traditional → assistive → predictive → AI-native is essential. Nudges that introduce AI capabilities at first-touch, before users have established baseline readiness, perform worse than those that fire at moments of demonstrated readiness.
In data-dense workspaces, peripheral nudges can be missed entirely — partners endorsed overlay-style treatment for onboarding, in tension with the framework's preference for subtle placement.
A senior service manager on the partner side endorsed the framework's overall direction, but identified a hard limit: in ServiceNow's data-dense workspaces, peripheral nudges can be missed entirely. He described it as "fighting against a lot of data on a single page — that's your enemy". His recommendation was an overlay-style treatment that grays out the surrounding screen and spotlights the nudge, particularly during onboarding and in-flow contextual help — especially for first-time users — and that the framework's content should sound collaborative and inviting ("see an example") rather than condescending ("let me show you how").
This sits in tension with the framework's instinct towards subtle, non-blocking placement. It shares ground with Insight 02 (capability awareness is the hardest problem in AI-native UX) and Insight 06 (transition matters as much as destination) — all three insights push the edge between a nudge firing and the user actually noticing. The content tone consideration reinforces Insight 04 (trust) — it's also about relevant stance.
When products lack contextual help, the authoring burden moves to customers — colleagues create step-by-step guides for each other, often with screenshots. Runtime generation removes that cost.
P5 described real, ongoing effort spent helping a colleague navigate a feature: "I have to make a lot of screenshots of where he can find it so that he can see what the information is. It was a lot of steps." This is a familiar pattern across enterprise teams — product-side help is missing, so colleagues fill the gap for each other. P5 explicitly said that runtime-generated help would change this: "For me, it will be very helpful and I know it will optimize a lot of process here."
This is direct customer validation of the AINH generation paradigm. It strengthens the case that retiring the BU-authored submission model (Rules 2.2 and 2.3) wasn't only an internal architectural choice — it reflects a real cost that customers are absorbing today.
Help format must shift with user mode — tours are welcome during learning, unusable during live execution under time pressure.
P5 drew a sharp distinction between learning and working mode. Tourist and walk-throughs are useful during on- and off-boarding to understand the product better — but the moment they're on a live call with measured handle time, the tone breaks down: "If I'm in a call right now and I just forgot how to do something, the top time average will go high because I'm spending time looking for a water I forgot. I would prefer to have a feature that I can just go and search super quickly."
This is a different axis from Insight 03 (discovery vs exploration) and Insight 06 (dismissal signals): it's about format fitting with what user is doing right now, not about whether help fires or how. The framework already handles suppression-after-mastery (rule 1.5); what's missing is the surface that takes over once tours have outlived their use — search, direct answers, or Otto on demand.
The 11 active rules referenced from the User problems tab. If you're scanning, read the at-a-glance summary first — the full rules sit below.
Only one nudge surfaces at a time, and only nudges relevant to the user's active context are eligible to surface in the first place.
Addresses Too many nudges at once · Nudges that interrupt focused work · Nudges that don't match what the user came to do
Why it matters. Volume is the enemy. Without scoping and pacing, users see a stack on every surface and dismiss the whole pile — taking trust in the framework with them.
When a user has demonstrated they can do a task, stop offering help on it — unless they later show they're stuck on the same thing again.
Addresses Nudges that don't recognize what the user already knows
Why it matters. Help that ignores prior competence reads as the platform not paying attention. The visible inattentiveness costs more than the help would have gained.
Every nudge offers three distinct response options, each with a different consequence — so users can say no without saying never.
Addresses Nudges that interrupt focused work · Nudges that users can't come back to
Why it matters. The current "X to close" pattern is why users hesitate to use it — they don't know if dismissing means "never again" or just "not in this moment". Splitting the actions removes the cost of saying no.
A nudge that's been dismissed or ignored stays hidden until the user's situation actually changes. They hit the same problem again, or the feature itself has meaningfully changed. Waiting 30 days and re-showing it is not a signal. It's a guess.
A focus state is any moment where the user is actively committed to a specific attention-demanding surface — a modal that needs action, a live voice or agent call, or a form or editor with unsaved input where they're actively typing. During these moments, the platform holds proactive nudges. Guided tours, especially. If the user asks for help directly (types a question, clicks a help icon), that's different — they are pulling, not being pushed.
Addresses Nudges that interrupt focused work
Why it matters. Focus states are commitments. The user chose what they are doing. Interrupting them — especially with a tour — is the textbook definition of intrusive. Insight 09 is direct on this: working users can't follow tours, and a nudge mid-task kills the suggestion, no matter how useful it might have been.
The recommendations below have not yet been through review with design leadership. They are included here to show the full shape of the framework; treat them as drafts open to challenge.
Every nudge has to earn its place on the screen. Before one surfaces, four things need to be true: the user's intent is clear, the guidance is actually needed, the content saves them real time, effort, or errors, and the outcome can be measured. If it can't pass all four, it doesn't ship.
Addresses Nudges that don't match what the user came to do
Why it matters. Users learn what the platform's judgment is worth from every nudge they see. One low-value nudge makes the next useful one lose credibility. Value density is what protects the whole system.
When a nudge walks the user through multiple steps, the platform requires a preview of the end result — a thumbnail, GIF, or finished view — to appear before the steps. If there is no preview, the nudge doesn't surface.
Addresses New users don't know what they don't know
Why it matters. Users decide whether to invest attention in a multi-step task based on whether the destination looks worth it. Showing the end first lets them make that call before they've spent effort.
The platform picks format from two signals: what mode the user is in (orientation vs. working) and how complex the task is (a quick answer vs. a walk-through). A user under SLA pressure needs a fast answer. A first-time user, learning a five step flow, needs a tour. A first-time user learning a one-click action just needs an in-line hint, not a tour.
Addresses Nudges that interrupt focused work · Nudges that don't match what the user came to do
Why it matters. A first-time user learning a one-click action doesn't need a tour. A working user hitting a complex new flow can't take a tour, but still needs to understand it. If format is decided by mode alone or by feature type, one of these users gets served wrong.
When multiple nudges are eligible, group them by topic before picking one. Three nudges about "reporting" should collapse into one slot, not compete individually against a nudge about search. Users experience topic areas, not team boundaries.
Addresses Too many nudges at once
Why it matters. Without grouping, a topic with many candidates wins disproportionate attention. The platform ends up doing whatever is loudest, not what's most useful to the user.
When nudges from different categories compete for the same slot, they resolve in a fixed order: Friction beats Resolution beats Mastery beats Relocation beats Novelty. A user who's stuck always beats a user who's being introduced to something new.
Addresses Too many nudges at once
Why it matters. The order reflects user need. A user who's stuck needs help before a user who could learn something new. If teams could tune the order, the platform's judgment would be their judgment — and the user would get whichever team shouts loudest.
A nudge about a new feature can only surface when the user is already doing the kind of work that feature is for. Just shipping something doesn't earn the right to interrupt.
Addresses Nudges that don't match what the user came to do · New users don't know what they don't know
Why it matters. Novelty on release is the loudest failure mode of platform help — users get interrupted about something they weren't asking about, don't have context for, and can't act on. Earned context is what makes novelty land.
Why parked: Time is the wrong unit. The real concern is task state — whether the user is in a position to absorb another nudge. Without telemetry on task boundaries, app-switching, and engagement signals, a time-based rule risks both silencing needed help and over-firing on field workers using the platform in 5-minute bursts.
Action: Hold until telemetry exists; revisit as a behavior-based rule.
Why parked: Tenure is a proxy for mastery — but a weak one. An 18-month user who's never adopted a feature isn't a power user for it. The right signal is behavioral (feature adoption, task efficiency, help-seeking patterns), and that telemetry doesn't exist yet.
Action: Hold until behavior-based signals are available; mastery and resumption signals added to engineering open questions.
Why retired: If contextual gating works (1.1), a user who never visits a surface never sees nudges from that surface — so a release-level cap is solving a problem that doesn't exist. The mechanism it relied on (BUs coordinating at planning) is unrealistic. The concern is absorbed by the contextual gate.
Why retired: "Release cycles" is not a coherent unit (customers update on their own timelines), all nudges shouldn't decay the same way (1.7 handles category-specific decay), and the rule assumed BUs manually author and resubmit nudges — which may not be the right model in an AI-native framework. The cleanup concern is absorbed by 1.7.
Why retired: the cap's stated purpose was back-pressure on BU planning, but BUs don't monitor cross-BU queues, so the planning-discipline mechanism doesn't work. The user-facing concern (stacking) is already handled by selection logic — even if many nudges are pending, only one fires per moment. The user never experiences queue debt.
Why retired: this rule assumed BUs author and submit discrete nudges per release. In the AINH framework, BUs define content sources, contexts, and triggers — the framework constructs nudges dynamically. "Primary nudges per release" is a concept from the submission paradigm. The user-facing concern (volume control) is already handled by 1.1 (context scoping) and 3.2 (priority hierarchy).
Why retired: pre-launch review assumed BUs submit finished nudges that get gated before shipping. In the AINH-native framework, there is no "ship" event for individual nudges — the framework constructs them at runtime from sources. The integrity concern (category accuracy, trigger conditions, success metrics) moves into the design of the framework's qualification logic — now covered by 2.1.
Why retired: content-shape rules — tone, opening structure — belong in the AINH content design guidelines. Framework governs whether and when to surface; content design governs how the words read once surfaced. The framework-level concern (generic promotion firing when it shouldn't) is now covered by 2.1's promotion nuance.
Why retired: same reason as 2.4 — how an AI nudge opens (evidence vs. pitch) is a content design rule, not a framework guardrail. Moves to the AINH content design guidelines. The framework requirement adjacent to this — that task-based nudges include an end-state preview — is retained as 2.6.
Items the framework needs to resolve, hold positions on, or hand to other teams. Surfacing these here so they are not buried in conversation.
The current document assumes BUs author and submit nudges. The PM agreement suggests AINH generates nudges using BU-defined context and triggers. These are different framing decisions with downstream implications for review gates, content discipline, and decay rules. Needs explicit framing before further work.
A recurring theme: when BUs are given configurability, they optimize for their own surface at the user's expense. A working position has emerged — platform sets, BUs tighten — but it needs explicit endorsement and a concrete list of what BUs can adjust on their own surfaces.
Nudges and notifications can compete for the same surface and same moment. The framework currently has no contract with the Notification system for resolving priority. Working hypothesis: priority decides, not type — but this requires alignment between two systems that don't yet talk to each other.
Several recommendations are held as v1 placeholders because the behavioral signals they need don't exist yet: cross-session mastery, current-session struggle, task-interruption recovery, and the engagement pattern over time. Each of these unlocks a rewrite of recommendations 1.2, 1.3, and 1.5.
Research with newly-onboarded customers (P3) and the AI Onboarding Insights Rollup both endorse overlay/spotlight patterns for new users — but this sits in tension with the framework's preference for a peripheral, non-blocking placement. The framework needs an explicit position rather than an implicit one.
All three recommendations govern how the system responds to user signals over time (mastery, dismissal, engagement, decay). They were written separately and overlap heavily. A future structural review may collapse them into one rule with sub-clauses or restructure the relationship between them.
Problem 07 is only partially addressed by the current rules. Rules 2.6 and 3.3 shape how Novelty nudges land when they fire — but they constrain when Novelty fires more than they drive discovery. The framework as currently written protects against overload (Problem 01) better than it solves discovery. A discovery-side rule, or a different mechanism altogether, may be needed. Worth specific input from Jeffrey Chan's Q2 2026 research plan.