테마를 쉽게 변경하는 디자인 토큰 기반의 디자인 시스템
한 번에 완벽히 구축할 수 없으면 수정이라도 용이하게 만들자
목차
- 디자인 시스템에서 고려해야 할 5가지 요건
- 디자인 토큰의 개념
- 피그마에서 디자인 토큰으로 룩앤필 쉽게 변경하기 (테스트)
새로운 도메인 서비스를 기획하게 되면서 디자인 시스템도 새로 만들게 되었다. 현재 작업 중인 서비스뿐만 아니라 아직 통일된 디자인이 적용되지 않은 다른 서비스도 있었기 때문에 여러 서비스에 모두 적용할 수 있는 시스템을 만들기로 했다.
시간 낭비하는 것을 싫어하기 때문에 어차피 해야 한다면 제대로 해보고 싶었다. 디자인 시스템을 참고할 서비스는 많지만 그대로 답습해봤자 배우는 것이 많지 않을 것 같아서 왜 해야 하는지에 집중해서 나만의 논리로 정리를 해보기로 했다. 그렇게 새로운 디자인 시스템에서 충족해야 할 요건들을 정리해나갔다. 기존의 디자인 시스템도 어느 정도의 통일성을 보장하기는 했지만, 서비스가 점차 확장되면서 개선해야 할 부분들이 조금씩 느껴지고 있어서 이참에 모두 고려해서 작업을 해보기로 했다.
디자인 시스템에서 고려해야 할 요건
1) 통일성
2) 브랜드 확장성
3) 수정 용이성
4) 접근성
5) 협업
1) 통일성
통일성에는 두 가지 종류가 있는 것 같다. 첫 번째는 디자인 시스템 자체의 통일성(디자인의 통일성)이고, 두 번째는 실제 서비스에 적용된 상태의 통일성(적용의 통일성)이다.
색상이나 타이포그래피 같은 기본적인 디자인 요소들과 컴포넌트 UI가 잘 정리되어 있다고 하더라도 디자이너나 개발자 간의 소통이 되지 않아서 서비스에 우후죽순으로 적용된다면 결국 고객은 하나의 브랜드에서 일관된 경험을 얻지 못하게 된다. 디자인 시스템은 서비스에 '잘 사용되어야' 의미가 있는 법이다.
디자인의 통일성 예시 - 인터랙션 방식
Goldman Sacks의 디자인 시스템은 상호작용 방식을 아래와 같이 규정하고 있다. Hover(마우스를 UI에 올리는) 상태는 기본 상태의 색상에서 위계가 2단계 높은 색상에 투명도 20%를 적용하여 상위 레이어로 오버레이 하는 방식이다.
이런 기준이 있다면 새로운 UI를 추가할 일이 생겨서 컴포넌트를 정리할 때 Hover 상태를 어떻게 디자인해야 할지 고민할 필요가 없다. 만약 기준이 없다면 어떤 컴포넌트는 Hover 효과가 없거나, 있어도 위계 차이가 너무 심하거나, 또는 위계 차이가 전혀 구분되지 않거나 등 서로 다른 방식으로 작동하게 될 것이다. 기준을 세우면 통일된 경험을 제공할 수 있기 때문에 고객 경험도 좋아진다. 뿐만 아니라 작업할 때 고민을 줄여주기 때문에 디자이너의 작업 효율성도 좋아진다.
구글 Matierl design 역시 아래와 같은 상호작용 상태를 정의하고 있다. 상태 표현은 on-color(배경 위에 표시된 텍스트 또는 아이콘 색상) 색상을 사용하여 각 상태(Hover, Focus, Press, Drag)에 따라서 불투명도를 적용한 레이어를 위에 올려 사용한다.
적용의 통일성 - 사용 방법
제대로 된 디자인 시스템은 단순히 UI만 나열하고 끝나지 않는다. 재료가 있어도 만드는 방식이 다르면 전혀 다른 요리가 나올 수 있다. 같은 재료를 사용하여 같은 맛의 요리를 만들 수 있는 레시피처럼 디자인 시스템도 잘 작동하기 위해서는 UI의 사용 목적을 명확하게 설명해야 한다.
Elastic 디자인 시스템의 경우 버튼의 위계에 따른 사용 목적을 명확하게 설명하고 있으며, 그래픽 이미지 예시를 들어서 Do와 Don't를 구체적으로 안내하고 있다.
ex. 하나의 레이아웃에 주요 버튼은 1개여야 한다.
2) 브랜드 확장성
새 디자인 시스템은 신규 도메인의 서비스에만 적용되는 것이 아니라 다른 서비스의 페이지에도 같이 사용할 예정이었다. 하나의 스타일로 정의된 컴포넌트를 사용해도 됐지만, 어차피 만들어야 한다면 브랜드에 따라 각 브랜드가 추구하는 감성을 주고 싶었다.
이전에 회사에서 A 브랜드에 B 브랜드를 연동하는 작업이 있었다. 당연히 두 브랜드의 디자인 시스템은 차이가 있었기 때문에 한 화면에 서로 다른 스타일이 존재하게 되었다. 그래도 색상은 변수로 사용해서 A 브랜드에 맞춰서 통일된 색상으로 제공할 수 있었지만, Border-radius(모서리 둥글기)와 같은 색상이 아닌 디자인 속성들은 다르게 적용될 수밖에 없었다.
같은 화면에서 서로 다른 도메인의 서비스가 사용 됨
Border-radius(모서리 둥글기)나 Box-shadow(그림자)와 같은 색상 외적인 부분에서 다소 차이가 있음사실 색상 통일로도 충분하기는 했지만(일반 고객들은 별로 신경 쓰지 않을 부분일 수도 있다) 아무래도 디자이너다 보니 디테일한 부분이 신경 쓰였다. 색상처럼 다른 디자인 요소들도 변수로 사용해서 쉽게 스타일을 바꿔서 사용할 수 있으면 좋을 것 같다는 생각이 들었다. A 브랜드와 B 브랜드의 디자인 시스템이 다르더라도 특정 브랜드의 스타일 정책을 적용할 수 있도록 유연하게 변경할 수 있었으면 했다.
3) 수정 용이성
프로덕트는 항상 변한다. 고객의 니즈가 달라질 수도 있고 회사에서 집중하는 프로젝트나 철학이 달라질 수도 있다. 또는 기존에 따르던 프로세스가 비효율적이라는 것을 깨달아서 개선할 수도 있다. 기준을 정하지 않으면 어떤 기능과 UI가 어떤 페이지나 플로우에 사용되었는지 확실하게 파악할 수가 없고, 무언가 수정해야 할 때 어디부터 손을 대야 할지 막막할 수 있다.
수정이 필요할 때마다 모든 페이지를 하나씩 뜯어보면서 수정할 것들을 리스트업하고, 개발자도 하드 코딩된 UI를 하나씩 수정하는 것은 굉장히 비효율적이고 인력 낭비라고 생각한다. 나중에 불필요한 노가다 작업을 하지 않기 위해서는 처음부터 쉽게 수정할 수 있도록 구축하고 싶었다.
4) 접근성
개인적인 기준이 아니라 더 많은 고객에게 쾌적한 경험을 주기 위하여 사회에서 통용되는 기준으로 작업을 하고 싶었다. 단순히 예쁜 디자인이 아니라 논리적인 설계를 하고 싶었기 때문에 접근성에 기반한 디자인 시스템을 만들기로 했다. 접근성에서 가장 중요한 것은 가독성이다. 그리고 가독성을 위해서는 색상과 크기가 제대로 설계되어 있어야 한다. 색상과 크기에 관련해서는 이전에 살짝 글을 작성한 적이 있었다.
색상
디자인 시스템에서 빠지지 않는 것은 바로 색상이다. 거의 모든 디자인 시스템에는 주요 색상이 팔레트로 구성되어 있다. 그러나 단순히 색상을 나열한 것인지 명확한 기준을 설정하여 구성한 것인지는 디자인에서 나타나는 것 같다. 색상은 결국 사람들에게 정보의 위계를 나누기 위한 용도로 사용되기 때문에 가장 중요한 것은 접근성에 대한 고려라고 생각한다. 정보는 제대로 인지되어야 한다.
https://dribbble.com/shots/3860984-Colorful-Tags-With-Icon-WIP위 UI를 보면 색상 정책이 제대로 설정되지 않았다는 생각이 든다. 알록달록한 색상에서 채도를 빼면 아래처럼 변한다. 노란색은 다른 색에 비하여 잘 보이지 않는다는 것을 확인할 수 있다. 딱 봐도 웹 접근성 기준에 한참 미달할 것 같은 위계다. 위 UI를 사용하여 노란색 뱃지로 정보가 전달될 때는 다른 색상의 뱃지보다 더 주의를 기울여서 봐야 할 것 같다.
Dell의 뱃지 컴포넌트다.
https://www.delldesignsystem.com/components/badge/?tab=Design색상을 빼고 보면 가독성이 거의 균일하다는 것을 확인할 수 있다. (Heavy에서 다소 균일하지 않은 것은 살짝 아쉽다) 물론 색상의 특성에 따라서 완벽히 동일하지는 않고 다소 차이가 있기는 하지만 정보를 확인하는 데에는 무리가 없다. 이처럼 디자인 시스템이 통일성 있게 작동하기 위해서는 기준이 중요하다.
접근성 디자인 가이드
아틀라시안의 디자인 시스템에서는 색상만으로 시각적 신호를 사용하지 말라고 가이드를 하고 있다.
색상만 사용하여 정보를 전달하지 마십시오. 모든 사람이 동일한 정보를 받을 수 있도록 획 두께, 패턴, 모양, 텍스트 또는 그림과 같은 여러 시각적 신호를 사용합니다. 이것은 한 색상을 다른 색상과 구별할 수 없거나 구별하는 데 어려움이 있는 사람들에게 도움이 됩니다. 여기에는 색맹, 저시력 또는 맹인이 포함됩니다.
예를 들어 이러한 인라인 유효성 검사 메시지는 색상과 아이콘을 모두 사용하여 심각도를 구분합니다.
https://atlassian.design/foundations/accessibility이처럼 신체적인 조건과 상관없이 정보를 제대로 전달하기 위해서는 다양한 요인들을 고려하여 디자인에 반영해야 한다.
5) 협업
1번에서 이야기했던 통일성과 연관이 있는 부분이다. 디자인 시스템은 결국 서비스에 적용이 되어야 의미가 있다. 아무리 UI를 잘 정리해두더라도 서로 소통이 되지 않고 어떻게 사용해야 하는지 이해할 수 없어서 제대로 사용되지 않는다면 무용지물이다. 협업을 위해서 디자인 시스템은 단순히 비주얼적인 통일성만 충족되면 안 된다. 명칭이 명확해서 언제 어디에서 사용되는지 직관적으로 이해되어야 하고, 새로운 컴포넌트를 추가할 때 누구나 큰 고민 없이 통일된 작동 방식에 따라서 추가할 수 있어야 한다.
https://designsystem.line.me/LDSG/foundation/overview-en라인은 Foundation 디자인 토큰(아래에서 이야기하겠지만 디자인 변수 개념)의 네이밍을 위와 같이 규정하고 있다. 이렇게 기준을 세워두면 어떤 브랜드의 어떤 시각적 요소의 토큰인지 보다 쉽게 이해할 수 있다.
그래서 어떻게 작업해야 할까?
디자인 시스템을 정리하면서 가능하면 쉽게 협업할 수 있게 생각하면서 작업할 예정이지만 처음부터 모든 것을 고려하여 작업하는 데에는 무리가 있을 것 같기도 하다. 다른 중요한 이슈도 있어서 디자인 시스템만 세월아 네월아 작업할 상황이 아니었다. 그래서 처음에 제대로 구축할 수 없다면 수정이라도 쉽게 할 수 있도록 설계를 해보기로 했다.
이렇게 새로운 디자인 시스템을 만들면서 중요하게 고려할 5가지 항목을 나누어서 적어보았다. 이 다섯 가지 항목인 통일성, 수정 용이성, 브랜드 확장성, 접근성, 협업은 따로 작동하는 것이 아니라 서로 밀접하게 맞물려있다. 통일성 있게 정리가 되고 수정을 쉽게 할 수 있어야 협업도 편해지는 것처럼.
디자인 토큰
통일성과 협업은 디자인 시스템을 설계하고 실제 서비스에 적용하는 모든 과정에서 계속 고려해야 할 사항이었기 때문에 일단 초반에는 수정 용이성과 브랜드 확장성, 접근성을 고려하여 디자인 시스템을 정리하기로 했다. 그렇게 디자인 시스템에 관련된 사례를 많이 찾아보다가 디자인 토큰 개념을 발견했다.
https://www.newline.co/courses/newline-guide-to-react-component-design-systems-with-figmagic/design-1) 디자인 토큰은 변수?
디자인 토큰을 간단하게 설명하자면, 색상과 타이포그래피, 간격, 크기 등 기본 단위의 디자인 속성을 재사용할 수 있는 변수로 정리하여 사용하는 방식이다. 디자인 토큰을 사용하면 수동 작업을 줄이고 쉽게 수정할 수 있다. 또한 필요할 경우 더 큰 범위로 확장할 수 있기 때문에 작업의 효율성이 높아진다.
일단 다른 것보다 수정이 쉽다는 측면에서 디자인 토큰을 사용해야겠다고 생각했다. 처음부터 완벽한 시스템을 만들 수 없다는 것을 알고 있었기 때문에 발을 잘못 들이더라도 쉽게 변경할 수 있도록 구축해놓으면 처음부터 다시 작업하는 시간 낭비를 줄일 수 있을 것 같았다.
한편 디자인 토큰은 변수 그 이상의 의미가 있다고도 했지만, 아직 학습이 충분하지 않아서 거기까지 공감하지는 못했기 때문에 일단 모든 디자인 속성을 변수로 사용한다고 이해하고 있다. 변수개념은 대부분 이해하고 있듯이 특정 값에 이름을 붙여서 저장해두고 사용하는 방식이다.
위처럼 특정 색상(#7E84FC)을 color-primary(보통 브랜드 메인 색상)라는 변수로 지정을 해두면 코딩할 때 HEX나 RGBA 값이 아니라 변수 이름을 사용하여 스타일을 지정할 수 있다. 디자이너와 개발자가 소통할 때도 '#7E84FC'로 전달하면 직관적으로 이해할 수 없지만 ‘color-primary’라고 전달한다면 브랜드 색상이라는 것을 쉽게 이해할 수 있게 된다.
사실 디자인 작업을 할 때는 변수의 이점을 크게 느끼지 못할 수 있다. 오히려 디자인 토큰을 일일이 찾아서 사용해야 하는 것이 번거롭게 느껴질 수도 있다. 하지만 나중에 브랜드 색상이 바뀐다거나 서비스 전반적으로 룩앤필의 변화를 준다고 했을 때 변수로 지정되어 있지 않으면 페이지와 각 기능을 하나씩 찾아서 수작업으로 변경을 해줘야 한다. 하지만 변수로 되어 있다면 다른 UI나 페이지를 볼 필요도 없이 변수의 값을 바꿔주기만 하면 된다.
--color-primary에 저장된 hex값만 바꿔주면 해당 변수를 참조하는 모든 값을 바꿀 수 있다.2) 디자인 토큰과 아토믹 디자인의 차이
아토믹 디자인은 디자인 시스템을 구축하는 유명한 방법론으로 웹디자이너이자 프론트엔드 개발자인 브래드 프로스트(Brad Frost)가 저서 "Atomic Design"에서 소개했다. 아토믹은 UI를 쉽게 관리하기 위하여 더 작고 재사용 가능한 구성 요소로 분해한다. 크기와 복잡도도 나누어 아톰(Atoms), 분자(Molecules), 조직(Organisms), 템플릿(Templates), 페이지(Pages)와 같은 다양한 레벨로 분류된다.
https://bradfrost.com/blog/post/atomic-web-design/Atoms (원자): UI 디자인의 최소 구성 단위. ex. 버튼, 타이포그래피, 아이콘 등
Molecules (분자): 두 개 이상의 원자들이 결합하여 만들어진 단위. ex. 검색 폼 - 텍스트 필드와 버튼이 결합하여 만들어짐
Organisms (유기체): 분자들이 결합하여 만들어진 상위 단위. ex. 로그인 폼 - 로그인 버튼과 회원 가입 링크를 포함한 분자들이 결합하여 만들어짐
Templates (템플릿): UI 디자인의 레이아웃을 결정하는 단위. ex. 로그인 폼을 포함한 로그인 페이지 템플릿
Pages (페이지): 실제 사용자가 보게 될 화면. 페이지는 템플릿과 유기체, 분자, 원자 등을 조합하여 만들지는 최종 디자인의 모습이다.
https://atomicdesign.bradfrost.com/chapter-2/디자인 시스템을 검색했을 때 일반적으로 볼 수 있는 UI 컴포넌트들이 ATOMS, MOLECULES 위주의 정리인 것 같다.
https://dribbble.com/shots/5779721-Eggplore-UI-StyleGuide-Freebie디자인 토큰
디자인 토큰과 아토믹 디자인은 전혀 다른 방법론은 아니다. 둘 다 모두 디자인 시스템을 구축하는 데 사용되는 용어다. 그래도 자세히 살펴보면 개념의 차이는 있다. 아토믹 디자인이 UI를 재사용 가능한 구성 요소로 분해하는 방법론이라면 디자인 토큰은 가장 작은 디자인 속성을 정의하고 일관성을 유지하는데 사용되는 개념이다.
https://bradfrost.com/blog/post/extending-atomic-design/아토믹 디자인보다 더 하위 단계의 속성을 정의한다고 보면 될 것 같다.
디자인 토큰은 규칙적인 디자인 속성으로 정의된다. 주로 사용하는 값만 일정 단계로 지정을 해두며 사용하기 때문에 불필요하게 1-2px씩 다르게 디자인에 적용되는 경우를 줄일 수 있다.
https://designsystem.line.me/LDSG/foundation/object-styles-en
https://paste.twilio.design/tokens/list#border-widths
https://atlassian.design/foundations/spacing/토큰의 종류는 다양하다. 위에 첨부한 이미지처럼 기본적으로 사용되는 속성으로는 color, border color, border width, radius, sizing, spacing(padding, gap, margin) font size, font weight, elevation(shadow), shadow처럼 가시적으로 볼 수 있는 비주얼 요소가 있다.
그리고 더 세부적으로 사용하면 transition, z-index, break point와 같이 눈에 보이지 않는 값도 토큰으로 구성하기도 한다.
https://spectrum.adobe.com/page/motion/
https://nordhealth.design/tokens/#z-index
https://elastic.github.io/eui/#/theming/breakpoints/values3) 디자인 토큰의 이점, 토큰의 단계
단순 변수인 ‘color-primary’나 ‘radius-s/m/l’을 보았을 때 언제, 어디에 사용되는지 전혀 이해를 할 수 없다. 그리고 ‘color-primary’가 수많은 UI에 적용되어 있다고 했을 때 특정 UI(가령 라디오 버튼)의 색상만 바꾸고 싶을 경우 결국 해당 UI만 찾아서 ‘color-primary’를 다른 색상으로 일일이 바꿔줘야 한다. 디자인 토큰을 제대로 사용하면 이런 노가다 작업을 줄일 수 있다.
디자인 토큰의 진정한 이점은 토큰을 단계적으로 사용한다는 것에 있다. 토큰 뎁스의 중요성은 영상(What the #&%$ are Design Tokens?)을 보면 쉽게 이해할 수 있다.
토큰의 3단계 구조
서비스마다 차이가 있을 수는 있지만 보통 디자인 토큰은 3단계로 사용된다.
구글 material design 의 경우 Reference tokens, System tokens, Component tokens 3가지 위계의 토큰을 사용한다.
세 종류의 토큰을 사용하여 팀은 디자인 결정을 전체적으로 업데이트하거나 단일 구성 요소에 변경 사항을 적용할 수 있습니다.
Reference tokens (참조 토큰) :
디자인 시스템에서 사용할 수 있는 모든 스타일의 옵션을 구성한다. 일반적으로 색상으로 사용되는 hex 코드나 폰트, 두께와 같은 정적인 값이 있다. 참조 토큰은 일관된 색상, 유형, 측전 등을 위한 시작점을 제공한다.
System tokens (시스템 토큰) :
특정 주제나 사용 맥락에 맞게 의미를 부여하는 토큰이다. System tokens은 Reference Tokens에 의해 정의된 값을 바탕으로 UI에서 제공하는 사용 목적을 정의한다. 테마를 적용할 때 밝은 테마 또는 어두운 테마와 같이 맥락에 따라 다른 Reference Tokens을 가리킬 수 있다. 가능하면 System tokens은 정적인 값(ex. hex code)이 아닌 System tokens을 가리켜야 한다.
Component tokens (컴포넌트 토큰) :
컨테이너, 레이블, 아이콘 등 특정한 컴포넌트의 디자인 속성에 대한 값을 지정합니다. 가능하면Component tokens은 정적인 코드가 아닌 System tokens 또는 Reference tokens을 가리켜야 한다.
Adobe spectrum 역시 Global tokens, Alias tokens, Component-specific tokens 3가지의 단계의 토큰을 사용한다.
Global tokens (글로벌 토큰) :
글로벌 토큰은 사용 맥락에 구애받지 않는 이름으로 표현되는 디자인 언어의 기본 값이다. 색상 팔레트, 애니메이션, 타이포그래피 등의 정적인 값은 모두 글로벌 토큰으로 기록된다.
Alias tokens (별칭? 토큰) :
특정 사용 맥락과 관련이 있다. 토큰의 의도된 목적을 전달하는데 도움이 되며 같은 스타일을 여러 곳에서 표현해야 할 때 효과적이다.
Component-specific tokens (컴포넌트 토큰) :
컴포넌트와 관련된 모든 디자인 속성을 철저하게 표현한 토큰이다. 별칭 토큰에서 상속되는 경우가 많지만 가능한 컴포넌트를 구체적으로 지정할 수 있는 방식으로 이름이 지정된다.
토큰을 부르는 네이밍이 다를 뿐 사용의 목적은 비슷한 것 같다. 처음에는 왜 이렇게 복잡하게 토큰을 나눠야 하는지 이해하지 못했다. 오히려 너무 복잡해서 쓰기가 어려울 것 같았다. 그러나 기본적인 토큰을 만들어서 테스트를 해보고 난 후에 토큰 뎁스 정책이 제대로 정해지지 않으면 확장성이 떨어질 수 있다는 것을 깨달았다. 디자인 토큰을 사용하려는 목적이 바로 확장성이었기 때문에 적절한 토큰의 위계는 필요하다고 판단했다.
다만 유의해야 할 것은 토큰의 뎁스가 많다고 좋은 것은 아니다. 복잡해질수록 실제 사용하기는 어려워지기 때문이다. 하지만 너무 간단하게 축약해버리면 적절한 사용 목적을 제대로 구분할 수 없어서 확장성이 떨어진다. 결국 토큰의 범위와 개수의 밸런스가 중요하다. 너무 적어서 확장성이 떨어지지는 않으며, 너무 많아서 관리하기가 힘들지 않을 정도의 적정 수준. 그래서 그런지 디자인 토큰 단계를 2단계로 축약해서 사용하는 서비스도 있다고 어떤 아티클에서 보았다. 하지만 나는 정석을 한번 따르고 싶어서 3단계로 구성해볼 예정이다. 정리하다가 너무 복잡하다고 생각되면 합치는 쪽으로 개선해도 되고. 합쳐져 있는 것을 나누는 것보다 나뉘어 있는 것을 합치는 것이 더 쉬울 것 같아서 가능하면 구체적으로 분류를 해보기로 했다.
4) 디자인 토큰을 사용하는 서비스
디자인 시스템을 안내하는 사이트에서 토큰이 정리된 것은 많이 보았지만 실제로 작동하는 것을 많이 체크하지는 못했다. 사이트에서 개발자 도구를 열어서 root를 보면 foundation tokens이 정의된 서비스도 종종 보인다. 나중에 토큰 네이밍을 정할 때 분석해보는 것도 좋을 것 같다.
드롭박스
피그마에서 디자인 토큰 테스트
디자인 토큰의 중요성과 토큰을 구성하는 방법에 대해서는 대략 살펴보았다. 디자인 토큰을 사용한 디자인 시스템이 얼마나 확장 가능성 있게 작동할 수 있는지 토큰 기반으로 시스템을 사용하는 다른 서비스의 사례를 많이 찾아보았다. 그러다가 한 영상(In the file - Building a headless design system)에서 영감을 얻을 수 있었다.
하나의 디자인이 다양한 스타일로 바뀌는 것을 보고 이거다 싶었다. 라이트모드와 다크모드처럼 색상이 바뀌는 것은 자주 보았지만 폰트나 크기, 간격 등 다른 디자인 속성이 쉽게 변하는 것은 보지 못해서 신기했다. 이게 정말 피그마에서 가능한건가 싶은 의문이 들어서 피그마 토큰 플러그인을 사용하여 직접 테스트해보기로 했다.
결론부터 말하자면 그동안 디자인 툴은 정적이라고 생각하고 있었고, 실제 적용된 모습은 개발이 되고 나서야 자세한 플로우를 확인할 수 있다고 보았는데 큰 오산이었다. 그냥 내가 툴을 정적으로 활용하고 있었을 뿐. 사람은 생각하는 대로 본다고 했던가... 이전에는 생각하지 않아서 유용한 것들을 발견하지 못했나 보다.
1) 수정 용이성의 충족
피그마 토큰을 알기 전까지는 UI 수정이 필요할 때 컴포넌트를 일일이 찾아서 변경하고 있었다. 예를 들어 Button과 Input 등의 UI에서 border-radius 값을 동일하게 변경하려면 ⓐ각 컴포넌트를 찾고 또 ⓑ해당 컴포넌트의 모든 variant를 선택해서 변경해야 했다. (내가 방법을 몰라서 그럴 수도 있다.)
일괄 수정을 테스트하려고 둥근 모양의 Button 컴포넌트를 4개의 Variant(Normal, Hover, Active, Disabled)로 간단하게 만들어보았다.
[Before]
여기서 Nomal Variant만 선택하고 변경하면 Nomal에서 파생된 UI만 변경이 된다.
다시 말해서 하나의 컴포넌트에서 일괄적으로 디자인 스타일을 변경하려면 생성된 variant를 모두 선택하여 바꿔줘야 하는 것이다. 지금은 임시로 만든 버튼이라 variant가 4개밖에 없지만 제대로 디자인 시스템을 만들면 버튼 컴포넌트 하나에서만 수십 개의 variant가 생길 수도 있다.
컴포넌트도 디자인의 일관성을 유지하고 쉽게 재사용하거나 수정하기 위해서 사용하는 방법이었지만, 여전히 수정이 불편하다는 점은 있었다. 물론 하드 코딩보다는 훨씬 수정은 쉽지만. 그러나 이것보다 더 좋은 방법이 있을 것 같았다.
[After]
디자인 토큰으로 서로 다른 컴포넌트 속성 한번에 바꾸기
디자인 토큰을 적용하여 컴포넌트를 만들면 UI를 선택하지 않고도 스타일을 일괄적으로 변경할 수 있다. 아래 이미지는 서로 다른 컴포넌트의 border-radius를 모두 동일한 디자인 토큰 ‘b-radius-3 (8px)’으로 적용해서 만든 예시다.
(GIF) 모든 컴포넌트의 border-radius 일괄 변경컴포넌트 Input, Button, Label의 border-radius는 모두 ‘b-radius-3’이라는 디자인 토큰을 참조하고 있다. 따라서 ‘b-radius-3’ 토큰의 값만 8px에서 50%로 바꿔주면(꼭 50%이 아니라 원하는 값으로) 해당 토큰을 참조하고 있는 상위의 스타일이 모두 바뀌게 된다.
(아직 토큰 구조와 네이밍 정책을 정하지 않아서 테스트용으로 막 만들었기 때문에 ‘b-radius-3’이라는 토큰의 값을 바로 변경하는 것은 좋은 예시는 아니다. ‘b-radius-4’가 12px인데 ‘b-radius-3’이 12px보다 크다면 구조상으로 이상하므로. 참조하는 토큰의 값을 변경하면 일괄적으로 변경할 수 있다는 것을 확인하기 위해 막 넣어본 것이기 때문에 참고로만 봐주기를.)
특정 컴포넌트 스타일만 바꾸기
위와 같이 여러 종류의 컴포넌트를 일괄적으로 변경하는 것이 아니라 특정 컴포넌트의 스타일만 변경해야 할 경우도 있다. 아래에서는 button의 border-radius만 바꾸는 경우를 테스트해보았다.
(GIF) Button 컴포넌트만 radius 일괄 변경컴포넌트 Input, Label, Button의 border-radius는 8px의 값이 저장된 ‘b-radius-3’ 디자인 토큰을 직접적으로 참조하지 않는다. border-radius은 각각 ‘c-input-radius’, ‘c-button-primary-radius’, ‘c-label-radius’ 컴포넌트 토큰으로 적용되어 있다. 그리고 이 ‘c-input-radius’, ‘c-button-primary-radius’, ‘c-label-radius’ 토큰들이 ‘b-radius-3’이라는 디자인 토큰을 참조하고 있다.
중간에 컴포넌트 토큰이라는 단계를 넣었기 때문에 ‘c-button-primary-radius’가 참조하는 ‘b-radius-3’ 토큰만 다른 토큰으로 변경하기만 하면 Button 컴포넌트만 수정할 수 있다. 위의 예시에서는 ‘c-button-primary-radius’이 참조하고 있는 ‘b-radius-3’ 토큰을 ‘b-radius-round’로 변경해보았다. (round는 50%로 적용하고 싶었지만 %가 먹지 않아서 그냥 999px로 설정해서 테스트했다)
확실히 원하는 방식으로 수정이 쉽다는 것은 확인했다.
상대적인 크기로 변경하기
컴포넌트는 기능의 중요도와 위계에 따라서 다르게 사용되기 때문에 보통 small, medium, large 사이즈로 구성한다. 이름 자체에서도 알 수 있듯이 논리적으로 small이 medium보다 큰 값을 가질 수 없다.
(GIF) 버튼 상대적인 크기로 일괄 수정하나의 사이즈를 기준으로 정해서 수식으로 적용한다면 하나의 디자인 토큰 값만 변경해도 크기의 비례를 유지하고 바꿀 수 있다. 위의 예시는 버튼 M과 L은 S를 참조하고 있기 때문에 S의 값만 바꿔도 M과 L은 S가 커지거나 작아진 값에 따라서 함께 변경된다.
2) 브랜드 확장성
하나의 디자인 시스템을 여러 브랜드에 적용할 수 있어야 했다. 브랜드마다 스타일이 다를 수 있어서(다를 수밖에 없고) 동일한 컴포넌트를 사용하더라도 도메인에 따라서 룩앤필을 바꿀 수 있는 방식이 필요했다. 예시로 카드 UI를 만들어보았다.
아토믹 디자인에 따르면 ‘ORGANISMS’의 UI라고 할 수 있다.
https://www.designsystems.com/building-chimekit-with-atomic-design-and-a-collaborative-process/이 카드 UI는 디자인 토큰으로 적용했기 때문에 참조하는 CSS 시트만 변경해주면(그냥 체크 박스만 선택하면 된다) 이렇게 룩앤필을 바꿔볼 수 있다.
(GIF) 브랜드 테마 한 번에 바꾸기변수를 사용하면 디자인 수정이 쉽다는 것은 알고 있었지만 디자인 툴에서 확인하는 방법은 잘 모르고 있었다. 그래서 피그마 자체에서 즉각적으로 변경해볼 수 있다는 것이 큰 매력이었다. 페이지 단위로 디자인 작업을 할 때 UI를 하나하나 변경해서 확인하는 것은 굉장히 오래 걸리고 비효율적이었기 때문에. 여하튼 브랜드 확장성도 성공적으로 테스트를 완료했다.
카드 UI에 적용한 토큰을 뜯어보면 다음과 같다. 더 세부적으로 토큰화할 수 있으나 일단 테스트라서 확실하게 비주얼적으로 구분이 되는 부분만 토큰을 적용해보았다.
A. 카드
border-radius: var(--c-itemCard-hor-box-radius)
box-shadow: var(--c-itemBox-shadow)
background: var(--c-itemCard-hor-box-surface)
(GIF) 카드 BOX 자체의 모서리, 배경, 그림자B. 이미지와 콘텐츠 영역
(이미지) border-radius: var(--c-itemCard-hor-image-radius)
(이미지) padding: var(--c-itemCard-hor-image-padding)
(콘텐츠) padding: var(--c-itemCard-hor-box-padding-l)
(콘텐츠) padding-left: var(--c-itemCard-hor-box-padding-m)
C. 텍스트 (타이포그래피)
title: var(--c-itemCrad-hor-content-title)
title-color: var(--c-itemCrad-hor-content-title-color)
sub: var(--c-itemCrad-hor-content-sub)
sub-color: var(--c-itemCrad-hor-content-sub-color)
(GIF) 타이틀과 서브 텍스트 토큰D. 레이블
color: var(--c-label-text-color)
background-color: var(--c-label-bg-surface)
border: var(--c-label-bg-border)
border-radius: var(--c-label-bg-radius)
(GIF) 태그처럼 사용되는 레이블E. CTA 버튼
backgroun-color: var(--c-button-primary-surface)
border-radius: var(--c-button-primary-radius)
box-shadow: var(--c-button-primary-shadow)
(GIF) 핵심 액션 버튼번외) 다크모드 테스트
다크모드에서도 어떻게 보이는지 바로바로 확인 가능하다. 토큰으로 적용되어 있다면 어떤 테마든 쉽게 적용할 수 있을 것 같다.
(GIF) 다크모드 색상으로 일괄 변경느낀점
테스트를 해보면서 토큰을 어떻게 사용해야 하는지 얼추 정리된 것 같다. 이제 가장 난관은 토큰을 어떤 기준으로 분류하고 생성할 것인지다. 일단 foundation token만 만들어보았는데도 너무 많아서 나중에 작업할 때 언제, 어떻게 써야 할지 혼란스러울 것 같았다. 그리고 우후죽순 토큰을 생성하다 보면 미처 인지하지 못하고 중복 토큰이 계속 생성되어서 결국 일관성이 깨질 것 같기도 하다. 여러모로 사용처를 명확하게 인지할 수 있는 semantic 네이밍의 중요성을 더욱 깨닫고 있다. 확장성을 고려하여 충분한 카테고리로 나누되, 너무 많아서 작업하기 어렵지 않을 정도의 밸런스를 어떻게 맞출지가 고민이다.
실제 서비스에 운영하기까지는 아직 갈 길이 멀지만, 목표로 했던 수정 용이성과 브랜드 확장성을 위한 방법을 찾아서 다행이다. 하드코딩으로 한번 적용되어 서비스 전반적으로 적용된 후에는 각 잡고 수정하지 않는 이상 고치기 힘들다는 것을 알기 때문에 초반에 토큰으로 잘 구성해 둘 필요성을 더 절실히 느끼고 있다.
아직 토큰의 구성에 대한 확실한 체계와 네이밍와 같은 구체적인 정책을 정하지 못했고 알면 알수록 복잡해서 실제 운영에 작 적용할 수 있을지 걱정이 되긴 한다. 방법론 자체가 정답은 아니기 때문에 좀 더 좋은 효율성을 찾기 위한 고민이 계속되고 있으며 막힐 때마다 막막해진다. 그래도 아무것도 하지 않는 것보다는 새로운 시도를 해보는 것이 낫다고 생각한다. 물론 그 결과가 너무 복잡해서 실패하게 되더라도 또 그 안에서 배우는 것이 있을 것 같다.
이전까지만 해도 디자인 시스템은 그저 보기 좋게 디자인 통일성을 지키기 위한 룰이라고 생각했다. 스타일 가이드 그 이상이라고 생각하지 않았던 것 같다. 고객에게 중요한 것은 디자인 자체가 아니라 유용한 서비스라고 보았기 때문에 페이지마다 디자인이 조금씩 다르다고 해서 별문제가 있는 것 같지도 않았다. 그건 디자인에 대한 나의 편협한 사고에서 기반한 것 같다. 다른 서비스에서 접근성, 로컬라이징, 다양한 사용 케이스를 상세하게 정리하여 시스템을 정리한 것을 보고 반성을 많이 했다. 디자인은 보기 좋기만 한 것이 아니라 그 이상의 총체적인 경험이었고, 실제로 서비스를 이용할 수 없게 만들기도 하니까. 접근성에 대한 고려도, 작업할 때마다 기준 없이 그때그때 끌리는 스타일로 디자인을 했던 과거의 나를 반성하며 앞으로는 논리적인 디자인을 항상 생각하며 작업해야겠다는 다짐을 했다.
