Headless Design System
멀티 브랜드를 위한 하나의 디자인 시스템
커버 이미지 출처: https://tokens.studio/
본 글은 In the file - Building a headless design system(Youtube) 일부를 번역 및 참고하여 작성한 글입니다. 본문에 사용한 이미지 출처 역시 동일 영상입니다.
목차
1. Headless란?
2. Headless Design System
3. Design Tokens
4. Single File Components
Headless란?
Headless라는 개념은 웹 개발 주로 사용하는 용어로 백엔드와 프런트엔드를 분리하는 개념입니다. 이는 사용자 인터페이스와 백엔드 로직을 완전히 분리하는 것을 의미하며, 백엔드에서는 데이터와 로직을 처리하고 프런트엔드에서는 사용자 인터페이스만 담당하는 것을 말합니다.
헤드리스 개념을 적용하여 웹 프로덕트를 개발하면 프런트엔드와 백엔드를 독립적으로 개발하기 때문에 서로 간 영향을 최소화하여 개발을 진행할 수 있습니다. 헤드리스는 마이크로서비스 아키텍처와 같이 유연하고 확장 가능한 아키텍처를 구현하는 데 도움이 됩니다.
Headless Desgin System
헤드리스 디자인 시스템은 시각적 디자인과 컴포넌트의 기능을 분리해 각각 독립적으로 개발한 디자인 시스템을 말합니다. 시각적 디자인이 없는 컴포넌트를 Headless Component라고 하며, 헤드리스 컴포넌트는 여러 토큰과 결합하여 themed component가 되는데, 이 컴포넌트가 사용자 인터페이스에서 실제로 사용하는 컴포넌트입니다.
Design Tokens
헤드리스 디자인 시스템에서 컴포넌트의 시각적 요소는 Design Token으로 컴포넌트와 분리되므로, 디자인 토큰이 무엇인지 먼저 설명하려 합니다.
디자인 토큰은 디자인과 관련된 값을 갖고 있는 변수, 쉽게 말해 시각적 디자인 속성에 대한 정보를 갖고 있는 재사용가능한 작은 정보의 조각입니다.(이 개념은 Salesforce의 Lightning Design System 구축 과정 중 만들어졌습니다.)
예를 들어, #635bff와 같은 hex값의 컬러 값을 blue-500과 같이 이해하고 관리하기 편리한 변수로 관리할 수 있는데, 이것을 디자인 토큰이라고 합니다. 아래의 이미지처럼 버튼, 텍스트, 라디오 버튼의 컬러를 모두 'blue-500'으로 관리할 수 있습니다.
blue-500이란 이름의 design token색상 외에도, 간격(Spacing), 타이포그래피(Typography), 크기(Scale) 등 시각적 요소를 디자인 토큰으로 관리할 수 있습니다. 디자인 토큰은 유연하고 확장 가능한 시스템을 구축하고 유지 및 관리하는데 도움이 됩니다.
Semantic Token, Option Token
하지만 button, heading, radio-button 컴포넌트가 모두 blue-500 토큰을 참조하고 있는 상태에서 버튼의 색만 변경하고 싶다면 어떻게 해야 할까요? 목적에 따른 Semantic Token(또는 Alias Token)을 사용할 수 있습니다. 보통, Semantic Token은 값을 갖고 있는 blue-500과 같은 Core Token(또는 Global Option Token) 하나를 참조합니다.
Semantic Token과 Option Token
action-primary-bg 토큰이 참조하고 있는 option token을 red-400으로 변경피그마에서 디자인 토큰 관리하기
하지만 몹시 아쉽게도 피그마에는 아직 이런 디자인 토큰 관리 기능이 없습니다. 현재는 Colors, Typography, Box Shadow 등 아주 일부 스타일만 토큰으로 관리할 수 있습니다. 아직 피그마에선 크기나 여백과 같은 변수로 지정해 둘 수 없으며, 하나의 토큰이 다른 옵션 토큰을 참조할 수 없어, Semantic Token과 같은 다른 토큰을 참조하는 토큰을 사용할 수 없습니다.
하지만 이를 보완할 수 있는 플러그인을 사용할 수 있습니다. 가장 유명한 플러그인은 Tokens Studio for Figma입니다. 이 플러그인으로 피그마에서도 쉽게 토큰을 정의하고 관리할 수 있으며, 이 정의된 토큰을 디자인 요소에 쉽게 적용할 수 있습니다. 컴포넌트에 적용된 토큰값에 대한 주석 생성 기능도 있어, 각 컴포넌트 별 핸드오프도 편리하게 관리할 수 있습니다.
본 포스팅은 Headless Design System에 대한 기본 이해를 위한 글이므로 Tokens Studio for Figma 플러그인 사용 방법은 아래 링크로 대신합니다.
Component Specific Token
지금까지 Core Token, Semantic Token 두 가지 토큰을 소개해 드렸는데요, 헤드리스 디자인 시스템에서는 Component Specific Token도 필요합니다. 이 토큰은 어떤 컴포넌트가 어떤 값을 사용하는지 구체적으로 표기합니다. 이 토큰은 Semantic Token을 참조하며, 컴포넌트는 Component Specific Token을 참조합니다. 이렇게 되면 아래 그림처럼 총 5개의 레이어가 생깁니다.
버튼 컴포넌트를 하나 예로 토큰 간 참조 구조를 시각화하여 표현하면, 아래 이미지와 같이 버튼 컴포넌트는 각각의 Component Specific Token과 연결되어 있고, Component Specific Tokens는 action-primary-background라는 Semantic Token과, 또 이 Semantic Token은 blue-500이라는 Option Token(Core Token)과 연결되어 있는 것을 볼 수 있습니다.
디자인 시스템이 이렇게 3단계의 토큰을 갖게 되면, 여러 개의 테마를 만들어 UI에 적용할 수 있습니다. 설명을 위해 아래 그림을 먼저 봐주세요.
위 그림에서, 버튼 컴포넌트는 button.cta.default.background-color과 button.border-radius라는 button.json 파일 내 Component Specific Tokens을 참조하고 있으며, 각각의 Component Specific Token은 또 brand-a.json이라는 파일의 Semantic Tokens를 참조하고 있습니다. 여기서 Granular가 Simplified를 다시 참조하고 있는 모습도 볼 수 있습니다. 이 Semantic Tokens은 또 각각의 Core Tokens을 참조하고 있습니다.
만약 버튼의 색과 모서리 둥글기를 변경하고 싶다면, 아래와 같이 brand-a.json안에서 참조하고 있는 option tokens을 변경해 주면 됩니다.
Ta-da! 참조값만 변경하여, 파란색의 둥근 버튼을 만들었습니다. 즉, semantic tokens만 변경하면, 테마를 변경할 수 있게 됩니다.
다른 컴포넌트를 볼게요. 아래 이미지의 가장 왼쪽에선 Avatar란 컴포넌트를 볼 수 있고, 컴포넌트 바로 오른쪽부터 컴포넌트가 참조하는 토큰들을 확인할 수 있습니다. Component specific token이 Granular semantic token으로 연결되고, 일부는 Simplified semantic token으로 연결되며, 최종적으로는 core token에 연결됩니다. Simplified semantic token이 없는 경우 직접 Granular semantic token이 core token과 연결됩니다. 이 두 개의 semantic token sets이 Themeable tokens이며, 다른 테마를 만들려면 이 토큰 값을 변경하면 됩니다.
또한 여러 테마를 적용하는 가장 기본 방법은 기본 Semantic Token에 Overwirte 되는 구조로 다른 테마의 token 파일을 만들어 적용하는 겁니다. Component specific token이 가장 먼저 참조하는 Semantic token에 대한 정보 소실 없이 안전하게 다른 테마를 적용할 수 있기 때문입니다.
이제 figma에서 Tokens Studio for Figma 플러그인을 활용하여, 심플한 카드 UI에 여러 테마를 적용하는 모습을 보겠습니다. 사진과 텍스트, 버튼으로 구성된 카드 디자인을 왼쪽에서 확인할 수 있고, 오른쪽 Figma Tokens 플러그인 탭에서 core, comp, semantic에 체크된 체크박스를 확인할 수 있습니다. 체크된 항목은 활성화된 tokens을 의미합니다. AL, AD, BL... 을 활성화 각각 다른 테마를 적용할 수 있습니다.
Core, Componet Specific, Semantic Token만 활성화된 기본 테마 디자인
AL 테마를 활성화하여 변경된 디자인, 가장 마지막에 활성화한 AL 테마가 기존 테마에 overwrite 되었습니다.
AD 테마를 활성화하여 변경된 디자인, AD 테마가 가장 마지막에 Overwrite 되었습니다.Single File Components
디자인 시스템을 만들고 있는 디자인팀이라면, 컴포넌트 디자인 파일을 어떻게 관리할지 한 번쯤 고민해 보셨을 겁니다. 하나의 파일 안에 다수의 컴포넌트들이 있는 구조가 효율적일까요? 아니면 하나의 파일에 하나의 컴포넌트만 있는 구조가 효율적일까요?
Esther Cheran(Creator of Headless Design System)는 피그마에서 Headless Design System을 구현하기 위한 최적의 파일 관리 방법으로 Single file components 방식을 제안합니다. 이 방식은 하나의 헤드리스 컴포넌트별로 파일을 따로 만드는 방식입니다. 그녀의 말에 따르면 단일 파일 컴포넌트 방식으로 헤드리스 디자인 시스템을 구축하면 다음과 같은 장점이 있다고 합니다.
- 관리가 간편합니다: 문서화, 핸드오프, 테마화(Theming), 버전 히스토리 관리, 접근 권한 관리 모두가 용이합니다.
- 피그마 파일 구조와 코드 라이브러리가 동일한 구조를 가질 수 있습니다.
- 큰 용량의 피그마 파일에서 발생하는 성능 이슈를 겪지 않아도 됩니다.
Single File Components 방식으로 파일 관리 시 이점
컴포넌트별 파일들, 작업 중인 컴포넌트와 아닌 컴포넌트를 Cover 배경색으로 구분하고 있습니다.For More Information
<The Future of Design Systems>라는 디자인 시스템 온라인 콘퍼런스가 2023년 6월 8일, 9일 이틀간 열립니다. Headless Design System에 대한 자세한 내용은 물론, 디자인 시스템의 최신 트렌드와 미래를 볼 수 있는 콘퍼런스인 것 같습니다.
