Stepper Specification

Stepper Specification

Contents

1. Overview
2. User Stories
3. Functionality
4. Test Scenarios
5. Accessibility
6. Assumptions and Limitations
7. References

Owned by

Team Name

Developer Name

Stefan Ivanov

Requires approval from

• Peer Developer Name | Date:
• Simeon Simeonov | Date:

Signed off by

• Product Owner Name | Date:
• Platform Architect Name | Date:

Revision History

Version	Users	Date	Notes
1	Names of Developers and Designers	Date

1. Overview

Objectives

The stepper conveys the progression of a sequence of individual steps indicating how much of a workflow has been completed and how much is left. It usually shows as a vertical or horizontal line with connected, numbered elements indicating the individual steps.

Acceptance criteria

Must-have before we can consider the feature a sprint candidate

1. The stepper should inform the user about the history of actions.
2. The stepper should inform the user about the current progress.
3. The stepper should inform the user about which and how many steps remain.
4. The stepper should show the direction of movement.
5. The stepper should support an arbitrary number of steps, usually, 3-5 are optimal.
6. The stepper should support numbering as a way to show the order of steps.
7. The stepper should support icons and visuals to better describe each individual step.
8. The stepper should support a horizontal layout for desktop and vertical for mobile.

2. User Stories

Elaborate more on the multi-facetted use cases

Developer stories:

• Story 1: As a developer, I want to be able to choose the stepper layout, so that I can show a horizontal one on desktop and a vertical one on smartphone screens.
• Story 2: As a developer, I want to be able to choose whether steps are mandatory or optional, so that I can have proper validation at the end of the flow.
• Story 3: As a developer, I want to be able to define arbitrary layout as the content for a step, so that I can create progressive forms and onboarding flows without being constrained.
• Story 4: As a developer, I want to be able to define the position of the label for step, so that I can place it before, after, above or below the visual indication.
• Story 5: As a developer, I want to be able to customize the visual step element, so that I can add a graphic element in it.
• Story 6: As a developer, I want to be able to define whether a line should be drawn to connect the steps, so that I can support the user to understand the sequence of steps.
• Story 7: As a developer, I want to be able to define the stepper as strictly linear (gated mode vs. ungated mode where you navigate steps freely), so that I don't let users to move to the next step unless everything up to it has been completed.
• Story 8: As a developer, I want to be able to define the stepper as read-only, so that it only serves as a visual cue but cannot be clicked to navigate between steps.

End-user stories:

• Story 1: As an end-user, I want to have a clear visual indication of what I should expect from each step, so that I know which ones are relevant/important to me.
• Story 2: As an end-user, I want to have a clear visual indication for the step I am currently at, so that I know approximately how much is left.
• Story 3: As an end-user, I want to have a clear visual indication for completed and uncompleted steps, so that I can finish what is left.
• Story 4: As an end-user, I want to have a clear visual indication for optional steps, so that I can skip them if they are not relevant.
• Story 5: As an end-user, I want to navigate between the steps with the keyboard one at a time, so that I can fill a progressive form more quickly.
• Story 6: As an end-user, I want to see the progress of a multistep process, so that I can e.g. track the delivery of an order.

3. Functionality

Describe behavior, design, look and feel of the implemented feature. Always include visual mock-up

3.1. End-User Experience Nesting steppers into each other is frustrating and destroys the UX.

References for well-designed and functional steppers:

3.2. Developer Experience

3.3. Globalization/Localization

Describe any special localization requirements such as the number of localizable strings, regional formats

3.4. Keyboard Navigation

Keys	Description

3.5. API

Options

Name	Description	Type	Default value	Valid values

Methods

Name	Description	Return type	Parameters

Events

Name	Description	Cancelable	Parameters

4. Test Scenarios

Automation

• Scenario 1:
• scenario 2:

5. Accessibility

ARIA Support

RTL Support

6. Assumptions and Limitations

Assumptions	Limitation Notes

7. References

Specify all referenced external sources