Start page

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?