주요 내용

• 핵심 개념: 디자인 결정을 Figma가 아닌 글로 먼저 작성. 'Write-first, build later' 접근법.

• 왜 글쓰기가 먼저인가

  • 목업은 설득력이 강해 검증되지 않은 생각도 확정된 것처럼 보이게 함. 한 문장의 글은 숨길 수 없어 논쟁을 유발하고 비용이 적게 드는 초기에 잘못된 가정을 드러냄.
  • 글은 결정과 실행을 분리. 검토자는 아름다운 결과물 없이 의도 수준에서 논쟁 가능.
  • 글로 남은 결정은 영구적이고 검색 가능. 6개월 후에도 이유를 확인 가능 (DuckDuckGo의 비동기 문화와 부합).
  • 경제성: 문서는 한 번 쓰여 여러 번 읽힘. 짧게 쓰는 시간이 모든 독자의 시간을 절약.

• 글쓰기 우선 디자인 프로세스

  1. Discovery Doc (디자인 전): 목표, 중요성, 성공 기준, 가설(We believe [change] will produce [outcome] because [reason])을 명시.
  2. Design Peer Review: 탐색 내용 요약 후 파일 링크. 실제 예: AI 답변 기능에서 데스크탑 단독 vs 모바일 우선 결정을 댓글에서 논쟁으로 해결. 가장 명확하게 쓰인 주장이 승리.
  3. Direction Doc: 배경, 연구 결과, 제안, 그리고 변경된 모든 디자인과 그 이유를 나열. 이유 없는 변경은 제거. 설명할 수 없는 결정은 선호도일 뿐.
  4. 구현 및 실험: 코드 작성 후 가설 검증. 문서화된 계획에 따라 실행.
  5. Mid-mortem / Postmortem: 예측 대비 실제 결과 기록. 다음 Discovery Doc의 기반.

• 짧고 명료하게 써야 함

  • 아무도 끝까지 읽지 않는 문서는 결정을 내리지 못함. 간결함이 핵심이나, 무미건조하지 않도록 맥락과 감사를 덧붙임.
  • 여러 포인트 중 결정에 가장 중요한 것을 먼저 배치. 덜 중요한 것은 나중에 언급하거나 생략.
  • 때로는 쓰지 않는 것이 더 강력. 댓글 추가 전에 모든 독자의 주의를 기울일 가치가 있는지 자문.

• PM과의 차이 (저자 인정)

  • 방법론은 좋은 PM이 사용하는 것과 동일하지만, 펜을 쥐는 사람이 다름. 가설을 쓰는 사람이 디자인하고 코드를 작성. 핸드오프 없음, 번역 손실 없음.

• 디자인 엔지니어에게 중요한 이유

  • 순수 디자이너: 잘못된 것을 다듬지 않도록 방지.
  • 순수 개발자: 검증되지 않은 방향을 구현하지 않도록 방지.
  • 동시에 하는 경우: 구현에 대한 애정이 정당화를 역설계하는 함정을 깨뜨림. 코드에 앞서 산문으로 추론에 전념.
  • 더 나은 빌더가 됨: 기능을 더 일찍 자를 수 있음 (처음부터 문서에 없었기 때문).

• 결론: 문서 자체가 목적이 아님. 절차의 순서가 중요. 말로 결정해 잘못될 경우 오후를 낭비, 코드로 잘못되면 스프린트를 낭비. 가장 싼 실패 장소는 한 단락이므로, 그곳에서 대부분의 실패를 경험하라.