제품이 커지면 디자인 시스템 가이드는 어떻게 개선돼야 할까?
300명이 넘는 개발자와 디자이너를 위한 디자인 시스템을 4명의 디자이너가 운영하고 있어요. 이 과정에서 컴포넌트의 유려함뿐만 아니라, 가이드의 효율적인 제작도 중요함을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.
문제
컴포넌트를 개선하려고 할 때, 기존 가이드로는 동료 플랫폼 디자이너 및 개발자분들과 소통하기 어려웠어요. 컴포넌트 가이드 작성에 대한 규칙이 없으니 디자이너마다 작성된 방식이 제각기였고, 이 때문에 기존에 작성된 가이드를 읽는 데에도 컴포넌트를 온전히 파악하기 어려웠기 때문이에요.
기존 컴포넌트의 가이드에서 어떤 부분들이 문제였길래, 컴포넌트를 만드는데 메이커들이 어려움을 겪었을까요? 그리고 플랫폼 디자이너들은 이 문제들을 어떻게 해결했을까요?
해결책
가이드 읽는 방향성 정하기
기존에는 한눈에 스펙을 확인할 수 있도록 정사각형에 가까운 형태로 가이드를 배치했어요.
각 옵션이 한 눈에 보이고, 깔끔하게 정리된 가이드를 보며, 이 완벽한 가이드만 있으면 더 이상의 커뮤니케이션은 필요 없을 줄 알았어요. 하지만 개발자분들이 이미 가이드에 정의된 스펙을 보지 못한 채 따로 요청해주시기도 하고, 컴포넌트를 구현하면서 누락된 옵션들도 종종 나타났죠.
이유를 개발자와 이야기해보니 가이드를 어떤 순서로 읽어야 하는지 파악하기 어려웠다는 걸 알게 됐어요. 그래서 어떤 구조로 컴포넌트를 만들어야 하는지 이해하기 힘들었다고 하더라고요.
그래서 정보를 단순히 그룹핑만 하는 것이 아니라, 읽는 방식부터 누구나 같은 방향으로 읽을 수 있게끔 그룹핑된 가이드 내용을 위에서 아래로 흐르게끔 배치했어요.
이로써, 가이드를 어떤 순서로 읽어야 하는지 알기 쉬워졌고, 그 결과 컴포넌트의 스펙을 단계별로 쉽게 소화할 수 있게 됐어요.
큰 구조부터 자세한 요소로
가이드의 방향성을 정한 이후로 순서에 대해서 고민하고 있을 때, 때마침 컴포넌트 스펙맞추기 해커톤이 예정되어있었어요. 안드로이드 iOS, 웹 세 플랫폼이 모이는 시간에 저도 아예 옆에 앉아서 가이드는 어떻게 기록되어야 좋은 가이드가 될 수 있을지, 신속하게 피드백을 구하며 빠르게 의사결정을 해나갔어요.
그 과정에서 발견한 것은 개발도 그림을 그리듯이 큰 구조부터 자세한 요소로 진행된다는 점이었어요. 전체적인 스케치를 한 다음 묘사를 하는 것처럼요.
그래서, 토스트 컴포넌트 가이드에서는 가장 먼저 컴포넌트의 상위 옵션인 상단과 하단 타입을 보여주어 개발자가 구조를 이해할 수 있도록 하고, 그다음으로 각 타입에 포함된 요소들을 정리했어요. 마지막으로는 컴포넌트의 다양한 상태 변화(예를 들어 다크모드나 텍스트가 두 줄이 됐을 때)의 상세 스펙을 추가했어요.
이처럼 큰 옵션 정의부터 내부 변경될 수 있는 자세한 스펙들 순으로 점층적으로 가이드를 구성해 원하는 스펙을 찾아 방황할 필요 없이 효율적으로 가이드를 읽을 수 있게 했어요.
최악의 케이스 그리기
컴포넌트의 정보 위계가 생긴 것은 좋았지만, 그 정보 위계의 지도를 한 눈에 볼 수 없다는 점이 아쉬웠어요. 컴포넌트 안에도 다양한 요소들이 있어서, 어떤 요소는 쓰고 어떤 요소는 안 썼을 때 등등 굉장히 다양한 경우의 수가 있었거든요.
예를 들어 토스트에서 주로 쓰는 형태는 왼쪽이지만, 오른쪽처럼 버튼을 넣는 케이스도 있었어요.
이런 케이스를 하나하나 살펴볼 수 없으니, 오른쪽처럼 모든 요소를 최대한으로 썼을 때의 모습을 가이드의 제일 위에 첨부해두었어요. 모든 옵션을 다 사용한 사례를 먼저 보고 나면, 어떤 옵션이 있는지 전체적으로 지도를 그린 다음 하나씩 살펴볼 수 있으니까요.
접근성 영역 나누기
기존 가이드에선 접근성 스펙을 컴포넌트 레이아웃에 대한 설명할 때 포함하기도 하고, 별도의 페이지에 작성하기도 했어요. 그렇다 보니 ‘음! 새로운 A컴포넌트를 만들 땐 B컴포넌트의 접근성 가이드를 참고해야지! ‘라고 떠올리기 쉽지 않았어요. 그래서 접근성을 챙기기 위한 여러 가지 장치들을 새로운 컴포넌트를 설계할 때 참고하기 어려웠죠.
그래서 접근성에 대한 기존의 의사결정들을 비슷한 컴포넌트를 새롭게 설계할 때도 빠르게 참고할 수 있도록 선형으로 설계된 가이드에 가장 하단에 위치시키기로 약속했어요.
이를 통해서 디자이너가 가이드를 설계할 때 이 옵션을 의식적으로 챙길 수 있었고, 이러한 구조 변경으로 더 큰 텍스트 뿐만 아니라 보이스오버 사용성, 동작 줄이기와 같은 조건들을 조금씩 쌓아나갈 수 있었어요.
수십개의 컴포넌트 가이드에 적용하기
토스트, CTA, 리스트 등 여러 요소를 조합해 사용하는 대다수 컴포넌트는 앞서 정한 구성을 그대로 적용할 수 있게 했어요. 이를 위해, 큰 구조부터 시작해 타입, 영역, 상세 스펙, 더 큰 텍스트, 다크모드까지 포함하는 체크리스트를 정의했죠. 이 체크리스트를 바탕으로 가이드를 작성하도록 했어요. 타입이 나뉘어있지 않거나, 상세 스펙을 따로 정의할 필요가 없는 경우에는 생략했어요.
에셋, 버튼, 체크박스와 같은 아토믹 컴포넌트들은 구성요소가 단순해서 일반적인 컴포넌트 가이드와 비슷한 구조로 짜다 보면, 불필요한 정보를 넣게 되더라고요. 그래서 컴포넌트 자체의 특성에 맞게 뒤따라올 옵션들이 예측할 수 있게끔만 가이드를 구성했어요.
그리고 화면을 덮으며 나타나는 다이얼로그나, 바텀시트와 같은 컴포넌트들은 화면 안에서 어디에 위치해야 하는지에 대해 정의할 수 있도록 position이라는 항목을 체크리스트에 추가했어요.
또한 각 스펙을 가이드에 작성할 때는, 정확한 스타일 값과 결과물을 한 번에 볼 수 있도록 왼쪽에는 예시 이미지를 오른쪽에는 정확한 값을 꼭 작성하도록 했고, 이 작업을 최대한 효율화하기 위해 디자인 스펙을 표기하는 몇 가지 형태를 복붙해서 사용할 수 있도록 만들어두기도 했어요
결과
이러한 해결책들을 통해서 기존 가이드의 많은 문제의식을 해결할 수 있었어요.
가이드 작성에 대한 규칙이 없을때는 하나의 컴포넌트 가이드를 작성하는 데에만 일주일이 걸렸는데, 가이드 작성하는 규칙이 생긴 이후로는 컴포넌트 3개를 하루 만에 가이드를 작업할 수도 있었어요. 또한 팀에 새로 합류한 플랫폼 디자이너들이 기존 시스템을 빠르게 이해하고 바로 기여할 수 있었어요.
하지만 시스템이 성장하면서 가이드가 길어진 것들은 지금의 방식으로는 원하는 스펙을 찾아가기 힘들어져, 구조에 맞게 가이드를 끊거나 목차를 만드는 등의 새로운 방식들을 고민하고 있어요.
앞으로 시스템의 규모가 성장함에 따라 기존 가이드를 개선했던 것처럼 팀원들과 함께 논의해가며 가이드를 개선해 나가려고 해요.