spec-template.md

author	created on	last updated	issue id
<first-name> <last-name> <github-id>/<email>	<yyyy-mm-dd>	<yyyy-mm-dd>	<github issue id>

Spec Title

1. Overview

1.1 Establish the Problem

[comment]: # What is the problem? Consider an interesting hook; think of this like the start of an elevator pitch.

1.2 Introduce the Solution

[comment]: # How does this idea help fix the problem above? What is the benefit/value of doing this? Which customer(s) is your feature focused on specifically?

1.3 Rough-in Designs

[comment]: # Show, don’t just tell. It’s fine for these to be “low fidelity” – but help us understand the flow.

2. Goals & User Cans

2.1 Goals

[comment]: # What are the main goals of this feature (usually between 2-7 goals)? This section can be used for scoping and should help the reader get a sense of why we are building the feature. There is no need to list obvious goals, such as meeting compliance goals.

2.2 Non-Goals

[comment]: # Are there any explicit non-goals for this feature? This section can be helpful for scoping and to help readers get an understanding of what will not be covered by this feature.

2.3 User Cans Summary Table

[comment]: # What are the high-level User Cans needed to complete this feature? A User Can is written as something a user can do. For example: A user can turn the feature on in settings. The focus of this section is to ensure that the dev team has enough information to do high level swag costing.

3. User Stories

[comment]: # What are the user stories for their jobs-to-be-done? What is the user experience within this feature for the user to complete their job? What are the golden paths for getting the user to complete their job? What are the edge cases for this scenario?

3.1 User story - XXX

Job-to-be-done

User experience

Golden paths (with images to guide)

Edge cases

3.2 User story - XXX

Job-to-be-done

User experience

Golden paths (with images to guide)

Edge cases

4. Requirements

4.1 Functional Requirements

Summary

[comment]: # Write a paragraph that can be copy/pasted into an email explaining the use case & core behavior covered by this spec. Assume that your audience understands the customer and business value of your feature (which is outlined in the Overview section of this doc for reference). Focus on describing the functionality. Limit yourself to a max of 4-5 sentences.

Detailed Experience Walkthrough

[comment]: # Include images pulled from the Figma doc and place them directly into this document.

Detailed Functional Requirements

[comment]: # Priority definitions: P0 = must have for WIP (minimum initial experiment), P1 = must have for GA, P2 = nice to have for GA, P3 = GA+

No.	Requirement	Pri
1
2