| Author | |
|---|---|
| Date | |
| PRD URL |
This is your tech spec’s abstract: the who/what/when/where/why of your entire proposal. Keep it short (max 2 paragraphs).
Most designs are neither right nor wrong; they just offer different trade-offs. What are key considerations guiding the proposed solution? It’s very important to call out the limitations of this system.
Examples:
1. The solution needs to be implemented in one quarter or less because of a customer promise date.
2. The solution needs to scale up to 1,000 requests per second.
3. The solution will only support up to 100 users per account.
Limit feature creep and align expectations. What are things we won’t be implementing in this phase of the project?
Examples:
1. We will not make the expiration time configurable by the end-user.
2. We will not support uploading files more than 100MB in size.
3. We will not support A/B testing at this stage.
Provide data models, data flows, schema, systems choices. The more you can summarize with diagrams/tables the better.
Make sure to identify trade-offs with the proposal. See Appendix: Design Questionnaire for things you'll want to consider including here.
The PRD should have left you with sequences or use cases describing how the system should function from an external perspective. Walkthrough each and check that your design satisfies the requirement. The goal here is to avoid the realization, halfway through implementation, that you’re not going to be able to satisfy some requirements with your chosen design.
Examples:
1. Users will be able to upload files of up to 100MB.
2. We will have a sign-up flow that gets the following information from the new user.
An ordered list of the functions, classes, databases, and endpoints you need to build, ordered by inverse dependency (i.e. most basic things at the top). Add a rough time estimate each of these components will take. Think of it as a rough estimate of how long it would take you to build this component if you were just focused on it. Make sure to record the total in the JIRA Initiative ticket field “Dev Weeks”. The “Priority” can be used to distinguish the criticality of the component: needs to get done (P0), nice to have (P1), out of scope (P2).
| Component | Dev Weeks | Priority | Service | Dependencies (new service, new infrastructure) |
|---|---|---|---|---|
If you've identified multiple ways in which we might want to implement a component or a group of components, provide each alternative and list the pros and cons of each. Keep this short.
List unresolved design or implementation questions, along with an invitation for reviewers to give feedback. Feel free to call out specific people who may have valuable input.
Below is a list of questions you should think about in your design. Make sure to document.
- How will we test this system? Please give example test paths.
- What dashboards/metrics will be used to observe the system changes? Can your logs be readily searched? Any new Pingdom tests?
- What existing services or systems are put at risk by the proposed solution?
- What new features or requirements should be flagged for validation due to external visibility, security considerations, business concerns, etc?
- How do competitors or other libraries implement it?
- Is there a “build vs. buy” option? In other words, could we take advantage of a third-party vendor or library to achieve this?
- What is the expected impact on the performance of our production systems? Should we load test before releasing it to production?
- Does your solution depend on other teams? For instance, will you need new hosts/databases/load balancers?
- Will the proposed solution introduce any changes to existing services or databases which cannot be easily rolled back?
- How will we track analytics requirements from the PRD?
- Release plan. Is a release strategy required (e.g. data migration, backward-incompatible change, or new flow)? If so, what is the rollback plan?
- Support plan. What questions might the Cx/Support team expect to receive related to this project once it is deployed?
- Does the project depend on any external APIs or services? What are they?
- How does the solution protect users’ data privacy? Does the project introduce any new Personally Identifiable Information (PII) into our systems?