Status: 📄 In Project Definition [be sure to keep this updated throughout the project]
Product Design Lead: ... (document author)
Product Manager: ...
Engineering Manager: ...
Eng Team: ...
Purpose of this doc: To define the scope, goals, details and other relevant information about this project. This document serves as the aggregate reference point for the project.
See also: [include other relevant docs here]
Write out background context about the project here, including what we are doing, why we are doing it, and any other relevant details...
[...write out the story of this feature as it would be told to someone in conversation, or at the beginning of a demo video for the feature...]
Product: what is the primary goal of this project from a product perspective? Articulate here...
Business: what is the primary goal of this project from a business perspective (if distinguishable from product perspective; may be more focused on business strategy than product experience)? Articulate here...
Design: what is the primary goal of this project from a design perspective? Articulate here...
Engineering: what is the primary goal of this project from a product perspective? Articulate here...
Category 1 (use categories to group JTBD when applicable)
- As a [user role or other situation] I want to [articulate what the user wants to be able to do]
- ...
The project will include:
- describe the key components of the feature/project from an experience/product perspective
- ...
To be clear, here is what we are not addressing in this project:
- include things intentionally we are deciding not to solve for right now...
Basic constraints we need to work within:
- this work needs to be GA shipped by...
- we will be using...
Some measures of success that we can look for:
- Increase in monthly active users...
- etc...
- Sketching and wireframing for ...
- High fidelity design explorations for ...
- etc...
For the team: feel free to add questions for discussion and clarification here:
- identify any key questions to discuss with product, engineering, or other stakeholders here...
- ...
To help keep our process efficient, we can solve for some major decisions at the beginning at a low fidelity stage of the design process that focuses less on the entire UI details and more on just the specific parts in question (usually overall layout, placement of components, etc – things that can be rendered quickly as sketches or with other wireframing tools).
Brief description of the item and what is to be decided (usually a choice about the overall layout, etc), including rationale for different options and images below. Be sure to record discussion notes from each decision stakeholder (typically best done in a triad sync meeting via discussion, and then key points captured here for later reference).
[Example] Option 1: add a new section to the core workflow
| Pros | Cons |
|---|---|
| some upside here... | some downside here... |
| some other upside here... | some other downside here... |
Decision Record:
- team member - notes from decision...
👂 Sync with ... on ...
Space here for notes from other key discussion (if applicable)
(Figma file here)
Design exploration TODOS:
- add design tasks here for reference if useful (be sure to include on your team’s project board also!)
- ...
- checklist of steps goes here to track progress and outstanding stages/tasks at a high level (or whatever level is useful for you in this doc)
- ...
- ...
- Design exploration
- initial research
- sketching / wireframes / paperframes
- hifi design explorations
- Design delivery (READY FOR DEV)
- ...list and link specific comp groups ready for dev here
- Engineering handoff
- review designs with team
- work with team on implementation details
- Q&A testing
- session 1
- ...
- Docs
- sync with docs to discuss docs plan
- ...
- Support
- sync with Support to let them know about the feature and discuss any potential common issues that users may face
- Marketing
- write feature narrative as a framing reference for marketing
- sync with marketing to discuss supporting release
- Ship date
- update Changelog
- tweet it
- Retrospective
- ...(notes)
- Future planning
- Identify most obvious post-ship iterations, open issues/board tickets
- Identify blockers, challenges, outstanding questions/decisions before future work will commence
- Identify where in the Roadmap future work belongs
- Sharpening the saw
- Figma file cleanup
- finish converting design elements to components & variants and update mocks accordingly
- Migrate new components and variants to design system
- ...
- Figma file cleanup
...after the initial design work has been completed, there may be several ideas that came up that are not included in initial scope. This space can be used to document those ideas to revisit later (it’s often helpful to write them down in as much detail as possible while they are still top of mind) and any other relevant project sequencing notes.
- ...
- ...
- ...
- ...