UX Patterns Guide
UI + UX Task And Workflow Patterns established

Start page

Provide a focused start page that names the service in user language, explains what it does, who it is for, what users need, what will happen, how long it may take, how to start, how to resume, and what alternatives exist when the service is not right for them.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A user is about to start one named service, transaction, booking, application, check, request, or registration.
  • Most users need brief pre-start information to avoid the wrong service, missing materials, unexpected costs, or failed completion.
  • The entry page must connect a public content page, product area, help topic, or search result to the first service step.

Avoid when

  • Users are still choosing among many topics, products, services, or articles.
  • The goal is to teach a product or configure first-run setup.
  • The work is a long ordered journey across several guidance pages and services.
  • The first page of the service can safely ask the first question without separate pre-start context.
  • The page mainly promotes a product, campaign, announcement, or brand story.

Problem it prevents

Users need a trustworthy entry point for a specific service or task, but without pre-start context they may begin the wrong service, lack required documents, miss costs or eligibility, or fail to recover an existing draft.

Pattern anatomy

What a strong implementation has to make clear

User need

A service, application, booking, check, registration, or request begins after the user clicks a primary start action.

Pattern promise

Provide a focused start page that names the service in user language, explains what it does, who it is for, what users need, what will happen, how long it may take, how to start, how to resume, and what alternatives exist when the service is not right for them.

Required state

Default entry state with service name, purpose, user fit, pre-start requirements, expected outcome, and primary start action.

Recovery path

Users begin the wrong service because the start page name and summary do not match user language.

Access contract

Use a clear H1 that names the service or task and matches the page title.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A permit application start page states who can apply, the fee, the estimated time, required documents, what happens after submission, a Start now button, and a Resume application link.
  • A health-service start page explains the result users will receive, lists information needed before starting, shows a single Start now button, and provides phone access for users who cannot complete the service online.
  • A user checks that they live in the eligible region, sees they need a reference number and 10 minutes, starts the service, and returns later through Resume application without losing their draft.
  • A user arriving from search realizes the service is not for their situation and follows a clearly labeled alternative route before entering the transaction.
Weak implementation

Vague, hidden, hard to recover from

  • A page titled Start contains a hero carousel, five equal buttons, news cards, and no clear transaction entry point.
  • A start page puts required identity documents and fees below the button where most users do not see them before beginning.
  • A user clicks Start now, answers four pages, and only then learns they needed a document that was not mentioned on the start page.
  • A returning user who already started must begin again because the entry page has no sign-in, resume, or draft recovery path.
UI guidance
  • Render the service or task name, short purpose statement, who can use it, what users need, outcome expectation, time or cost where relevant, one primary start action, resume or sign-in route when relevant, and other access routes in a narrow readable page.
  • Keep the primary start action visually dominant and put essential pre-start information above it; place optional context, related guidance, and alternative channels below or beside the main path without making them peer calls to action.
UX guidance
  • Use a start page to help users decide whether they are in the right place and begin a specific service with the right materials, expectations, and recovery routes.
  • Keep the page focused on starting the service; move complex eligibility, branching, identity proof, payment, and multi-step progress into the appropriate downstream flow.
Implementation contract

What the implementation must handle

States

  • Default entry state with service name, purpose, user fit, pre-start requirements, expected outcome, and primary start action.
  • Returning-user state with sign-in, resume, or update route distinct from the new-start action.
  • Not-for-you state with concise exclusion or alternative route when a common wrong audience arrives.
  • Before-you-start state listing documents, account details, time, cost, consent, or device needs that most users must know.

Interaction

  • The primary start action moves users into the first service step and does not jump to unrelated marketing, category browsing, or account dashboards.
  • Resume or sign-in actions return users to their existing draft, application, account, or record without creating a duplicate transaction.
  • Eligibility and requirement text on the start page matches the downstream service validation and business rules.
  • Essential information needed before starting appears before the start action or is clearly reachable before commitment.

Accessibility

  • Use a clear H1 that names the service or task and matches the page title.
  • Keep the main start action keyboard reachable after essential information, with a label that describes the action.
  • Do not rely on iconography, color, card placement, or hero imagery to communicate eligibility, cost, or required documents.
  • Use normal lists for required documents and alternative access routes so screen reader users can scan them.

Review

  • Can a search-arriving user tell whether this is the right service before clicking the start action?
  • What must most users know before they begin, and is that information visible before commitment?
  • Is there exactly one primary start action, and does its label match the next service step?
  • What does a returning user do if they already started?
Interactive lab

Inspect the states before you copy the pattern

Start the right service with the right preparation

Check fit, reveal required documents, start the service, resume a draft, follow alternative access, pause the service, and compare buried requirements, equal actions, no resume, eligibility maze, and dead-end entry failures.

Start page
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Default entry state with service name, purpose, user fit, pre-start requirements, expected outcome, and primary start action.

Keyboard / Access

Skip links and landmarks let keyboard users reach the start page heading and the start action without traversing every global link.

Avoid Generating

Treating a product homepage, marketing landing page, or category directory as a start page for a specific service.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Start using a service pattern

GOV.UK Design System - checked

GOV.UK defines how public service start points should give enough context, start action text, resume routes, required information, and alternative access.

NHS Start page pattern

NHS digital service manual - checked

NHS defines start page structure and explains that important information needed to complete the service should appear before the button.

Full agent/debug reference

Problem Context

  • A service, application, booking, check, registration, or request begins after the user clicks a primary start action.
  • Users may arrive from search, navigation, email, or another guidance page and need confidence that this is the correct entry point.
  • Most users need to know eligibility, required information, documents, costs, time, outcome, or alternative channels before they start.
  • Some users may have already started and need to resume rather than create a duplicate transaction.
  • The service sits inside a wider information architecture, topic, product, or public website where users need a route back if this task is not for them.

Selection Rules

  • Choose a start page when one named service or transaction needs a focused entry point before the first question, form, booking, payment, or authenticated step.
  • Use one primary start action with action-specific text such as Start now, Apply now, Book now, Sign in, or Register or update details.
  • Provide resume, sign-in, or update routes when returning users can continue an existing application or manage an existing record.
  • List only information most users need before starting, such as documents, cost, time, account requirements, region, outcome, or service availability.
  • Move complex eligibility checks into the service flow; keep only short eligibility cues or alternative routes on the start page.
  • Use browse by category when users still need to choose among many services or topics.
  • Use onboarding when users need first-use product activation or teaching rather than a transaction entry point.
  • Use step navigation when the user must complete several guidance or transaction tasks in a known order across a wider journey.
  • Use service navigation, breadcrumbs, related links, or search to situate the start page, but keep those recovery routes secondary to the start action.

Required States

  • Default entry state with service name, purpose, user fit, pre-start requirements, expected outcome, and primary start action.
  • Returning-user state with sign-in, resume, or update route distinct from the new-start action.
  • Not-for-you state with concise exclusion or alternative route when a common wrong audience arrives.
  • Before-you-start state listing documents, account details, time, cost, consent, or device needs that most users must know.
  • Alternative access state for phone, paper, assisted digital, offline, or delegated access when available.
  • Unavailable or paused state explaining when the service cannot be started and where to go instead.
  • Mobile state where the service name, essential requirements, and start action remain visible without burying the needed information.

Interaction Contract

  • The primary start action moves users into the first service step and does not jump to unrelated marketing, category browsing, or account dashboards.
  • Resume or sign-in actions return users to their existing draft, application, account, or record without creating a duplicate transaction.
  • Eligibility and requirement text on the start page matches the downstream service validation and business rules.
  • Essential information needed before starting appears before the start action or is clearly reachable before commitment.
  • Alternative routes explain who should use them and preserve the user's task context where possible.
  • Deep-linked users can identify the service, surrounding topic, and route back through breadcrumbs, service navigation, or related links.
  • Starting the service sets focus on the first question, form heading, or authenticated step with the service context intact.

Implementation Checklist

  • Define the service name, first service step, primary start action text, returning-user route, and destination before writing the page.
  • Inventory the information most users need before starting: documents, identifiers, time, cost, eligibility, account, device, region, outcome, and alternatives.
  • Decide which information belongs above the start action, below it, in a separate before-you-start page, or inside the transaction.
  • Keep surrounding navigation, breadcrumbs, search, and related links available without competing with the primary start action.
  • Verify the start page language matches search terms, support questions, and the downstream service name.
  • Test new, returning, ineligible, assisted, mobile, keyboard, screen reader, deep-linked, translated-label, and service-unavailable states.
  • Instrument start, resume, wrong-service exit, downstream abandonment, and missing-document errors to see whether the start page is setting expectations correctly.

Common Generated-UI Mistakes

  • Treating a product homepage, marketing landing page, or category directory as a start page for a specific service.
  • Showing several equal calls to action when one service start action should be primary.
  • Hiding documents, costs, account requirements, or outcome expectations after the start action.
  • Using the start page for long eligibility questionnaires that belong inside the service.
  • Making returning users restart because resume or sign-in is absent or visually hidden.
  • Disconnecting the page from the wider information architecture so wrong arrivals hit a dead end.
  • Changing the start button label to a vague phrase that does not match the action users are about to take.

Critique Questions

  • Can a search-arriving user tell whether this is the right service before clicking the start action?
  • What must most users know before they begin, and is that information visible before commitment?
  • Is there exactly one primary start action, and does its label match the next service step?
  • What does a returning user do if they already started?
  • Which common wrong users need an alternative route before they enter the service?
  • Would browse by category, onboarding, step navigation, question page, or wizard be more accurate?
Accessibility
  • Use a clear H1 that names the service or task and matches the page title.
  • Keep the main start action keyboard reachable after essential information, with a label that describes the action.
  • Do not rely on iconography, color, card placement, or hero imagery to communicate eligibility, cost, or required documents.
  • Use normal lists for required documents and alternative access routes so screen reader users can scan them.
  • Keep breadcrumb and surrounding navigation landmarks separate from the main start action.
  • Ensure resume, sign-in, and alternative routes have distinct link text and do not repeat Start now.
  • On transition into the service, move focus to the first service heading or question and preserve the service name in context.
Keyboard Behavior
  • Skip links and landmarks let keyboard users reach the start page heading and the start action without traversing every global link.
  • Tab order follows the page reading order: service context, essential pre-start information, primary start action, secondary resume or alternative routes, and related links.
  • The primary start action activates with Enter or Space when rendered as a button, or Enter when rendered as a link styled as a button.
  • Resume and sign-in links remain separate focus stops with text that identifies the returning-user destination.
  • If an unavailable or paused state replaces the start action, focus reaches the explanation and alternative next route.
  • After activation, focus lands on the first question, form heading, authentication heading, or error summary in the destination flow.
Variants
  • Simple service start page
  • Start point within a guide
  • Application start page
  • Booking start page
  • Check service start page
  • Authenticated start page
  • Returning-user resume start
  • Assisted-digital start page
  • Before-you-start entry

Verification

Last verified: