Update existing tech design doc to include MM discovery doc language (#…

…2221)

docs/templates/technical-design-discussion-template.md

@@ -1,79 +1,54 @@
 ---
-title: Technical Design Discussion Template
+title: Technical Discovery Template
 ---
 
-## Title of Design Doc
+# Title of Design Discovery Doc
 
 ## Overview
 
-In one or two sentences,
-summarize what the problem is and how you intend on solving it.
-It's helpful to outline the stakeholders here,
-as it informs why this problem merits solving.
+In one or two sentences, summarize the problem (may be a feature epic under consideration)
+
+## Links
+
+Jira ticket links or diagrams
 
 ## Constraints (optional)
 
-Write what this document will not cover.
+Write what this document will not cover
 
 ## Terminology (optional)
 
-Define any terminology you are using that could be application system jargon 
+Define any application system jargon
 
-## Background
+## Discovery
 
 This section is for going into more detail about the problem.
 
-- Who are the stakeholders and how have they been impacted?
-- Historically, what effect has the problem it had?
-- Is there data to illustrate the impact?
-- Is there an existing solution?
-  If so, why does it need to be improved on?
-- Are there past projects or designs to link for context?
+### What do we need to be able to do?
 
-## Examples
+### How should we do it?
 
-At least one example should be used to help the audience understand the context better.
+### What relevant code or tooling do we have already?
 
-## Proposed Solution
+### What architectural considerations exist?
+examples: new or adjusted programming patterns, new or adjusted infrastructure, new libraries introduced, permissions modeling changes, data model changes. Was there a build vs. buy solution? Was there scope considerations or tradeoff?
 
-Detail your solution here.
-Start with a broad overview and then go into detail on each portion of the design.
+### How will we test this ?
 
-- What changes will the stakeholder/client see?
-  This should clearly illustrate how the stakeholders' needs are being met
-- How exactly does it solve the problem outlined above?
-  Explain how this solution applies to the use cases identified.
-- Why are you picking this solution?
-- What are the limits of the proposed solution?
-  At what point will the design cease to be a viable solution?
-- How will you measure the success of your solution?
-- If priorities shift or the solution becomes too cumbersome to implement, how will you roll back?
 
-Visual representations of the solution can be helpful here (ex. a diagram for a request lifecycle).
-
-## Implementation
+## Proposed Solution
 
-Without going too much into individual tasks,
-write an overview of what this solution's implementation would look like.
+Detail your solution here. Start with a broad overview and then list the ticket-level tasks as you see them.
 
-- Can this be broken down into multiple technical efforts?
-- What is the tech stack involved?
-- Will additional infrastructure be needed to achieve this?
-- How will you test this?
+Visual representations of the solution can be helpful here as well.
 
-## Trade-offs
+## Dependencies (optional)
 
-- This section should go over other possible solutions,
-  and why you chose yours over them.
-- Was there a build vs. buy solution?
-- What industry standards/practices already exist?
-- Why is your solution better?
+Are there any dependencies on other feature epics or third party tools? Do we need anything from other teams?
 
-## Cross Team Dependencies (optional)
+## Open Questions
 
-If there are multiple teams or clients that are dependencies for implementation to be successful,
-list them here.
-Examples of this are security or design collaboration/reviews.
+Add any open questions still remaining.
 
 ## Further Reading