Design is a process that results in a document called the Design Document. The document should provide several key sections covering core areas of the design process.

The process starts with a problem that needs a solution. Your first goal as a designer is to make sure that you understand the problem, so you need to outline the problem clearly in the first section of your design document. The problem statement sets the scope for the whole design, if you cannot articulate the problem, then you need to spend more time researching and meeting with people to understand it. You should also cover the benefit of addressing the problem to help stakeholders understand the benefit and weigh the cost of the solution against it.

After the problem statement, you should provide an overview of your proposal. The overview should be a couple of paragraphs that enable the reader to understand the overall idea of the proposal. The overview is usually targeted to the development leads or system architects. After the overview, you should proceed to describe the proposed solution in detail. You will need to split that into subsections that cover each subsystem or interface change you are proposing. The interface could be a system API or user interface or both. The audience of these detailed sections will be the owners of the different subsystems.

In addition to the proposal overview and details, you should provide information about the expected cost of the solution. If the change is small enough, the cost could be included in the proposal details as it will be mostly about change in code design or data flow. If the problem is large enough, the cost of the proposal may translate to a large investment in terms of development time or deployment costs. The latter case warrants a separate section in the document to outline the costs.

One other aspect where the design process kind of interacts with project management is the timeline. For proposals that will require coordination between multiple teams or external dependencies, calling out the proposed timeline will be beneficial.

Once you are done, the document should have the following sections:

• Problem Statement: Targeting all document readers.
• Proposal Overview: Targeting leads and system architects.
• Proposal Details: split into subsections cover subsystems and interface. Each subsection targets the owners of that subsystem.
• Expected Cost (optional)
• Proposed Timeline (optional)