Create a Design Plan

Design plans outline a general strategy for how the team will spend their time on architecture. Will we do more analysis up front? Are we expecting change later? When do we start writing code? A good design plan sets expectations and explains these details.

A design plan doesn’t have to be a formal schedule, but you do need to put some thought into it. Here are a few things every design plan should include: Capture your plan in a lightweight document such as an inception deck described.

Stopping conditions for design

Will you time-box up-front design work, or will you reduce risks no matter how long it takes? Will you do minimal up-front design before starting to write code, or do you want more of the architecture laid out? Can implementation start piecemeal, or do some areas need to start together? There is no single right answer. Stopping conditions depend heavily on the team, stakeholders, and project context.

Required design artifacts

Tell everyone how you plan to document the architecture before starting. Are you OK with pictures of whiteboards, or do you need a more traditional document? Does your team use specific templates? Where should design artifacts be stored?

Time line

Describe the key design milestones within the project schedule. Many large projects have a dedicated elaboration phase for gathering requirements and exploring architecture. Smaller projects or continuously maintained software systems might regularly schedule design spikes.

At a minimum, the time line should include milestones for reviewing architecturally significant requirements, reviewing draft designs, and conducting evaluations. Also, include any major workshops with stakeholders. Call out when you think implementation will start and what is in scope for early implementation.

Top risks

Since we are using a risk-driven design approach, include the top risks in the design plan as context. Revisit your risk list throughout the software system’s life, especially during any up-front architecture design.

Notional architecture design

Start with a potential solution. Recall that we need to think about the solution to help us define the problem. A notional architecture can be a lightweight sketch, just enough to communicate the essence of your initial design thoughts.

The amount of time spent on design could be hours, days, or even months depending on the software system. No matter your time horizon, if we use the four principles of design thinking covered and focus on finding a satisficing solution discussed, then we should arrive at a working solution by the time we need it.