A design doc is simply a document detailing how you plan to build a system from beginning to end. In this document, you should break down each planned feature of your system into individual actionable items which can be assigned to team members. Remember to think about the feasability and complexity of your system as you design it, so that the architecture is sound and you do not overcommit or undercommit to any particular feature.
- Design decisions (behavior for uncommon cases, which scenarios to support, etc)
- Implementation plans (implement infra A, then function B, then UI C)
- Potential risks and difficulties, if any
93%: Contribution was below expectations for that member of the team.
- Design Document does not follow standards set in How to Break Down Large Tasks
- Task proposals are infeasible or architecturally impossible
96%: Contribution was at expectations for that member of the team. This is the baseline grade.
- Pros and cons of your approach are described.
- Plan is mostly actionable.
100%: Contribution was above expectations for that member of the team.
- Pros and cons of your approach are clearly described.
- Strong justification of why your design is optimal or most feasible.