디자인 시스템 구축기 3편
#Typography #프로젝트관리 #연말회고 #배운것
2편에서 이어지는 글이며 이전 회사에서 디자인 시스템을 구축했던 과정을 담고 있습니다.
1편 - 디자인 시스템을 만들기로 결심하고 피그마로 이사하기까지
2편 - 목표와 원칙, 정기 미팅, 모듈 시스템, 그리드, 컬러
3편 - 타이포그래피, 프로젝트 관리, 연말 회고, 구축 과정에서 배운 것
목차
1. Typography
2. Jira와 Confluence를 통한 프로젝트 관리
3. 프로젝트 연말 회고
4. 디자인 시스템 구축 과정에서 배운 것
1.
Typography
1) 폰트
현재 디자인 시스템은 Noto Sans를 사용하고 있다. 무료이고 다국어를 지원하며 준수한 가독성을 보여주기 때문이다. 아마 많은 웹과 앱 서비스가 이 폰트를 사용할 것이다. 그런데 몇 달 전, Pretendard라는 폰트가 나왔고 디자이너들 사이에서 화제가 되는 것 같아 관심을 갖고 살펴보았는데 아래 내용이 공감되어 폰트를 교체하는 것을 고려하게 되었다.
본문용 무료 글꼴의 대명사로 쓰이고 있는 Noto Sans KR—본고딕은, 그 글자를 조형하는 여러 사람들이 공통적으로 자간을 조정하는 데 시간을 쏟고 있다는 것과, 본고딕의 한글 크기가 대부분의 한글 글꼴과 비슷하게 다국어 타이포그래피 환경에서는 조금 크게 자리 잡아 라틴 글자와 섞어 쓸 때 글자 비율을 조정해서 쓰는 점이 제품을 만드는 데 어느 정도 부채가 쌓이는 상황... (중략)
Pretendard는 Noto Sans CJK의 완성도를 높이고 영문에는 Inter 폰트를 사용하였으며 기존에 없던 SemiBold, ExtraBold 등의 굵기가 추가되어 다양한 상황에 활용할 수 있다. 숫자 기호도 더욱 깔끔하게 표현되어 심미성과 가독성이 개선되었다. 게다가 터키어, 스페인어, 일본어, 이탈리아어 등 수십 가지의 다국어를 지원한다. 덕분에 시스템 폰트를 사용하던 우리 회사의 글로벌 서비스에 Pretendard를 사용함으로써 일관된 디자인을 제공할 수 있을 것으로 기대된다. (현재는 퇴사하여 폰트를 바꾸지 못해 아쉬움이 남는다.)
2) 사이즈
웹 접근성 권고사항에 따라 폰트의 최소 사이즈는 12px로 설정하고 본문 사이즈는 크롬, 사파리 등 웹 브라우저의 기본 폰트 사이즈로 많이 사용되는 16px로 설정했다. 또한 시각적 위계질서를 명확히 표현하기 위해 폰트 사이즈 간의 대비를 충분히 주고, 목적에 따라 다양한 크기를 사용할 수 있도록 설계했다.
가장 큰 폰트 사이즈는 50px로 웹사이트의 메인 페이지에서 방문자의 눈을 사로잡기 위한 용도로 사용할 수 있도록 했다. 제목으로 사용할 폰트의 사이즈는 위계에 따라 38px, 28px, 22px로 정의했는데, 화면이 작은 모바일에서는 동일한 사이즈를 사용할 경우 면적을 과도하게 차지하여 가독성을 저하시키므로 모바일 폰트 사이즈는 조금 작게 설정했다.
3) 굵기
폰트 굵기는 DemiLight, Medium, Bold를 사용하고 있다. 특수한 경우를 제외하면 UI의 시각적 위계질서를 표현하는 데에는 이 3가지 굵기로 충분하다. 다양한 굵기를 담을수록 앱의 용량이 커지니 꼭 필요한 굵기만 사용하는 것이 경제적이다. 참고로 Regular가 아닌 DemiLight를 사용하는 이유는 Regular의 굵기가 Medium과 눈에 띄게 차이 나지 않기 때문이다. 보통 텍스트를 강조하거나 분리하기 위해 다른 굵기를 사용하기 때문에 굵기 차이가 명확할수록 가독성이 높아진다고 판단했는데, 이건 폰트마다 다르므로 적절히 조정하면 된다.
4) 행간
행 사이의 간격을 적절히 조정하면 다음 행을 구별하기 쉽게 만들어준다. 일반적으로 행간은 글자 크기의 130~150% 정도가 이상적이라고 알려져 있다. 12~16px 정도의 본문은 140~150%를, 크기가 큰 Heading 계열은 120~130%의 비교적 작은 행간을 사용한다. 제목은 보통 한 줄에서 길어야 두 줄인데 행간이 넓으면 텍스트가 밀집되어 보이지 않아 제목으로써의 가독성이 떨어지기 때문이다. 폰트와 언어마다 다소 차이가 있을 수 있으니 적절히 조정하는 게 좋다.
5) 자간
글자 사이의 간격이 너무 좁거나 넓으면 글자가 겹쳐져 보이거나 불필요한 여백이 생겨 읽기 불편해진다. 폰트의 크기에 따라 자간을 적절히 조절하면 가독성이 향상되는데 이는 게슈탈트 이론 중 근접성의 원리와 관련 있다. 이 구축기에서 설명하고 있는 이전 회사의 디자인 시스템에서는 여러 테스트를 거쳐 Noto Sans와 피그마를 기준으로 마이너스 2~4%의 자간을 사용하고 있다.
6) 시멘틱 네이밍
구축 초기에는 폰트를 사이즈별로 이해하기 쉽도록 XL, L, M과 같은 형식을 사용하자는 의견이 있었다. 이 형식은 크기를 예상하기는 쉽지만 어떤 상황에서 사용해야 할지 알기 어렵다는 단점이 있다. 게다가 사용되는 모든 타이포그래피의 크기를 커버하려면 2XS부터 3XL까지 사용해야 했는데 마치 옷 사이즈를 고르는 것 같아 친숙하지만 사이즈 이름이 상대적이고 추상적이라 목적에 맞게 사용하기 어려웠다. 결국 시멘틱 네이밍을 사용하는 것으로 의견을 좁히고 Hero, Heading, Body, Caption을 사용하기로 결정했다. 시멘틱 네이밍의 구조는 다음과 같다.
시멘틱 네이밍 규칙여기서 숫자는 1(대제목), 2(중제목), 3(소제목)으로 표기하는데 디자이너와 개발자가 위계질서를 쉽게 이해할 수 있게 정한 규칙이다. 숫자가 아닌 Large, Medium을 붙이자는 의견도 있었는데, font-weight에 있는 Medium과 중복되고 네이밍이 길어지며 영문과 숫자를 함께 사용하는 것이 가독성이 더 좋다고 판단했다.
타이포그래피에 관심이 있고 더 자세히 알고 싶다면 아래 영상을 참고하길 바란다.
함께 타이포그래피 - 모바일 본문 타이포그래피 연구 (네이버)
2.
Jira와 Confluence를 통한
프로젝트 관리
1) Jira로 이슈 관리
이전 회사에서 프로덕트 디자이너로서 다양한 업무를 했고, 디자인 시스템은 사이드로 진행하는 프로젝트였다. 하지만 디자인 시스템 구축이 1년 이상 지속되었고 한 번 만들면 끝나는 것이 아니기 때문에 관련 작업을 보다 체계적으로 관리하기 위해서 디자인 시스템을 위한 Jira 프로젝트를 만들었다. 또한 디자이너뿐만 아니라 개발자도 함께 작업하는데 서로의 워크플로우가 다르기 때문에 이슈 타입을 분리하여 관리했다.
디자인 이슈
・Type: NewDesign, FixDesign
・Component: Design
・Workflow: Backlog → Designing → Ready to Develop → Closed/Rejected
개발 이슈
・Type: Bug, Task, Subtask, Improvement
・Component: Web, iOS, Android (컴포넌트별로 Swimlane 분리)
・Workflow: Backlog → Selected for Development → Resolved → Ready to Deploy/QA Failed → Closed/Rejected
2) Confluence로 문서 관리
다크 모드 대응을 위한 컬러 시스템 개편, Input 개선 등 다양한 디자인 시스템 작업이 진행되면서 플랫폼별 개발 현황을 파악하기 어려워 혼란이 생기고, 같은 질문을 여러 번 하게 되는 등의 소모적인 커뮤니케이션이 발생했다. 이를 해결하기 위해 디자인 시스템 현황 문서를 만들었고, 누구나 플랫폼별 개발 현황을 파악하고 관련 문서를 쉽게 찾을 수 있게 되었다.
3.
프로젝트
연말 회고
디자인 시스템 일부약 8개월의 시간 동안 파편화된 컴포넌트를 통합하고 버튼, 컬러, 타이포그래피 등 디자인 시스템에 필요한 요소들을 개발하며 많은 시행착오를 겪었고 정신없이 달려왔기 때문에 잠시 돌아보는 시간을 갖고자 2020년 12월에 연말 회고를 진행했다. 디자인팀과 개발팀, QA팀이 참석했고 몇 가지 컴포넌트에 대해 논의한 후 플랫폼별 개발 현황을 공유했다. Web, Android, iOS 모두 70% 이상 구축 완료된 상태였으며 디자인 시스템을 통해 좋아진 점과 개선해야 할 사항들에 대해서도 이야기를 나눴다. 아직 완전하지 않은 상태였기 때문인지 아쉬운 부분도 있어서 지속적으로 개선할 필요성을 느낀 자리였다.
좋아진 것
개발자
UI 개발 시간이 약 40% 단축되었다.
디자이너
모든 화면이 유기적으로 연결되어 관리가 편해졌다.
UI를 고민할 시간이 단축되고 문제 해결에 집중할 수 있는 시간이 늘어났다.
QA 매니저
QA를 할 때 디자인 시스템 컴포넌트로 구현된 화면은 확인하기 편해졌다.
아직 부족한 것
개발자
화면 전환에 대한 애니메이션 가이드도 있으면 좋겠다.
디자인 시스템이 일부만 적용되어 아직은 화면 간의 일관성이 떨어진다.
구축 단계의 과도기라 컴포넌트 동작 방식 등을 확인해야 하는 경우가 많았다.
4.
디자인 시스템
구축 과정에서 배운 것
디자이너, 개발자 등 다양한 구성원과 함께 디자인 시스템을 만들면서 디자인과 개발 양쪽에서 고려해야 할 사항이 얼마나 많은지, 그리고 구성원 간의 커뮤니케이션이 얼마나 중요한지 배웠다. iOS, Android, Web 간에 사용하는 기술 스택과 언어, 구현 방식이 달라서 맞춰가는 과정도 필요했지만 결국 이렇게 구축한 시스템이 장기적으로 얼마나 많은 시간을 절약해주고 효율적인 커뮤니케이션을 가능하게 하는지 체감할 수 있었다.
어려운 점도 있었는데 모두가 처음이다 보니 시행착오가 많았고, 각자 다른 업무도 있다 보니 디자인 시스템에 온전히 집중하기는 어려웠다. 그래서 프로젝트가 중간에 힘을 잃고 유야무야되지 않도록 개발자분들의 요청에 빠르게 대응하고 적극적으로 커뮤니케이션하면서 끝까지 가기 위해 노력했다. 그 결과, 약 2년 전에 디자인 시스템 구축을 처음 시작했을 때와 비교하면 현재 디자인 시스템의 완성도는 높은 수준을 갖추었으며 올해 초에 새로운 프로덕트를 디자인하고 개발하는 데에 큰 도움이 되었다.
이렇게 우여곡절을 겪으며 만들어온 디자인 시스템을 2월에 피그마 커뮤니티에 공개하려고 했었다. 유수의 기업들이 공개한 디자인 시스템에 비하면 별것 아닐 수도 있지만, 약 2년이라는 시간 동안 작은 규모의 조직에서 시행착오를 겪으며 만들어왔기 때문에 이제 막 디자인 시스템을 구축하려고 하는 스타트업이나 개인에게 하나의 사례로써 조금이나마 도움이 되고자 하는 마음이었다. 하지만 회사 측에서 내부 자산을 공개하는 것을 원하지 않았기 때문에 공개하지 못한 것은 조금 아쉬움이 남는다.
글을 쓰며 되돌아보니 부족한 점이 많이 보인다. 지금 회사에서는 디자인 시스템에만 집중하고 있다 보니 더욱 그런 것 같다. 인력이 적은 스타트업의 특성상 어쩔 수 없는 부분이라고 생각하고, 비슷한 환경에 놓인 분들에게 조금이나마 도움이 되었으면 좋겠다.
또한 디자인 시스템 구축기는 원래 4편까지로 계획했지만 구축기인 만큼 구축 과정에만 집중하고 Button, Input, Modal Dialog 등 UI 컴포넌트에 대한 이야기는 별도로 정리하는 게 좋을 것 같아 여기서 마무리한다.
끝.
