디자인 시스템과 기획 문서의 연결고리

디자인 시스템 이야기는 보통 디자이너들의 영역으로 여겨지는데, 저는 기획자로서 이 부분에 꽤 자주 발을 담그게 됐습니다.
PRD를 쓸 때마다 "이 화면에 쓸 버튼이 디자인 시스템에 있는 건가, 새로 만들어야 하는 건가"를 판단해야 하는 순간이 계속 생기더라고요.

이번 글에서는 기획 문서와 디자인 시스템을 어떻게 연결해서 관리하고 있는지 정리해보려 합니다.

 

예전에는 요구사항정의서에 "확인 버튼을 크게 배치한다" 같은 식으로 화면을 말로만 설명했습니다.
디자이너가 이걸 받아서 작업하다가 "이 버튼, 기존 시스템에 있는 Primary 버튼 쓰면 되나요, 새로 만들어야 하나요?"라고 물으면 저는 답을 못 했어요.
결국 디자이너가 임의로 판단해서 작업했다가, 나중에 다른 화면과 스타일이 안 맞아서 다시 고치는 일이 반복됐습니다.
이 문제를 겪으면서, 기획자도 최소한 디자인 시스템의 컴포넌트 목록 정도는 파악하고 있어야 한다는 걸 깨달았어요.

 

지금은 요구사항정의서의 사용자 플로우 섹션에 화면을 설명할 때, 가능하면 디자인 시스템의 컴포넌트 이름을 직접 언급합니다.
"확인 버튼(Primary Large)을 화면 하단에 고정 배치"처럼요.
이렇게 쓰면 디자이너가 새로 디자인할 부분과 기존 시스템을 그대로 쓸 부분을 바로 구분할 수 있습니다.
새 컴포넌트가 필요한 경우에는 요구사항정의서 에 "신규 컴포넌트 필요"라고 표시해두고, 디자인 시스템 담당자에게 미리 공유해서 일정에 반영할 수 있게 했어요.

 

기획 단계에서 새로운 UI 패턴이 필요하다고 판단되면, 바로 화면 디자인으로 넘어가지 않고 먼저 디자인 시스템 담당자와 짧은 리뷰를 하도록 프로세스를 만들었습니다.
"이거 기존 컴포넌트를 변형해서 쓸 수 있는지, 정말 새로 만들어야 하는지"를 먼저 판단받는 거예요.
저희 팀은 이 리뷰 없이 화면 디자인을 진행했다가, 나중에 비슷한 패턴이 서비스 곳곳에 제각각으로 생겨서 디자인 시스템이 누더기가 됐던 경험이 있었거든요.
이 프로세스를 넣고 나서부터는 새 컴포넌트가 생기는 속도가 줄었고, 대신 기존 컴포넌트의 재사용률이 확실히 올라갔습니다.

 

색상 코드나 spacing 값 같은 세부 토큰까지 기획자가 알 필요는 없다고 생각합니다.
다만 "이 화면은 어떤 상태(성공/경고/오류)를 표현해야 하는가" 정도는 기획 단계에서 명확히 해줘야 해요.
저는 요구사항정의서에 상태별 문구와 함께 "경고 상태로 표현"처럼 톤만 명시하고, 실제 색상이나 스타일은 디자이너가 시스템에 맞게 적용하도록 맡깁니다.
이 정도의 역할 분담이 되니까, 기획자가 디자인을 침해하지 않으면서도 필요한 정보는 충분히 전달할 수 있게 됐어요.

 

요구사항정의서와 디자인 시스템 문서가 따로 관리되면 시간이 지나면서 내용이 어긋나기 마련입니다.
저희는 요구사항정의서 에서 컴포넌트를 언급할 때 디자인 시스템 문서의 해당 페이지로 바로 링크를 걸어두는 걸 규칙으로 하고 있어요.
이렇게 하면 컴포넌트 스펙이 바뀌었을 때 요구사항정의서 를 열어봐도 최신 정보로 자동으로 연결되기 때문에, 옛날 스펙을 보고 개발자와 디자이너가 서로 다른 걸 참고하는 문제를 줄일 수 있었습니다.

디자인 시스템은 디자이너만의 자산이 아니라, 기획 문서가 얼마나 빠르고 정확하게 실제 화면으로 옮겨지는지를 결정하는 공통 언어라고 생각합니다.
기획자가 이 언어를 몰라도 일은 어떻게든 진행되지만, 알고 있으면 훨씬 적은 커뮤니케이션으로 같은 결과에 도달할 수 있더라고요.

저도 아직 디자인 시스템의 세세한 부분까지는 다 못 챙기지만, 적어도 요구사항정의서 를 쓸 때 컴포넌트 단위로 생각하는 습관은 확실히 자리 잡은 것 같습니다.