Get started
R29Make a broad product easy to navigate
Pro

Give each role a way in

Put the roles near the top, give each one a tailored scenario, and keep a single shared explanation underneath.

Back to page recipes

Page flow

5 sections in the order the visitor meets them. Taller bars mark the sections that need more space.

  1. OrientShared promise
  2. NavigateRole tabs
  3. DemonstrateTailored scenario
  4. ProveShared platform section
  5. ConvertRole-specific action

How the page leads to action

  1. 1

    Open with a promise general enough to be true for every role, specific enough to matter.

  2. 2

    Put the role selector high, labelled with titles people use for themselves.

  3. 3

    Give each role one concrete scenario with its own artifact.

  4. 4

    Keep a shared platform section, so the product is one thing rather than several.

  5. 5

    Convert per role, into whatever that role would actually do next.

What each section needs to do

OrientShared promise
One promise true for every role listed, avoiding a lowest-common-denominator platitude.
NavigateRole tabs
Four to seven roles named as people name themselves, with the highest-volume role as the default.
DemonstrateTailored scenario
One scenario per role: their trigger, their artifact, their outcome. Not a reskinned generic story.
ProveShared platform section
What every role gets: the common data, admin and integration layer that makes it one product.
ConvertRole-specific action
The next step that role would really take — a template, a pilot, a security review, a demo.

Is this the right page flow?

Who it is for

Departmental buyers inside one organization who each need to see their own work reflected before they believe the product fits.

Products it suits

Horizontal products used differently by several functions, where one generic story satisfies nobody.

Not for

A specialist product with one buyer and one job, where role tabs manufacture ambiguity.

How the page proves its case

Which proof appears first, and what follows it.

  1. Primary: recognition — the visitor sees their own job described accurately.
  2. Secondary: the per-role artifact, which proves the scenario is real, not a persona exercise.
  3. Tertiary: the shared layer, which turns several role stories into one purchase.

Call to action plan

What the page asks for, what it offers instead, and where.

Primary
Start with your role's scenario
Secondary
See the shared platform, or switch role
Placement
An action inside each role panel, plus one platform-level action after the shared section.

Responsive behavior

What the sequence has to do when the viewport stops cooperating.

  • Role tabs become a scrollable chip row with the active role always visible and deep-linkable.
  • Scenario artifacts crop to their meaningful region rather than scaling to illegibility.
  • The shared platform section keeps its position after the tabs at every breakpoint.

Anti-patterns

The failure modes that make this sequence stop working.

  • Roles that share one generic scenario with the noun swapped.
  • Nine roles, which dilutes every one of them.
  • Role content that only exists behind interaction, leaving crawlers and skimmers with nothing.
  • No shared section, so the page reads as five products under one logo.

Build spec

Pro

What an agent needs in order to build Give each role a way in: what each section must contain, the copy rule that keeps it honest, the slots to resolve from your product, and the order to build in.

Checking access to the build spec

Agent tags

The vocabulary an agent matches this recipe on.

  • role-tabs
  • tailored-scenario
  • shared-platform
  • default-role
  • role-cta