Back_to_Basics

{3줄 요약}

디자인 문서는 화면 뒤의 이유와 결정 과정을 또렷하게 남겨 주는 기록 장치예요.
이유가 남지 않으면 시간이 지난 뒤 같은 질문과 뒤집힘이 반복되기 쉬워요.
문서화를 하면 협업과 인수인계에서도 설계 기준을 더 안정적으로 지킬 수 있어요.

6개월 전에 만든 화면을 다시 손봐야 하는 상황이에요.
버튼이 왜 이 색인지, 이 흐름이 왜 이 순서인지 아무도 기억하지 못해요.
결국 회의를 열고 다시 결정해요.
그런데 예전에 이미 같은 토론을 했고, 같은 이유로 지금 방식을 선택했을 수 있어요.

이게 문서화가 없을 때 팀에서 반복되는 일이에요.

Sarah Richards는 《Content Design》에서 문서는 "콘텐츠를 만드는 사람을 위한 것이 아니라, 그 콘텐츠를 받아 쓰는 사람을 위한 것"이라고 했어요.
디자인 문서도 마찬가지예요.
만든 사람이 아니라 나중에 읽는 사람을 위해 써야 해요.

많은 디자이너가 문서화를 "Figma 파일을 깔끔하게 정리하는 것"으로 생각해요.
그건 문서화의 반쪽이에요.
Figma는 "어떻게 생겼는지"를 보여주지만 "왜 이렇게 생겼는지"는 담지 못해요.
그 "왜"가 진짜 문서예요.

결정과 그 이유

"이 버튼을 Primary로 쓴 이유는 이 화면에서 가장 빈번히 선택되는 행동이기 때문이에요. 두 번째로 자주 쓰이는 '취소'는 Secondary로 처리했어요."

이런 메모 한 줄이 나중에 "버튼 색이 왜 이래요?"라는 질문을 막아요.

기각된 방향들

"A 방향과 B 방향을 검토했고, B를 선택한 이유는 X예요. A는 이런 이유로 제외됐어요."

기각된 것을 왜 기록하냐고요?
3개월 뒤 새 팀원이 "이 방향은 어떤가요?"라고 물을 때, 그게 이미 고려됐다는 것을 증명해줘요.
같은 토론을 반복하지 않아도 돼요.

제약 조건과 가정

"이 화면은 서비스가 iOS 15 이상에서만 지원된다는 가정 하에 설계됐어요. API 응답이 1초 이내라는 기술 제약도 반영했어요."

이 조건들이 바뀌면 화면도 바뀌어야 한다는 것을 알 수 있어요.

미해결 항목

"이 화면의 에러 상태는 아직 확정되지 않았어요. 개발팀의 오류 분류 체계가 확정된 후 업데이트 예정이에요."

열린 것을 열린 것으로 표시해두면, 나중에 놓치지 않아요.

문서화 도구는 팀마다 달라요.
Notion, Confluence, Figma의 주석 기능, Zeroheight — 어떤 것이든 팀이 실제로 보는 곳에 있어야 의미가 있어요.

Figma 내 주석: 가장 접근성이 높아요. 컴포넌트 옆에 바로 붙어 있으니 개발자도 Figma에서 바로 읽어요. 짧고 핵심만 담는 게 좋아요.

Notion / Confluence 페이지: 복잡한 흐름 결정, 기각된 방향 기록, 리서치 인사이트처럼 맥락이 필요한 내용이에요. 링크로 Figma와 연결해요.

Design System 문서: 컴포넌트가 왜 이렇게 생겼는지, 어떤 상황에 쓰고 어떤 상황에 쓰지 말아야 하는지를 기록해요. Storybook, Zeroheight 같은 도구가 여기에 쓰여요.

"시간이 없어서 문서화를 못 해요"라는 말은 절반만 맞아요.
실제 이유 중 하나는 "나중에 할게요"라고 미루다가 결정의 이유를 까먹는 거예요.
결정 직후 5분이 나중에 1시간보다 효율적이에요.

또 하나는 "무엇을 써야 하는지 모른다"예요. 그럴 땐 이 질문 세 가지를 기준으로 써보세요:

이 세 가지만 있어도 충분한 문서가 돼요.

문서화가 Design System에서 어떻게 작동하는지는 Design System 구축에서,
팀 전체 워크플로와 문서화의 관계는 Design Organization 운영에서 다뤄요.

Sarah Richards, 《Content Design》(2017) - 독자를 위한 문서 작성 원칙과 명확한 언어 선택 방법론이에요. 이 글의 "미래의 팀원을 위해 쓴다"는 관점의 근거예요.