디자인 시스템의 육하원칙-
3. 무엇을? 어떻게? -1
디자인 토큰이 디자인 시스템의 정체성 및 유지 리소스에 미치는 영향
시리즈 소개
이 글은 디지털 디자인 브랜드 'Data Driven Design'의 기획 콘텐츠, '디자인 시스템의 육하원칙', 세 번째 에피소드입니다. 디자인 시스템 도입에 장벽을 느끼는 실무자들에게 도움을 주고자 기획하였으며 총 4개의 에피소드로 구성되었습니다.
1. 왜?
2. 누가, 언제?
3. 무엇을, 어떻게?- 01
4. 무엇을, 어떻게?- 02
4. 그래서?
목차
0. 무엇을, 어떻게? - part1: 프롤로그
1. 디자인 시스템을 이루는 세가지 패턴
2. 디자인 시스템의 원칙과 디자인 토큰
3. 토크나이징 과정에서 고려할 요소들
4. 정리하며
0. 무엇을, 어떻게? - part1: 프롤로그
기나긴 1,2번째 에피소드를 모두 읽고 오신 분들이 계시다면 박수를 쳐드리고 싶네요! 첫 에피소드(왜?)에서는 조직이 단선적 사고에서 시스템 사고로 전환하기 위한 디자인 시스템을 얘기했습니다. 이어서 아토믹 디자인 접근과 분류체계 활용한 디자인 시스템 도입을 두 번째 에피소드(언제, 누가?)에서 다루었습니다.
세 번째 에피소드 '무엇을 어떻게' 에서는 본격적으로 디자인 시스템의 구축 과정을 들여다봅니다. 특히 디자인 시스템을 구성하는 세가지 패턴들의 존재 이유를 시스템의 본질적인 특성(왜)과 디자인 시스템의 발전 단계(언제,누가)와 연관지어 살펴보겠습니다. 그리고 인지적 패턴에 해당되는 디자인 토큰을 설계하는 방식을 매우 현실적인 관점에서 다루어 보고자 합니다.
산출물들의 예시는 figma(디자인툴), React(개발언어)를 활용하였지만 업무 환경이 바뀌어도 충분히 응용할 수 있는 내용들로 구성되었습니다. 이번 에피소드가 디자인 시스템의 사용자들 간에 간극을 한층 줄여주는 역할을 하길 바라며 세 번째 에피소드를 시작하겠습니다.
1. 디자인 시스템을 구성하는 세가지 패턴
첫번째 에피소드(왜?)에서 모든 시스템들은 구성 요소들의 상호 연결성을 파악하고 합성을 반복하는 과정에서 새로운 패턴이 발현된다는 점을 언급했습니다. 디자인 시스템 또한 본질적으로 시스템이라는걸 잊지말아야 하며 이를 구성하는 페턴에는 크게 3가지 종류가 있습니다.
인지적 패턴(Perceptual): 브랜딩과 UI의 기본적인 조형을 위한 시각적 인지 패턴
기능적 패턴(Functional): 특정 기능을 위한 UI, 혹은 2개 이상의 조합 패턴
맥락적 패턴(Contextual): 반복되는 태스크를 해결하기 위한 기능적 패턴의 조합
아토믹 디자인의 구성요소가 큰 단위로 합성될수록 인지적, 기능적, 맥락적 패턴의 성격을 띄게된다.패턴이라는 것은 결국 반복되어 사용 되어야할 대상을 얘기합니다. 인지적 패턴은 사용자가 직관적으로 인식하게 되는 모든 시각적인 요소들의 패턴과 규칙들을 얘기하며 이는 결국 비주얼 브랜드와 UI의 접점에 있는 영역입니다. 따라서 color, typography, space와 layout 활용, grid system 등 모든 시각적 요소들이 제품과 브랜드 두 영역의 특징을 모두 나타내야 합니다.
결국 이러한 시각적 요소를 체계적으로 정리한 것이 디자인 토큰이며 디자인 토큰은 디자인 툴과 개발 환경에서 모두 컴퍼넌트들이 시각요소들을 바로 활용할 수 있도록 인덱싱을 해주는 역할을 합니다. 조금 과장해서 얘기하자면 디자인 토큰은 디자인 시스템의 DNA와도 같다고 생각합니다. 단순히 값을 저장하는 역할을 할 뿐 아니라 카테고리의 키값과 계층 구조를 어떻게 구성하냐에 따라 디자인 시스템의 성격이 달라지기 때문입니다. 저는 디자인 토큰의 역할을 다음 3가지로 요약합니다.
이미지 출처: zeroheight.com/ 디자인 토큰을 설계하는 것은 단순히 시각적 요소에 대한 정의하는 것뿐 아니라 브랜드, 제품의 특성을 견고하게 이해하는 과정이기도 하다.1. 디자인 시스템의 원칙 (design principle)을 반영하는 foundation 역할을 한다.
2. 시스템 빌딩의 효율성과 생산성을 높이는데 결정적인 역할을 한다.
3. 디자인 시스템의 리팩토링 소요를 최소화하고 업데이트 영역에서 혁신의 공간을 마련해준다.
간혹 디자인 시스템을 막 도입하려는 디자이너의 입장에서 '서로 다른 디자인 시스템들속에서 디자인 토큰의 구조가 다르면 얼마나 다를까?'라는 궁금증이 생길 수있습니다. 디자인 토큰의 브랜드적인 역할만 보면 메인 컬러톤과 타이포만으로 이미 브랜드 키 비쥬얼을 구성하는데 큰 무리가 없기 때문입니다. 하지만 UI 요소들을 빌딩하는 과정속에서 수없이 리팩토링과 업데이트의 트레이드 오프를 마주하는 상황을 상상해 본다면 디자인 토큰의 구조를 우리 제품에 맞게 설계하는 것이 매우 중요합니다.
리팩토링: 시스템의 최적화를 위해 외부 동작을 변경하지 않고 기존 요소들을 재구성하는 프로세스
업데이트: 새로운 기능 추가 혹은 퍼포먼스의 향상을 위해 구성 요소를 추가하거나 변경하는 프로세스.
디자인 토큰은 아토믹 디자인의 가장 작은 요소이기 때문에 한번 설계되어 이미 더 큰 요소(컴퍼넌트, 템플렛 등)들에 배포된 이후에 수정하게 된다면 이는 이미 디자인 토큰만의 문제가 아니기때문입니다. 이전 에피소드(누가?언제?)에서 찰스 다윈이 종의 기원을 쓰면서 차용했던 분류의 방법과 어느 대형 서점의 잘못된 분류체계가 서점 전체 네비게이션 시스템에 미친 부작용을 설명한 것 또한 같은 맥락입니다. 이는 디자인 토큰을 완벽하게 완성하고 다음 단계로 넘어가야 한다라고 주장하는 것이 아닙니다. 적어도 제품이 갖춰야할 특징이 반영될 수 있는 최소한의 카테고리가 확장 가능한 형태로 반영이 되야할 것입니다. 다시 말하자면 디자인 토큰안의 값뿐만 아니라 이를 인덱싱 해주는 카테고리의 계층 구조 또한 중요합니다. 이렇게만 얘기해면 잘 이해가 안갈 수있으니 더 구체적인 예시를 들어보겠습니다.
2. 디자인 토큰과 제품의 특성과의 관계
이제 성격이 다른 2개의 디자인 시스템을 비교해 보면서 디자인 시스템의 원칙이 토크나이징 과정에 어떻게 영향을 미치는지 살펴보겠습니다. 예시로 선택한 기준은 일단 많은 사람들이 알만한 인지도를 갖고 있는지와 디자인 가이드와 코드가 오픈소스로 공개돼서 직접 확인할 수 있는가를 고려했습니다.
(참고로 아래 설명할 각 디자인 시스템들의 특성은 공식 문서에서 직접 밝힌 것보다 제가 직접 리뷰한 주관이 많이 섞여 있으니 참고 부탁드립니다.)
- MUI by google
- carbon design system by IBM
IBM Carbon Design System
Google Material UI2-1. Material UI by google - 유니버설 디자인 버전의 디자인 시스템
MUI는 구글에서 제공하는 material design기반 상용 버전의 디자인 시스템입니다. 전 세계 남년노소가 사용하는 구글인 만큼 MUI에서 가장 중요시하는 가치는 모든 사용자의 accebility(접근성)이며 이는 '노인과 장애인이 사용가능하다면 모두가 사용가능하다'는 의미의 유니버설 디자인의 철학과도 비슷합니다. 따라서 꼭 필요한 만큼의 미니멀리즘 그리고 명확하고 오해의 소지가 없는 사용자 인지를 위해 다른 디자인 시스템에 비해 엄격한 룰을 갖고 있습니다.
mui의 컴포넌트들은 누구에게나 인지적인 접근성이 가장 높도록 설계되었고 이를 구성하는 디자인 토큰 또한 이점을 염두에 두고 설계되었다.이 말은 반대로 하면 커스텀의 자유도를 통제하여 이들이 지향하는 접근성과의 오차를 최소화 하겠다라는 의도와도 같습니다. color token을 예로 들면 컬러의 우선순위와 역할을 기준으로 분류된 palete에 항상 고정된 opacity값과 배경색의 블렌딩으로 정해진 interaction rule이 적용돼 있는데 가능하면 이 외의 커스텀을 지양하는 방향으로 설계되어 있습니다. 버튼을 비롯한 인터랙션을 요구하는 컴포넌트들은 오직 사전에 약속된 칼러 역할의 키값 (eg. primary, secondary, error...)을 부여하는 것만 허용하여 불필요한 color varation을 사전에 방지합니다. (물론 inline style을 비롯한 강제로 색을 변경할 수 있지만 이는 mui에서 지향하는 방식은 아닙니다.)
MUI figma 파일에서의 variable: color palete의 구성은 시각적인 복잡도와 접근성을 엄격하게 통제하고자 하는 의도가 반영되어 있다.
mui react 프로젝트의 color theme config 파일: 테마 프로바이더에서 정의한 룰에 벗어나는 토큰 값들은 애초에 컴포넌트들에 배포되지 않는다.2-2. Carbon Design System by IBM - 궁극의 모듈러티와 가독성을 위한 집합체
carbon design system은 IBM에서 제작한 디자인 시스템으로 공식 웹사이트를 비롯한 다양한 클라우드 서비스들을 구성하고 있습니다. IBM의 사업적인 맥락을 고려했을 때 시시각각 진행되는 R&D의 결과물을 빠르게 프로토타이핑할 수 있는 환경이 중요할 것입니다. 따라서 불필요한 디자인 의사결정을 최소화하며 기능의 최소단위를 레고처럼 빠르게 조립하고 변경해 볼 수 있는 모듈화가 디자인 시스템의 중요한 요소라 보입니다.
carbon design system은 구성 요소들이 병렬적으로 추가되어도 시각적인 안정감을 잡아주는 견고한 그리드 시스템과 효율적인 정보 그루핑에 최적화된 컬러 토큰을 갖고 있다
Carbon Design System의 color token은 유연하게 확장 가능한 구조를 지향한다.
Sass로 관리되는 Carbon design system의 디자인 토큰은 material design과 비교했을때 더 넓은 자유도의 커스터마이징을 허용한다이처럼 자동 배포되는 b2b환경에 최적화된 carbon design system은 페이지, 템플렛의 구성 요소가 병렬적으로 추가되어도 빠르게 시각적 계층을 구성할 수 있는 레이아웃과 그리드 시스템을 갖고 있으며, color palette 또한 최소한의 변화를 통해 밀접해 있는 정보들을 효과적으로 그루핑 할 수 있는 토큰들로 구성되어 있습니다. 참고로 material ui와 비교하자면 carbon design system의 디자인 토큰은 theme provider에 제공하는 json형태가 아닌 sass로 관리가 되며 토큰들의 커스터마이징(추가, 수정)의 자유도가 높아 세밀한 시각 보정에 용이합니다.
2-3 여러분의 design system은 어떤 특징이(있어야) 있나요?
앞서 성격이 다른 2개의 디자인 시스템을 살펴보면서 각 디자인 시스템의 방향성과 특징에 따라 디자인 토큰을 어떻게 구성되었는지를 짧게나마 살펴보았습니다. 다시 강조하지만 디자인 토큰은 디자인 시스템에서 가장 중요한 분류체계라 할 수 있으며 비즈니스, 제품 빌딩 환경에 맞게 토크나이징이 이루어졌을 때 리팩토링 소요를 최소화하고 제품에 맞는 UX.UI 요소들을 빌딩 하는데 집중할 수 있습니다.
아토믹 디자인의 아톰 단계라고 할 수 있는 디자인 토큰을 작성하는 가장 이상적인 방법은 우리 제품과 가장 유사한 환경에 있는 디자인 시스템을 그대로 차용하거나 응용하는 것입니다. 제가 가장 추천하는 방법은 피그마를 비롯한 여러 커뮤니티에서 오픈 소스로 공개된 몇몇 디자인 시스템과 이를 기반으로 만들어진 제품을 같이 비교해 보면서 이들이 추구하려는 UX전략과 디자인 토큰 구성의 관계를 유추해 보면서 우리 팀이 차용할 부분과 하지 말아야 할 부분을 구체화하는 접근입니다. 그리고 가능하면 단순히 디자인 키트로 제공되는 디자인 시스템이 아닌 실제로 가이드를 기반으로 개발까지 완료된 디자인 시스템을 참고하는 것을 권장하며 아래는 제가 평소에 레퍼런스로 많이 활용하는 디자인 시스템 리스트입니다.
1. material ui - google , 가이드 및 공식 사이트 링크
2. carbon design system - IBM, 가이드 및 공식 사이트 링크
3. Goldman Sachs Design System, 가이드 및 공식 사이트 링크
4. Base Design System - Uber, 가이드 및 공식 사이트 링크
2-4 또 다른 예시: Datum Design System의 디자인 토큰
그런데 앞선 예시들은 이미 고도화가 이루어진 디자인 시스템이어서 어떻게 시작을 할지 여전히 감이 잡히지 않을 수 있다는 생각에 최근 제가 작업한 Data Driven Driven의 Datum Design System(이하 DDS)을 예로 들어보겠습니다. DDS는 데이터 드리븐 디자인의 브랜드 웹사이트와 더불어 클라이언트사의 서비스를 개발하기 앞서 그들의 상황에 맞게 확장하려는 용도로 아직도 제작중에 있는 디자인시스템입니다. 일단 저는 DDS의 디자인 원칙을 다음 세가지로 정했습니다.
1- Geometric Minimalism
모든 조형 요소를 데이터와 알고리즘으로 표현이 가능한 primary shape의 조합으로 구성, 모듈화된 비주얼 시스템을 지향한다.
2- Contextual Dynamic
data가 정보, 컨텐츠가 되는 과정의 연속성을 역동적으로 표현하여 시각 요소들이 전달하려는 메세지의 맥락을 효과적으로 반영한다.
3- Quantum Data
데이터가 물질이라면? 이라는 질문을 기반으로 데이터로 구성된 공간, 형태, 시간 등 물리적 대상들을 브랜드 키비주얼로 표현한다.
위의 원칙들은 이세상에 모든것을 데이터로 표현하면 어떻게 보일까? 라는 질문에서 나왔으며 극단적인 단순성을 시간과 모션 그리고 그리드 시스템과 절묘하게 조합하기 위한 환경을 구성하는 것이 DDS의 디자인 토큰의 역할이라고 생각했습니다. 아직 완성이 되있지 않아 모든 것을 공개하긴 어렵지만 color token만 더 들여다보자면 조금이라도 반복이 되는 것들을 같은 페턴으로 묶는 것이 적합하다고 판단하였습니다.
놀랍게도 위의 토큰들이 dds의 color token의 전부입니다. UI는 텍스트, 아이콘을 포함 UI의 컨텐츠를 직접 표현하는 core token이며 그 외에 정보의 성격을 나타내는 Status, 컨테이터의 Surface, Border에 다시 mapping하여 사용합니다. 그리고 버튼,인풋,칩,스낵바와 같은 인터랙티브한 컴퍼넌트들의 시각 보정을 일괄적으로 조절할수 있도록 네스팅 컴퍼넌트를 별도로 관리하여 관리에 있어서도 미니멀한 접근을 추구하였습니다.
3. 토크나이징 과정에서 고려할 요소들: 네이밍 컨벤션과 배포 방식
여기까지 과정을 통해 우리 제품의 디자인 시스템이 갖춰야 할 원칙과 디자인 토큰의 성격을 정했다면 이제 본격적으로 토크나이징 하는 과정을 들여다보겠습니다. 토크 아니지은 피그마에서 스타일링 혹은 variable로 관리하는 토큰을 개발 사이드에서 어떤 방식으로 배포할 것인가를 모두 포함되는 과정을 말합니다. 토크나이징 과정에서 고려할 것은 다음 2가지입니다.
1. 디자인 토큰의 네이밍 컨벤션
2. 개발 환경에서 디자인 토큰을 컴포넌트들에 배포하는 방식
시스템의 모든 요소들이 그러하지만 디자인 토큰 또한 모든 참여자들이 이해하고 의미가 명확하며 빠르게 인덱싱이 가능한 네이밍 규칙이 정립되야 합니다. 이때 고려할 네이밍 컨벤션에는 대략 다음과 같은 옵션들이 있습니다.
3-1 네이밍 컨벤션
4가지 표기법에 꼭 정해진 용도는 없지만 관리해야 할 이름의 양이 방대해지기 전에 경우에 따라 지킬 규칙을 정하는 것이 좋습니다.보통 디자인 토큰 네이밍을 할 때는 snake_case와 kebab-case를 사용하게 됩니다. 언더라인과 스트라이크 라인이 토큰의 성격과 베리에이션에 해당되는 단어를 구분하기 때문인데요 더 구체적으로는 json에 옮겨질 디자인 토큰은 snake_case, css나 sass의 스타일 파일로 옮겨질 토큰들은 kebab-case를 사용합니다. (참고로 json을 비롯한 javasciprt환경에서는 kebab-case의 네이밍룰은 적용 불가능합니다.)
컴포넌트 네이밍의 우선순위를 '기능 > 맥락 > 특징'의 순으로 지정하였다.네이밍 규칙에 정답이 있는 것은 아니지만 위의 방식은 제가 주로 사용하는 규칙입니다. 특정 컴포넌트를 찾을 때 일단 어떤 기능을 하는 것인지를 파악하고 그다음에 어떤 맥락과 연결되었는지 마지막으로 어떤 세부 특징을 갖고 있는지를 확인합니다. 즉 네이밍의 왼쪽에 있을수록 상위 카테고리와 연결이 됩니다. 이름을 구성하는 규칙 또 있지만 표현하는 규칙도 존재할 수 있습니다.
모든 Card UI의 기본 기능. 속성은 Clickable Container로부터 상속받으며, Container 역시 Style에 미리 정의된 요소들만의 조합으로 정의된다.3-2 디자인 토큰 배포 방식
디자인 토큰을 배포하는 방식은 크게 2가지 방식이 있습니다. 가장 간단하게는 토큰과 동일한 네이밍의 스타일 파일로 배포하는 방식(scss, sass)과 모던 프레임웍에서 상태관리하는 방식과 유사하게 모든 토큰이 매핑된 theme파일을 theme provider를 통해 배포하여 시스템 내의 모든 컴포넌트에게 토큰 접근권한을 부여하는 방식입니다.
앞선 예시에서 carbon design system은 sass(스크립트 방식으로 신택스를 적용가능한 확장형 css) 그리고 구글의 material ui는 theme provider와 json형태의 theme파일의 조합을 통해 디자인 토큰을 관리합니다. 제 개인적인 생각은 전자는 확장성을 속도감 있게 활용하고 싶을 때의 장점이 있고 후자는 토큰 간의 관계를 유기적으로 만들고, 시스템 룰을 좀 더 견고하게 하고 싶을 때 용이합니다.
당연히 이 두 방식 중 무엇이 더 우월하다고 볼 순 없으며 각자 환경에 맞는 방식이 무엇인가 생각해 볼 필요가 있습니다. 개인적으로 후자의 방식을 선호하는데 그 이유는 제가 주로 작업하는 프로젝트의 성격상 디자인 토큰과 컴포넌트의 props로 받은 데이터를 연산해서 인터랙티브 한 모습을 연출할 때가 많기 때문이며 이또한 정답이 있는것은 아닙니다. 디자이너가 앞에서 언급한 2개 방식을 모두 이해할 필요는 없지만 이 두 개의 다른 디자인 시스템의 토크 아니지 방식이 다른지를 전 챕터의 내용과 함께 유추해 본다면 팀 내 개발자와 함께 우리 제품에 맞는 디자인 시스템에 맞는 방식은 어떤 것인지 정하는데 도움이 될 것입니다.
4. 정리하며...
이번 에피소드에서는 디자인 시스템 구축의 시작점인 디자인 토큰이 궁극적으로 디자인 시스템의 방향성 및 향후 리팩토링 소요에도 큰 영향을 미치는 이유에 대해서 깊게 살펴봤습니다. 그리고 디자인 토큰을 작성할 때 반드시 살펴야 할 브랜드와 제품 개발 환경의 특징을 2개의 다른 디자인 시스템을 예시로 들어 얘기해 봤으며 마지막으로 디자인 토큰 및 컴포넌트를 구성할 때 참고할 네이밍 룰에 대해서도 다루었습니다.
디자인 토큰을 설계하는 일은 조금 지루하면서도 자칫 모든 디자인 시스템의 토큰값이 얼추 비슷하지 않을까?라는 생각이 잠시 들기도 하지만 이렇게 지나치기에는 그 영향력이 크다고 생각합니다. 다음 챕터에서는 디자인 토큰을 디자인 시스템에서 어떻게 효과적으로 배포하면서 컴포넌트, 템플렛 등 큰 단위로 합성하는 과정에 대해 다룰 예정입니다.
다음 에피소드: 무엇을, 어떻게-2? 에서 계속됩니다>>
이전 에피소드: 언제? 누가? 보기
Creat Your Business Value With Data Driven Design
