Programming/Design Docs: Difference between revisions
No edit summary |
No edit summary |
||
Line 13: | Line 13: | ||
* Requirements, | * Requirements, | ||
* Out of Scope, | * Out of Scope, | ||
* Tenets, | |||
* Success Criteria and Metrics, | * Success Criteria and Metrics, | ||
* Proposed Solution, | * Proposed Solution, |
Revision as of 09:59, 9 June 2021
What is a Design Document?
Amazon is known for being a bit weird for many reasons, but one of the reasons is Amazonians are prohibited from using PowerPoints or slide decks. Any transfer of information is expected to be written in a document. Instead of the meeting host giving a presentation, meetings start with time reserved for attendees to read the prepared document. Amazonians have names for each of these types of documents: some are familiar, such as Press Releases, and some are more Amazon-specific such as the One Pager. The document software developers write to convey their technological solutions to a given problem are called Design Documents, or design docs for short.
What is the General Structure of a Design Document?
The goal of a design document is to cover the entire solution in a way an outsider with little-to-no knowledge of your problem can understand the following:
- what problem you are trying to solve,
- how you are planning on solving it,
- and why you chose this solution over others.
Design document formats vary widely: a design document can be a word document, a wiki page, or a Markdown file, and it can be broken down in many different ways. I have found that starting with the following sections helps me consider all the data needed to form a complete solution:
- Problem Statement,
- Requirements,
- Out of Scope,
- Tenets,
- Success Criteria and Metrics,
- Proposed Solution,
- Low-Level Design,
- Architecture Diagram,
- Technology Decisions,
- Testing Strategy,
- Risks,
- FAQ,
- and Appendix.