4 Design document

 

This chapter covers

  • The most common myths around the design document
  • Defining antigoals for an even sharper focus on core objectives
  • Drafting a design document based on the information available
  • Reviewing a design document
  • The evolution of a design document

Once you have defined the problem your system should solve, as well as a list of stakeholders, and have a rough understanding of what technologies and solutions would be most appropriate for the product, as described in chapter 3, it is time to prepare a design document.

It is worth noting here that there is no set-in-stone order of actions at the early stage of creating a machine learning (ML) system. You can start preparing a design document as soon as you’ve identified the problem and goals (especially if you work in a startup, where the speed of delivery is often more important than following processes). But since this book is presented as a checklist, the list of actions is also displayed in a traditional sequence.

As one of the authors’ managers once said, no fancy recommendation algorithm can beat a customer with a shopping list. These people have a goal and a plan for achieving it. Nothing can stop them.

4.1 Common myths surrounding the design document

4.1.1 Myth #1. Design documents work only for big companies but not startups

4.1.2 Myth #2. Design documents are efficient only for complex projects

4.1.3 Myth #3. Every design document should be based on a template

4.1.4 Myth #4. Every design document should lead to a deployed system

4.2 Goals and antigoals

4.3 Design document structure

4.4 Reviewing a design document

4.4.1 Design document review example

4.5 A design doc is a living thing

Summary

sitemap