- Hint Health is an enterprise software company with only a handful of engineers. We handle payments for big health care clients, and we can't afford to "just try whatever". We have to balance speed with getting things right the first time. This checklist has been iterated on many times, and has proved very helpful in doing that.
- The goal here is to 1.) Make sure you build things people want. And 2.) Surface problems and implications of the design as fast as possible, by reminding ourselves of important questions that can easily get overlooked.
- Use the top area to consolidate the latest thinking on the feature. (on that point, we don't use this for bugs or chores. only features)
- Use the checklist at the bottom to make sure you're asking the right questions, and do a kick ass job of defining, designing, and implementing the feature.
- As soon as you're like... "we should build X", stop and do the User Requirements Pipeline. This alone often catches and clarifies things significantly. You might have enough knowledge at that point to decide if you should actually build the feature. If not, doing some of the design pipeline might shine more light on the difficulty. Assuming it does get prioritized and picked up, then you do everything else.
- This is what is working for us now. But we're always refining, so season to taste.
Name:
PM: (Who's making sure this feature happens?)
Rough Value to Users Who Use It: (Low|Med|High)
Rough Number of Users Who Will Use It: (Low|Med|High)
Rough Engineering Difficulty: (Low|Med|High)
User Stories:
-
story 1 - As a user, I can...
-
story 2
-
Evidence - Customer interviews reveal X. Usage data reveals Y.
Designs:
- Wireframes
- DB / Schema Changes
- API / Logic Changes
- Front Ends
- Why this was chosen
Alternate Designs:
- alt 1
- Why these were not chosen
Background Information:
- Why? Customer email links? Phone call, or convo notes?
- Define User Stories (not implementations: "A way to track progress in-app" VS "add some checkboxes") - Consider implications for other parts of the app such as Reporting or the Public API.
- Observe / Get Feedback on User Stories (from relevant current or future customers)
- Provide link / context to these user stories - give readers confidence these user stories are accurate
- Prioritize User Stories, mark any as optional for the MLP (minimum lovable product)
- External Impact (Payments, Integrations, Customer Emails, Public API)
- Reporting Changes / Additions
- Mocks / Prototypes for the 5 screen states (Ideal, Empty, Error, Partial, Loading)
- DB Schema Changes
- API Changes (routes, params, responses)
- Core logical points, list any places to specifically look out for
- Add a note to explain alternate design theories and why this design was chosen over the others
- Break out design into codable issues. Each issue needs front or back end designs written in such a way that another engineer could fill in any gaps without requiring discussion.
- Schedule Deploy with Customer Success / Eng (so it's not during demos, and so the right people are nearby if it breaks)
- Coordinate Updating of Help Docs / Announcement with Customer Success
- Do we need a retro about this story / the process? How could this have gone better?
- Did this solve the customer's needs, are they using it? Observe / get feedback from users