Features, User Stories, and Journeys are the supply-side expression of the product. A Feature is a named capability the product offers — the primary unit of planning and prioritization. A User Story is a persona-specific narrative showing one way a feature delivers value. A User Journey is a longer arc that spans multiple features and steps the product does not directly control. Each describes the product from a progressively wider lens: capability, interaction, end-to-end experience.

Feature

A Feature is a named capability the product offers to its users. A feature is scoped, prioritized, and delivered. It is not a system requirement — it describes what the user gets, not what the system shall do. The precise, testable version of the feature lives downstream in system requirements.

A feature carries seven attributes:

  • summary — a one-sentence description of what the feature does for the user.
  • persona — the primary persona served by the feature.
  • value proposition — why this feature matters, expressed in terms of the persona’s goals or frustrations.
  • priority — MoSCoW classification (must, should, could, wont). The same scale as system requirements, which keeps prioritization consistent across layers.
  • status — proposed (under discussion), accepted (committed), in-progress (being built), delivered (shipped), deferred (postponed with rationale), or rejected (explicitly declined with rationale).
  • non-goals — what this feature deliberately does not do. Tactical exclusions within the feature’s scope. Narrower than product-level non-goals.
  • design references — pointers to visual artifacts: wireframes, mockups, prototypes, Figma links. The PRD does not contain the designs — it references where they live.

A feature belongs to a product, addresses jobs, advances goals, may be tested by a hypothesis, may be planned in a release, and is sourced by zero or more system requirements through the traceability bridge described in Releases & Traceability.

Example:

feature "Ride request and fare estimate" {
  summary "Rider enters destination and sees an upfront fare estimate before committing"
  persona "Daily commuter rider"
  value-proposition "Eliminates fare anxiety — rider knows the cost before the trip"
  priority must
  status accepted
  addresses "Get to destination quickly when running late",
            "Know total cost before committing to a ride"
  advances "Reduce rider wait time"
  tested-by "Upfront fare reduces abandonment"
  design-references {
    "Fare estimate screen — rider app" -> "figma.com/file/abc123/ride-request-flow"
    "Fare breakdown modal"             -> "figma.com/file/abc123/fare-breakdown"
  }
  non-goals {
    "Let riders negotiate the fare — pricing is algorithmic only"
    "Show competitor prices — we show our price, not a comparison"
  }
}

Every field carries load. addresses links the feature to the jobs it helps get done. advances ties it to a business goal. tested-by names the hypothesis that justifies the bet. design-references tells engineers where to find the visual spec. non-goals prevents scope creep by stating, inside the feature, exactly what it will not do.

User Story

A User Story is a persona-specific narrative describing one way a feature delivers value. A feature is a capability; a story is one way of using that capability, told from one persona’s perspective.

A user story follows the canonical form:

As a <persona>, I want <action>, so that <outcome>.

It carries:

  • persona — the persona whose perspective this story represents.
  • action — what the persona wants to do, stated in the persona’s own vocabulary.
  • outcome — the benefit the persona expects, stated as a result, not a system behavior.
  • acceptance criteria — a set of conditions that must be true for the story to be considered complete. Each criterion is testable — these are the primary candidates for formalization into EARS requirements. The source field on a system requirement commonly references the exact acceptance criterion it formalizes.

The acceptance criteria bridge is what makes user stories operationally useful. A story without acceptance criteria is a wish. A story with clear criteria becomes the direct input for one or more EARS requirements.

Example:

stories {
  "As a daily commuter rider, I want to see the fare before I confirm,
   so that I can decide if the ride is worth the cost." {
    acceptance-criteria {
      "Fare estimate is displayed within 3 seconds of entering destination"
      "Fare breakdown shows base fare, distance, time, and surge if applicable"
      "Rider can cancel without penalty before confirming"
    }
  }
}

Each acceptance criterion is a testable statement. The first (“within 3 seconds”) is a natural fit for an EARS performance requirement. The third (“no penalty before confirming”) will source the free-cancellation system requirement and, downstream, a domain-level state guard.

User Journey

A User Journey is a sequence of steps a persona takes to accomplish a goal, typically spanning multiple features and sometimes extending outside the product entirely. A journey is broader than a story: it includes steps the product does not control — “rider walks to the pickup point”, “driver waits for passenger” — and documents the emotional arc across the whole experience.

A user journey carries:

  • persona — the persona walking the journey.
  • trigger — what initiates it: “Rider needs to get to work”.
  • outcome — the desired end state: “Rider arrives at destination, receipt in inbox”.
  • design references — pointers to journey maps, flow diagrams, prototypes.
  • a sequence of journey steps.

Journeys are the right lens for spotting gaps between features. A bridge that no feature covers — “rider waits at curb and cannot tell if the driver is about to cancel” — is visible in a journey but invisible in any single feature card. Those gaps become candidates for new features, new notifications, or new timeout requirements.

Journey Step

A Journey Step is a single interaction within a user journey. Each step describes what happens from the persona’s perspective, not from the system’s.

A journey step carries five attributes:

  • action — what the persona does or experiences: “Opens app and enters destination”.
  • system response — what the product does in response, if anything: “Shows fare estimate and available ride types”.
  • channel — where the interaction happens: app, web, sms, email, physical, backoffice, or external (outside the product).
  • emotional tone — optional: how the persona feels at this step (confident, anxious, frustrated, delighted, neutral). Emotional tone surfaces UX-critical moments that functional requirements miss entirely.
  • order — the step’s position in the journey sequence.

A step with channel = external marks a moment the product does not control but must account for. “Rider waits at curb for driver” is an external step — the product cannot move the driver faster, but it can send a proactive notification if the wait exceeds a threshold, or suppress driver-cancel actions in the final 30 seconds. These steps are the origin of many of the cross-cutting notification and timeout requirements a functional-decomposition approach would never surface.

Example:

step {
  order 3
  action "Rider waits at pickup point for driver"
  system-response "Shows live driver location; pushes arrival notification at 1 minute away"
  channel external
  emotional-tone anxious
}

The step is explicitly external — nothing about the walk to the curb is under product control. But the anxious emotional tone tells the product team that reassurance matters here, which is why the system response is a continuous location update plus a proactive notification. That design decision is visible on the journey and invisible anywhere else.