Currency ProgressBar

The prototype recreates the component as a working interface: switch between step and percentage variants, advance the flow, run the animation, inspect do/don't examples, and open the Code tab for a portable ProgressBar snippet.

A progress indicator sounds simple until it has to serve content, product, and engineering at once. The component needed to orient users, support different workflow types, and remain predictable enough for teams to ship without reinventing the pattern.

• Workflow complexity

  Financial decision flows often span several questions or sections. Users need explicit cues for what is complete, what remains, and whether moving backward is expected.

• Pattern drift

  Without a documented system component, teams could place progress bars near unrelated controls, move indicators backward unexpectedly, or omit value labels that explain the process.

• Implementation need

  The spec needed to translate design intent into usable props, including labels, separators, values, and variants that engineers could adopt directly.

• Different flows need different measures

  Some experiences progress by discrete steps, while others communicate a percentage complete. The component had to support both without changing the underlying mental model.

• Progress must never mislead

  The indicator should not move backward unless the user intentionally goes back. The documentation calls out that behavior as a product rule, not just a visual detail.

• Placement affects comprehension

  The progress bar belongs near the page content it describes, not below the question or attached to unrelated navigation controls.

• Design and code have to stay paired

  The same spec needed to show live examples, usage guidance, and props so implementation choices did not drift away from the design rationale.

1. 01

   Orient before asking

   Show how long the process takes before the user starts answering, especially in higher-friction money decisions.

2. 02

   Keep movement predictable

   Forward and backward motion should mirror user intent so the indicator feels trustworthy, not decorative.

3. 03

   Label the measure

   Use value labels like 'Step 1 of 5' or '25% completed' so the bar is readable even when the visual length is hard to estimate.

4. 04

   Document the edge cases

   Do/don't examples are part of the component, because misuse is often a placement or behavior problem rather than a styling problem.

The ProgressBar documentation turned a small UI element into a repeatable product pattern for long-form flows.

Variants

2

Step and percentage progress models

Governance

Do / don't

Behavior and placement rules documented

Handoff

Props

Design guidance paired with implementation details

The useful design work was less about the green bar itself and more about preventing ambiguity around it. By documenting anatomy, behavior, placement, and props together, the component gave teams a shared answer to the same recurring question: how do we tell users where they are without making the flow feel longer, less clear, or less trustworthy?