Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[DevDojo] Mercari Design Doc - 2024

[DevDojo] Mercari Design Doc - 2024

This session teaches the basics of the design docs (also known as technical specifications) needed for product development. It also explains how to write a good design doc and how design docs are used at Mercari.

Avatar for mercari

mercari

May 30, 2024
Tweet

More Decks by mercari

Other Decks in Technology

Transcript

  1. Design Doc - Definition A technical spec about a feature

    or a system that outlines the technical directions, design decisions, and implementation details of the system or feature
  2. Design Doc - Purpose? - Blueprint - Provides a roadmap

    for developers and other stakeholders, guiding them through the design and implementation process - Communicate Decisions - Documents the logic behind architectural design choices, ensuring clarity and understanding among team members
  3. Design Doc - Why? • Clarity and Communication ◦ Requirements,

    system’s architecture & design • Roadmap for Development ◦ Implementation roadmap, components interaction, technical details ◦ Speed up development • Risk Mitigation ◦ Identify potential risks and challenges early • Documentation ◦ Reference doc throughout the development ◦ Aiding in maintenance and future enhancements • Deliver with Quality ◦ Getting feedback from various stakeholders ◦ Improve code review quality
  4. Design Doc - When? Spec Discussion Design doc Development PM

    plans/create a new idea Design and functionalities are fixed Start development after getting approval for design doc
  5. Design Doc - Process Design Discussion Review Code Before writing

    code,and/or while prototyping By people having an insight for the domain Incorporate insight and idea Similar to “develop/review code” but It costs much less if written before actual code
  6. Design Doc - Lifespan • Draft version and iteration ◦

    Shared initial draft with teammates ◦ Update until find a stable version • Review ◦ Shared with wider audience • Implementation and Iteration ◦ Start implementation when reviews are done or almost done ◦ Update if anything minor changes while implementation ◦ For major changes create another version • Maintenance and Learning
  7. Design Doc - How? • Gather Requirements • Define Scope

    • Outline Structure • Architecture • Include Visuals • Release plan
  8. Design Doc - Teams • Each team may have a

    different process ◦ Design Docs may be required before implementation of some features ◦ Other engineers or the tech lead may need to approve ◦ Templates might be different ◦ Some teams may not have a design doc flow • Individual ◦ Even if your team does not require it, you might write design docs for your own learning