한 걸음 더 나아가기
안녕하세요. 밀리의 서재 디자인 파트입니다.
작년 millie Design System(이하 밀디라)을 피그마와 브런치를 통해 공개한 이후 큰 관심을 받았습니다. 작년에 진행했던 밀디라 프로젝트는 잘 마무리되었지만, 모든 프로젝트가 그러하듯 아쉬운 점과 해결해야 할 문제점이 남아있었습니다.
특히 디자인 시스템은 많은 사람들이 함께 만들어나가는 것이기에 더 날카롭고 정확한 개선을 필요로 합니다. 그래서 저희 디자인 파트는 올해 4월에 밀디라의 문제점을 해결하고 더 실용적인 시스템으로 만들기 위해 2차 프로젝트를 진행하였습니다. 오늘은 그 과정과 이를 통해 배운 인사이트를 공유하려 합니다.
말을 꺼낸 자가 책임을 져야 하는 법. 개선을 강력히 주장한 디자이너 Sally가 프로젝트의 리더를 맡았습니다. 그리고 디자이너 Jenna와 Tasha, 웹 개발자 Ray까지 총 4명이 함께하게 되었습니다. 사실 더 많은 개발자 구성원을 모으기 위해 기획 리뷰를 진행했었습니다. 하지만 안타깝게도 앱 개발자의 리소스가 부족한 탓에 방향성을 조율할 수밖에 없었습니다. 최종적으로 ‘웹을 우선 구축하자’는 결정을 했고 극소수 정예 멤버로 프로젝트를 세팅하게 되었습니다.
우선 밀디라를 사용하면서 겪은 문제점들을 파악하였습니다.
다양한 상황에 대한 대응이나 가이드가 부족하여 컴포넌트 수정이 일어남
피그마 내에서 UI KIT 정도의 역할만 함
디자이너만의 약속으로 남음
파악한 문제점을 기반으로 해결방안을 도출하고 크게 3가지 목표를 설정하였습니다.
더 구체적인 체계와 가이드를 설계할 것
개발자도 코드를 재사용할 수 있도록 스토리북을 구축할 것
기획, 디자인, 개발 직군 모두의 약속이 될 수 있도록 전파하여 원활한 커뮤니케이션을 할 것
프로젝트 멤버들이 비즈니스 우선순위가 높은 업무에 각자 투입되어 있었기 때문에 디자인 시스템 프로젝트가 그에 밀려 흐지부지 되지 않도록 다음과 같은 장치를 두었습니다.
멤버들의 프로젝트 오너쉽을 위해 매주 정기 미팅 진행
참여자가 아닌 디자이너도 이해도를 높이기 위해 정기 미팅 참석
배포 후 관련 인원들에게 시스템 전파 및 교육
요소들의 업데이트를 위해 시스템을 열어보고 가장 먼저 든 생각이 단위 분류였습니다. 두서없이 나열되어 있었기에 그룹핑해주는 것이 매우 중요하다고 생각했기 때문입니다. 저희는 요소의 형태에 따라 Foundation / Component / Template / Brand Identity 총 4가지로 단위를 분류하여 구조를 만들었습니다.
Foundation : 가장 기본이 되는 단위를 뜻합니다.
Component : 재사용이 가능한 단위를 뜻하며, Foundation의 조합입니다.
Template : Foundation과 Component을 구성하여 만든 조합이며, 목적을 가지고 있습니다.
Brand Identity : 밀리의 서재 브랜드 자산 모음입니다.
저희는 디자인 언어와 개발 언어의 간극을 줄이는 것을 그 다음 숙제로 가져갔습니다. 같은 컴포넌트이지만 직군에 따라 다르게 부르던 이름을 통일하는 작업을 하기로 했습니다. 가장 많이 쓰는 동시에 타입이 많은 버튼과 아이콘의 네이밍 규칙을 설정했습니다.
텍스트를 더블 클릭하면 '_(언더바)'로 묶인 텍스트는 한 번에 선택되고, '-(대시)'로 묶인 텍스트는 따로 선택하기 좋습니다. 그래서 언더바는 같은 범위 내에서 띄어쓰기의 개념으로, 대시는 다른 범위를 구분 짓는 용도로 이름 지었습니다.
버튼 네이밍 가이드
- 영문(소문자), 숫자로만 표기
- dash와 underbar로 구분하여 표기
- 구분은 dash(-)
- 띄어쓰기는 underbar(_)
- component만 모음을 탈락시켜 약어로 표기 (단, 이해되는 선에서 적용)
- ex) icon ➡️ icn / background ➡️ bg / image ➡️ img / button ➡️ btn
- ex) field / logo
- type은 한 단어로 떨어지는 단일어를 사용하되, 두 단어 이상의 복합어는 underbar로 연결하여 표기
- essential은 필수 값으로 빠짐없이 표기
- flexible은 가변 값으로 해당되는 경우에만 표기
아이콘 네이밍 가이드
- 영문(소문자), 숫자로만 표기
- dash와 underbar로 구분하여 표기
- 구분은 dash(-)
- 띄어쓰기는 underbar(_)
- 약어는 권장하지 않음
- name은 한 단어로 떨어지는 단일어를 사용하되, 두 단어 이상의 복합어는 underbar로 연결하여 표기
- type은 동일한 name을 가진 아이콘을 구분하는 목적으로 사용
- ex) arrow_left / arrow_right / arrow_top / arrow_bottom
- essential은 필수 값으로 빠짐없이 표기
- flexible은 가변 값으로 해당되는 경우에만 표기
시스템에 분류된 각 컴포넌트마다 자세한 디자인 가이드와 정책을 작성하기로 했습니다. 컨플루언스나 노션 등 문서 작성에 용이한 서비스를 사용할까 고민했습니다. 하지만 실제로 작업할 때 피그마와 스토리북을 확인하는 것만으로도 버겁다는 판단을 내렸고, 플랫폼이 다양할수록 업데이트 및 관리가 용이하지 않다고 생각했습니다. 그래서 디자인 시스템 피그마 안에 가이드를 작성하여 컴포넌트와 통합 관리하기로 결정했습니다.
개발 코드는 스토리북에서 업데이트 및 관리하고 있습니다. 개발 가이드는 프로젝트의 원앤온리 개발자 Ray의 주도하에 관리되고 있습니다.
색상을 디자인 시스템에 포함시킬 때 팔레트와 토큰을 정의하는 것이 필요했습니다. 이전의 디자인 시스템에서는 그 두 개념의 차이를 완전히 구분하지 못하고 사용했습니다. 팔레트만으로는 토큰을 대체할 수 없습니다. 팔레트만 정의해서 사용했을 때의 한계가 토큰을 정의하고 나니 해소되었습니다. 토큰이란 컬러뿐만 아니라 디자인 시스템 내의 모든 값에 '이름'과 함께 정의된 요소입니다.
밀리의 서재에서는 디자이너가 떠올리기 쉬운 이름일 수 있도록 컬러 토큰을 정의했습니다. 이전 버전의 디자인 시스템에서 어떤 컬러를 중요도가 두 번째인 텍스트에를 적용했는지 기억해내기가 쉽지 않다는 사실을 배웠기 때문입니다. '$ui-'로 정리한 ui의 선/배경 요소와 관련된 컬러 토큰, '$text-'로 정리한 텍스트 관련 토큰, 그리고 '$audio', '$chatbook', '$error', '$sucess'등 의미론적 토큰을 다양하게 정의했습니다.
$ui-08과 $text-02의 컬러 팔레트는 Gray-11로 같습니다만, 그 토큰은 같은 것이 아닙니다. 버전 1에는 이런 개념이 없었습니다. 그래서 일관성 있게 사용하려면 Gray-11이 사용된 곳이 어디인지 기억력을 많이 발휘했어야 했는데요, 지금의 디자인 시스템을 사용하면서는 일관적인 사용이 한결 수월해졌습니다.
밀리의 서재는 아직 다크 모드 전면 적용이 되지 않았지만, 책을 읽는 뷰어 화면에서는 다크 테마를 제공합니다. 뷰어를 기준으로 다크 모드 컬러 토큰을 정의했습니다. 뷰어를 기준으로 정의한 1쌍의 토큰을 실제 UI에 적용시켜보며 다듬었습니다.
아이콘을 폰트로 만들 때에는 복잡한 형태의 SVG는 일러스트레이터로 정리하고 Compound Path를 다시 재정의하여 *.svg 파일로 만들어야 패스 오류가 나지 않고 폰트화가 됩니다. 이런 복잡한 과정을 거쳐야 했기에 폰트로 제작된 아이콘은 빈번하게 쓰이면서도 단순하게 생긴 아이콘들입니다.
폰트로 만든 아이콘은 잊지 않고 따로 모아 두고, 변경한 네이밍도 기록해둡니다. 'icon-name_name-24_1'과 같이 아이콘의 긴 이름이 코드에 사용되면 가독성이 떨어지기 때문에 폰트로 만들 때는 아이콘의 이름을 최대한 단순하게 만들었습니다. 누구나 폰트화 할 수 있도록 최신 파일, 컨버팅 방법, 협업의 과정도 기록해두었습니다. 이게 시스템의 존재 이유니까요.
7월 말에 프로젝트를 성공적으로 마무리했습니다.
주 4일과 셧다운 등의 휴식 기간과 함께 멤버들이 우선순위가 높은 프로젝트에 투입되는 경우가 발생하여 예상 일정보다 조금 밀리게 되었지만, 실질적으론 2개월 반이라는 시간을 소요하며 매우 퀵하게 프로젝트를 진행했습니다. 저희는 결과물을 만드는데 그치지 않고 기존 개발자들에게 전파 및 신규 입사자 교육을 통해 밀디라 사용을 장려했습니다. 5개월이 지난 지금도 밀디라를 적극 사용하고 있으며, 새로 입사한 앱 개발자분들이 앱도 구축하자고 먼저 제안을 주기도 했습니다. 이번 프로젝트를 통해 밀디라가 허울만 좋은 시스템이 아닌 디자이너와 개발자에게 실질적으로 도움이 되는 시스템으로 거듭난 셈입니다. 이제 “텍스트 필드 포커스 상태는 어떻게 보여주나요?”, “액션 시트를 PC에선 어떻게 대응하죠?” 등의 질문을 받을 때 저희의 대답이 하나가 되었습니다. “밀디라 보시면 있어요!”
아, 그리고 이건 TMI인데 ‘이 달의 밀리’ 평가에서 100% 성과 달성으로 인정받았어요. 보상도 있었답니다. 이번 프로젝트 역시 이전의 것을 개선하는 작업이었지만, 디자인 시스템을 개선할수록 완전한 끝은 없다는 걸 배우고 있습니다. 그래서 손 발이 척척 맞아 서로 디자인 시스템을 생명력 있게 가꾸고 서비스에 적용시켜나가는 동료들이 있다는 게 얼마나 감사한 일인지 더 크게 다가옵니다. 프로젝트 멤버들의 회고로 이 글을 마무리 짓고자 합니다.
Sally
시스템 구축이 쉬운 일이 아니다 보니 사서 고민한 부분이 많았습니다. 타사의 디자인 시스템을 보면 볼수록 정의한 기준이 다 달라서 혼란에 빠졌습니다. 이렇게 제가 갈피를 못 잡을 때 멤버들이 말해주더라고요. 우리가 만들고 우리가 사용하니 우리가 내린 결정이 맞다고. 덕분에 깨달았습니다. 정답은 없다는 걸요! 덕분에 오롯이 저희의 실사용성에 집중할 수 있었습니다. 함께 할 수 있어서 영광이었어요.
Tasha
밀리의 서재에 입사 후 밀디라 1.0을 잘 활용해서 적응한 디자이너로서 일관성 있고 효율적인 작업 환경을 만드는 멋진 프로젝트에 함께 참여할 수 있어서 즐거웠습니다. 긍정적인 마인드로 함께해 준 팀원분들 감사하고 고생하셨습니다! 여기서 멈추지 않고 계속해서 밀리의 디자인 시스템을 고도화하는 작업이 기대됩니다.
Jenna
이전 UI KIT 수준의 디자인 시스템도 디자이너로서는 사용하기 괜찮았지만, 개발자분들이 똑같은 것을 개인마다 다르게 여러 번 만드는 모습을 보는 건 이래저래 마음이 편치 않았습니다. 디자인 시스템을 코드화하고 나서 그 부분이 가장 만족스럽습니다. 시스템을 만드는 과정에는 커뮤니케이션, 일관성, 실용성, 지속성, 편의성 등 생각해야 할 제약사항이 굉장히 많다는 걸 알게 되었고 해결하는 방법을 찾을 때마다 경험의 범위가 확장되는 느낌이 좋았어요. 혼자 힘으로는 절대 못했을 텐데 팀이란 게 이런 거구나 다시 한번 느꼈습니다.
Ray
초기 설계부터 한참 고민했는데도 어려워서 많이 헤맸어요. 그래도 하나 둘 완성되어 갈수록 활용 능력이 한층 업그레이드되는 것 같아 뿌듯했습니다. 함께해주신 모든 분들께 축복을!
Designing a Dark Mode for your iOS app — The Ultimate Guide!
밀리 디자인 라이브러리는 피그마 커뮤니티에 공개되어 있으며 언제든지 보실 수 있습니다.