The document discusses different types of design documents for data science projects, including architecture, implementation, and idea documents. It provides guidance on how to structure design documents, including outlining objectives, minimum viable products, research plans, milestones, and summaries. The document emphasizes that design documents serve as conceptual lighthouses to communicate plans and navigate complexity, and different document types are suited for different stages and audiences of a project.

1. Unboxing Design
Docs for Data
Scientists

2. Wait, who am I?

3. Meet Vincent
ML Engineer/Analyst (Machine Learning)
Trust & Safety Google
Medium : towardsdatascience.com/@vincentkernn
Linkedin : linkedin.com/in/vincenttatan/
Data Podcast: https://datacast.simplecast.com/

4. Disclaimer
This disclaimer informs readers that the views, thoughts, and opinions
expressed in the text belong solely to the author, and not necessarily to the
author’s employer, organization, committee or other group or individual.
This article was made purely as the author’s initiatives and in no way driven by
any other hidden agenda.

5. Google:
Trust and Safety To prevent phishing @
scale with Data Analytics
and ML
Google
Data Analyst, Machine Learning
Aug 19 - Present

6. Proprietary + Confidential
Today’s Agenda
1
2
3
Why Design Docs?
How to build Design Docs (Demo)?
[What] Types of Design Docs?

7. Proprietary + Confidential
TL:DR (Too Long Didn’t Read)
1
2
3
Why Design Docs? → As a conceptual lighthouse (communication)
How to build Design Docs (Demo)? → objectives, MVP, Research, Milestone, TL:DDR
Types of Design Docs? Architecture, Implementation, and Idea

8. 1 Why Design Docs?
As a Conceptual Lighthouse
1

9. Understanding Design Docs
Medium Articles
https://towardsdatascience.com/the-undeniable-importance-of-design-docs-to-data-scientists-421132561f3c

10. How do I make sure my data project is successful?
How do I communicate and realize impact for my
stakeholders?

11. The Biggest Noob Mistake
You received a new project. After glancing through the problem, you jumped into the code hoping to resolve
your project quickly.
But later you realized you introduced many bugs; open source packages were broken, outages breakdown
due to size, repeats of experiments due to lack of technical documentation. Desperate, you spent weeks
troubleshooting your subpar model.
Once you were done, you realized that your newly built model was simply too complex and obtuse for the
engineering team to support. Disgruntled, you spent all nighters to implement a simple model which did
enough for the team
— Spoken from the author’s experience —
● Lack of planning
● Untracked Experiments/Documentations

12. The story of Netflix $1M Shiny Stone

13. We need a way to 1) navigate business, data, and
engineering complexity while 2) writing clear
documentation and 3) managing stakeholders’
expectations

15. Design Docs Navigate Short Sightedness in the Dark
Design docs are meant to be lighthouses.
A lighthouse signals a goal.
Every embarking boat needs a lighthouse to navigate
the sea in the dark.
The turbulent waves might distract the boat to detour. But
with the lighthouse, every boat captain has the power
to steer the boat to the destination.
Dark = Unrealized Data Project, Boat = You,

16. Design Docs Deliver Shared Impacts
Design docs are highly used in Engineering focused
culture such as Amazon and Google.
They are meant to share ideas, progress, and results on
all initiatives to highlight shared goals and impacts.

17. Design docs form conceptual lighthouses to
understand how you navigate short-sightedness,
eliminate time sinks and deliver shared impacts.

18. 2 How to Build Design Docs
The Structure of Design Docs for Effective
Communication

19. How To Build Design Docs
1. Objectives: Why are you building this?
2. Minimum Viable Product: What’s important for your audience?
3. Research and explorations: What time and resources are available?
4. Milestones and Results: What can and has been achieved?
5. TL:DR (Too Long Didn’t Read): What’s the summary?

20. Demo / Sample (Yayasan Merajut Hati – YMH)

21. Objectives
Why are you building this?
Create a world where anyone can belong anywhere and
focus on creating an end-to-end travel platform that will
handle every part of your trip
Tips:
You can also use design docs to create your own personal objective / work ethics memorandum
Organize the world’s information and make it universally
accessible and useful.
Give people the power to build community and bring the
world closer together
AirBnB
Google
Facebook
● [Demo] To extract high quality Instagram data exclusive to YMH Marketing Needs.
● To increase FN coverage with Graph Network (GNN).

22. TL:DR is a great way to conclude results and share knowledge quickly. It gives your stakeholders the gold
nugget for them to decide if they should read further.
The best benefit of TL:DR is to respect each other’s time. It saves your stakeholders time while allowing them
to understand your actual work and impacts.
In terms of order, I will put TL:DR after objective. This allows stakeholders to directly view the summaries to decide
further time investment to read.
Too Long Didn’t Read
What’s the golden nugget (summary)?

23. Minimum Viable Product (MVP) defines the core
value of your project.
It is the North Star which you rely on to determine if
your project is successful. You can safely declare
success as long as your project achieves it.
Guide of MVP:
● Realistic than idealistic
● Conservative than ambitious
● Metrics Focused
● Iterative
Minimum Viable Product (MVP)
What’s important for your audience? (Deliverable)

24. Research and Explorations
Action steps, time, and resources available
Research and explorations define the methods
available to build your MVP.
This requires open ended brainstorming which
include:
● What tools are you going to use? Why?
● How much time do you set to accomplish this?
● [For ML Project] What Exploratory Data Analysis
(EDA) do you do? Why is this important? What
models should you build? Why?
Having a quick research and exploration will enable you
to switch solutions quickly when your solution fails
to meet the MVP.

25. Milestones and Results
[Milestones] What can be achieved? [Results] What has been achieved?
Milestones and Results defines the actual work you plan or have accomplished towards your MVP.
Milestones set dynamic short term goals which are set on your explorations and research . Milestones will
become results once you do the actual work. Start by building milestones to break down your MVP. Once you
accomplish the milestones, document the results (e.g: generated insights to increase XX% viewer reach).

26. Recap
Why Design Docs
1. Objectives
2. Minimum Viable Product:
3. Research and explorations:
4. Milestones and Results
5. TL:DR (Too Long Didn’t Read)

27. 3 Principles of Design Docs
Varieties of Design Docs for Various
Circumstances with Best Practices

28. Understanding Design Docs
Medium Articles
https://towardsdatascience.com/understanding-design-docs-principles-for-achieving-data-scientists-53e6d5ad6f7e

29. Who is your audience?
Yourself
Team
Members
Cross
Department
Executives
External

30. The Right Design Docs Types for The Right Space

31. “If you don’t know what you want to achieve in your
presentation, your audience never will.” — Harvey
Diamond

32. Space Objectives Main Audience Time Types
Architecture
(Stable)
high level
architecture on
complex and
impactful systems
Executives,
Techleads, External
Slow and stable.
Ideally, it rarely
changes except due
to disruptions
Architecture Doc,
North Star Metrics
Implementation
(Launch)
facilitate system
designs
implementations (ML
Ops, data privacy
access, etc).
Tech Leads, Cross
departments
(especially
up/downstream
applications)
Moderate changes System Design,
Timeline Launch
Documents, Privacy
Documents
Idea (Experimental) To experiment minor
tweaks, idea
brainstorm, and quick
feedback gathering
Everyone including
cross department
Highly dynamic One pager, Learning
Journeys, Pre (Post)
Execution,
Evaluations, Pre
(Post)Mortem
The Right Design Docs Types for The Right Space

33. The Principles of Design Docs
1. Start from Ideas: Always start your experiment on one pager (idea spaces). Create a thought
experiment and brainstorm quickly before investing further time into the idea.
2. Invest Time in Lower Level Spaces: The higher the space (Idea → Implementation → Architecture),
the more time you should invest. Spend at most 1 week on one pager (idea space), 1 month on
implementation/analysis space, and 1 quarter/semester on architectural space. Of course this
depends on the scope, but you get the gist.
3. Prioritize Promising One Pagers: Promote and scale your one pagers based on impacts. If the idea
is intended for cross collaboration, spend more time deliberating how your goals align the high level
spaces (North Star Metrics, System Design, etc).
4. Land Into North Star: For general success metrics, focus on ideas with lowest time investments (e.g:
small tweaks on machine learning), with high impacts to North Star Metrics. This helps you to build
solid foundations to land in higher spaces.
5. Point Directly to Golden Nugget: Your design docs need to point the audience to the golden nugget
as direct as possible. The higher the space is, the more direct this golden nugget should be.

34. The Principles of Design Doc Visualized
T
I
M
E
Start from Ideas
Invest Time in Lower
Level Spaces
Prioritize Promising
One Pagers
Land Into North Star
Point Directly to
Golden Nugget

35. Recap
Why Design Docs
1. Architecture Space
2. Implementation Space
3. Idea Space
4. Top Principles in Design Docs

36. Proprietary + Confidential
TL:DR (Too Long Didn’t Read)
1
2
3
Why Design Docs? → As a conceptual lighthouse (communication)
How to build Design Docs (Demo)? → with objectives, MVP, etc
Types of Design Docs? →From Idea to Implementation

37. Unboxing Innovation in Data Projects
Medium Articles
https://towardsdatascience.com/unboxing-innovation-in-data-projects-3f8220618b1a

38. Reach out to me :)
Medium : towardsdatascience.com/@vincentkernn
Linkedin : linkedin.com/in/vincenttatan/
Survey: tiny.cc/vincent-survey
Please share your experience via
linkedin/comment in Youtube as well
:)
Soli Deo Gloria

39. Appendix
Slides graveyard

40. Architecture Space (Stable)
Design Docs Characteristics
● Objectives: Document high level architecture on systems which solve complex problems
and leads to direct user impacts.
● Main Audience: Executives, Tech Leads
● Time: Slow and stable. Ideally, it rarely changes except due to disruptions.
Types of Design Docs
● Architecture Doc: Document high level system architectures with clear objectives For
example, project Google Loon aims to solve the scarcity of reliable internet
infrastructures.
● North Star Metrics: Identify critical metrics to measure success/failures for executive
communications. For example, in customer facing apps, the metrics will be user
adoptions while it will be protecting users in abuse fighting apps.

41. Implementation Space (Launch)
Design Docs Characteristics
● Objectives: To facilitate system designs implementations for example data storage, ML
Ops, data privacy access, etc. This document ensures data products are launched,
scaled, and evaluated properly.
● Main Audience: Tech Leads, Cross departments (especially up/downstream
applications)
● Time: Moderate changes
Types of Design Docs
● System Design: Highlight system implementation flowcharts, up/downstream
interactions, data storage, appeals, etc.
● Timeline Launch Documents: Highlight progress and timeline for a system to launch. In
Google, we have Standard Operating Procedures (SOP) to ensure each launch is
properly maintained and scaled.
● Privacy Documents: Manage confidential data regarding users or other sensitive
agencies.

42. Idea Space (Experimental)
Design Docs Characteristics
● Objectives: To experiment minor tweaks, idea brainstorm, and quick feedback gathering.
● Main Audience: Everyone including cross department
● Time: Highly dynamic. One pagers are drafted, analysed and discarded on a daily basis. Your
goal is to fail quickly and move on.
Types of Design Docs
● One pager: Fast moving design docs to facilitate early idea reviews. As ideas grow to proven
concepts, the one pager will be promoted into two pagers and system design docs.
● Learning Journeys: Identify learning journeys in terms of past presentations, design documents,
models launched. In big companies, the learning journeys are necessary to keep track of
changes that happen very quickly in cross department and regional collaborations.
● Pre Execution Evaluations: What are the expected impacts if we launch a product (e.g: models
/ tweaks)?
● Post Execution Evaluations: What are the impacts after the past launched product (e.g: models
/ tweaks)?
● Pre Mortem: What could go wrong when the product is launched?
● Post Mortem: What has gone wrong after the past launched products?

43. The Right Design Docs Types for The Right Space
1. Start from Ideas: Always start your experiment on one pager (idea spaces). Create a
thought experiment and brainstorm quickly before investing further time into the idea.
2. Invest Time in Lower Level Spaces: The higher the space (Idea → Implementation →
Architecture), the more time you should invest. Spend at most 1 week on one pager (idea
space), 1 month on implementation/analysis space, and 1 quarter/semester on
architectural space. Of course this depends on the scope, but you get the gist.
3. Prioritize Promising One Pagers: Promote and scale your one pagers based on
impacts. If the idea is intended for cross collaboration, spend more time deliberating how
your goals align the high level spaces (North Star Metrics, System Design, etc).
4. Land Into North Star: For general success metrics, focus on ideas with lowest time
investments (e.g: small tweaks on machine learning), with high impacts to North Star
Metrics. This helps you to build solid foundations to land in higher spaces.
5. Point Directly to Golden Nugget: Your design docs need to point the audience to the
golden nugget as direct as possible. The higher the space is, the more direct this golden
nugget should be.