5주차 1일 - 제품이 커지면 디자인 시스템 가이드는 어떻게 개선돼야 할까?
문제
기존 가이드로는 동료 플랫폼 디자이너 및 개발자분들과 소통하기 어려웠어요.
컴포넌트 가이드 작성에 대한 규칙이 없으니 디자이너마다 작성된 방식이 제각각 이였다
기존에 작성된 가이드를 읽는 데에도 컴포넌트를 온전히 파악하기 어렵다
해결책
가이드 읽는 방향성 정하기
기존에는 한눈에 스펙을 확인할 수 있도록 정사각형에 가까운 형태로 가이드를 배치
이유를 개발자와 이야기해 보니 가이드를 어떤 순서로 읽어야 하는지 파악하기 어려웠다는 걸 알게 됐었고 어떤 구조로 컴포넌트를 만들어야 하는지 이해하기 힘듦
큰 구조부터 자세한 요소로
가이드의 방향성을 정한 이후로 순서에 대해서 고민하고 있을 때, 때마침 컴포넌트 스펙 맞추기 해커톤이 예정되어 있었어요. 안드로이드 iOS, 웹 세 플랫폼이 모이는 시간에 저도 아예 옆에 앉아서 가이드는 어떻게 기록되어야 좋은 가이드가 될 수 있을지, 신속하게 피드백을 구하며 빠르게 의사결정을 해나갔어요.
그 과정에서 발견한 것은 개발도 그림을 그리듯이 큰 구조부터 자세한 요소로 진행된다는 점이었어요. 전체적인 스케치를 한 다음 묘사를 하는 것처럼요.
그래서, 토스트 컴포넌트 가이드에서는 가장 먼저 컴포넌트의 상위 옵션인 상단과 하단 타입을 보여주어 개발자가 구조를 이해할 수 있도록 하고, 그다음으로 각 타입에 포함된 요소들을 정리했어요. 마지막으로는 컴포넌트의 다양한 상태 변화(예를 들어 다크모드나 텍스트가 두 줄이 됐을 때)의 상세 스펙을 추가했어요.
이처럼 큰 옵션 정의부터 내부 변경될 수 있는 자세한 스펙들 순으로 점층적으로 가이드를 구성해 원하는 스펙을 찾아 방황할 필요 없이 효율적으로 가이드를 읽을 수 있게 했어요.
최악의 케이스 그리기
컴포넌트의 정보 위계가 생긴 것은 좋았지만, 그 정보 위계의 지도를 한눈에 볼 수 없다는 점이 아쉬웠어요. 컴포넌트 안에도 다양한 요소들이 있어서, 어떤 요소는 쓰고 어떤 요소는 안 썼을 때 등등 굉장히 다양한 경우의 수가 있었거든요.
예를 들어 토스트에서 주로 쓰는 형태는 왼쪽이지만, 오른쪽처럼 버튼을 넣는 케이스도 있었어요.
접근성 영역 나누기
기존 가이드에선 접근성 스펙을 컴포넌트 레이아웃에 대한 설명할 때 포함하기도 하고, 별도의 페이지에 작성하기도 했어요. 그렇다 보니 ‘음! 새로운 A컴포넌트를 만들 땐 B컴포넌트의 접근성 가이드를 참고해야지! ‘라고 떠올리기 쉽지 않았어요. 그래서 접근성을 챙기기 위한 여러 가지 장치들을 새로운 컴포넌트를 설계할 때 참고하기 어려웠죠.
그래서 접근성에 대한 기존의 의사결정들을 비슷한 컴포넌트를 새롭게 설계할 때도 빠르게 참고할 수 있도록 선형으로 설계된 가이드에 가장 하단에 위치시키기로 약속했어요.
수십 개의 컴포넌트 가이드에 적용하기
토스트, CTA, 리스트 등 여러 요소를 조합해 사용하는 대다수 컴포넌트는 앞서 정한 구성을 그대로 적용할 수 있게 했어요. 이를 위해, 큰 구조부터 시작해 타입, 영역, 상세 스펙, 더 큰 텍스트, 다크모드까지 포함하는 체크리스트를 정의했죠. 이 체크리스트를 바탕으로 가이드를 작성하도록 했어요. 타입이 나뉘어있지 않거나, 상세 스펙을 따로 정의할 필요가 없는 경우에는 생략했어요.
인사이트
알게 된 점
제품이 커짐에 따라 기존에 가이드로는 소통하기 각 어려웠다는 점이고 다른 하나는 컴포넌트를 파악하기가 어렵다는 점을 알게 되었다
좋았던 점
시스템가이드에 대해 궁금했는데 한눈에 스펙을 확인할 수 있도록 정사각형에 가까운 형태로 가이드를 배치 점이고 접근성 영역 나누기 등에 대해서 알 수 있어서 좋았다.
아쉬웠던 점
없음