<Insert Name of Feature>

• Associated: (Insert list of associated epics, issues, or PRs)

<!-- Note: Feel free to add or remove sections as needed. However, most design docs should at least keep the suggested sections. -->

The Problem

<!-- What is the user problem we want to solve? The answer to this question should link to at least one open GitHub issue describing the problem. -->

Success Criteria

<!-- What does a solution to this problem need to accomplish in order to be successful? The criteria should help us verify that a proposed solution would solve our problem without naming a specific solution. Instead, focus on the outcomes we hope result from this work. Feel free to list both qualitative and quantitative measurements. -->

Out of Scope

<!-- What does a solution to this problem not need to address in order to be successful? It's important to be clear about what parts of a problem we won't be solving and why. This leads to crisper designs, and it aids in focusing the reviewer. -->

Solution Proposal

<!-- What is your preferred solution, and why have you chosen it over the alternatives? Start this section with a brief, high-level summary. This is your opportunity to clearly communicate your chosen design. For any design document, the appropriate level of technical details depends both on the target reviewers and the nature of the design that is being proposed. A good rule of thumb is that you should strive for the minimum level of detail that fully communicates the proposal to your reviewers. If you're unsure, reach out to your manager for help. For the console, depending on the scope and complexity of the design, some things you might want to include are: * If/how this solution depends on other interfaces, such as the cloud and database APIs. Are any changes required there? * What libraries you're planning to use. * What shared components you'll use, and what new components you'll add. * Any refactoring or other pre-work required. * How the work will be phased. * Where and how feature flags will be used. * Other considerations you might want to think about up front, like dark mode, smaller screens, browser support, error handling, testing, and observability that are more complicated than usual. Some of the above may instead be covered in the MVP section below. You can also create sub-sections in this section where useful to go into more detail. -->

Minimal Viable Prototype

<!-- Build and share the minimal viable version of your project to validate the design, value, and user experience. Depending on the project, your prototype might look like: - A Figma wireframe, or fuller prototype - SQL syntax that isn't actually attached to anything on the backend - A hacky but working live demo of a solution running on your laptop or in a staging environment The best prototypes will be validated by Materialize team members as well as prospects and customers. If you want help getting your prototype in front of external folks, reach out to the Product team in #product. This step is crucial for de-risking the design as early as possible and a prototype is required in most cases. In _some_ cases it can be beneficial to get eyes on the initial proposal without a prototype. If you think that there is a good reason for skpiping or delaying the prototype, please explicitly mention it in this section and provide details on why you you'd like to skip or delay it. -->

Alternatives

<!-- What other solutions were considered, and why weren't they chosen? This is your chance to demonstrate that you've fully discovered the problem. Alternative solutions can come from many places, like: you or your Materialize team members, our customers, our prospects, academic research, prior art, or competitive research. One of our company values is to "do the reading" and to "write things down." This is your opportunity to demonstrate both! -->

Open questions

<!-- What is left unaddressed by this design document that needs to be closed out? When a design document is authored and shared, there might still be open questions that need to be explored. Through the design document process, you are responsible for getting answers to these open questions. All open questions should be answered by the time a design document is merged. -->