안녕하세요. 저는 GS SHOP Mobile 개발팀에서 디자인 시스템 구축을 담당하고 있는 이인영입니다.
디자인 시스템에 대해 Product UX 팀의 박이슬 매니저님께서 상세히 작성해 주신 내용들이 있기에 저는 간략하게 디자인 시스템에 대해 설명하고 현재까지 어떤 방식으로 디자인 시스템을 작업하고 있는지, 디자이너와 개발자의 협업과 디자인 토큰이 무엇인지 그리고 디자인 토큰을 정의하여 테마를 적용해 보는 것에 대해 이야기해 보려고 합니다.
작년 9월 말 모바일 개발팀에 합류하게 되면서부터 GS SHOP 디자인 시스템을 구축하기 시작했습니다.
디자인 시스템은 회사 내에서 많은 분들이 관심을 가지고 계시는 분야이기도 하고 전 세계적으로도 계속해서 뜨거운 이슈입니다.
Google의 Material Design, Apple의 HIG(Human Interface Guideline), Adobe의 spectrum, LINE의 LDS(LINE Design System), IBM의 Carbon Design System 등 많은 기업들이 고유의 디자인 시스템을 가지고 있습니다.
디자인 시스템은 제품을 일관되고 지속 가능하게 구축하려는 기업에 필수적입니다.
디자이너와 개발자에게 유익할 뿐만 아니라 내부 관계자들이 서비스의 원칙과 서비스 구축을 위해 표준화시키고 문서화해서 모든 것을 모아 두고 공유함으로써 작업 시에 관련자들이 작업에 대한 결정을 내리거나 의사소통 시에 유용하게 사용할 수 있습니다.
디자인 시스템이 뭐길래?
단순히 디자인 스타일 가이드를 말하는 것이 아니라 내부 관계자들이 서비스를 일관성 있게 구축할 수 있도록 도와주는 브랜드 아이덴티티, 디자인 원칙과 패턴, 개발, UX Writing, Voice & Tone과 같은 모든 것을 포괄하는 가이드를 디자인 시스템이라고 합니다.
브랜드의 가치관을 녹이고 사용자에게 일관된 경험을 만들기 위해 Color, Typography, Spacing 등과 같은 재사용 가능한 요소들을 정의한 후 각 컴포넌트에 적용시켜 코드 화하고, 기획자와 디자이너 그리고 개발자까지 다양한 직무의 인원들 모두가 협업이 가능하게 도움을 주는 디자인 가이드에서 개발까지를 포괄하는 기능 요소의 모음이라고 볼 수 있습니다.
디자인 시스템의 이점
단순히 아름다운 디자인 요소들의 라이브러리가 아닌 각 요소에는 브랜드의 정체성이 녹아 있으며 브랜드 에센스를 반영한 견고한 디자인 원칙을 기반으로 구성되어야 합니다.
디자인 시스템을 보유하면 장기적으로 많은 시간과 노력을 들이는 반복되는 작업들을 줄이고 복잡한 커뮤니케이션을 절약할 수 있으며 디자이너와 개발자 모두에게 디자인 시스템을 제공하여 워크플로를 간소화시킬 수 있습니다.
모든 서비스는 브랜드 일관성을 유지하기 위한 지침이 필요합니다.
Product를 구축할 때 필요한 룩앤필, 가이드라인과 같은 지침이 정해져 있기 때문에 결정을 위한 시간을 줄여줍니다.
브랜드의 디자인 원칙에서 벗어난 일관되지 않은 UI는 사용자에게 혼란을 가져다주고 이러한 문제는 고객에게 신뢰성과 사용성을 떨어트리게 되는 큰 문제로 다가오게 됩니다.
새로운 구성원이 추가되었을 경우에도 서비스에 관련된 내용을 한눈에 파악할 수 있도록 중앙 집중화된 디자인 시스템 관리는 작업자가 원활한 작업을 수행할 수 있도록 도움을 줍니다.
우리의 디자인 시스템은?
GS SHOP의 디자인 시스템은 Material Design을 기반으로 Apple의 iOS Human Interface Guidelines을 참조하여 추가적으로 정의를 하고 규칙을 세워 만들어가고 있습니다.
Inspiring, Social, Playful, Effortless이라는 UX 원칙을 정하고 4가지의 UX Principles 중 Effortless에 집중함으써 궁극적인 고객 경험 개선을 추구합니다. 구체적인 Effortless 실현을 위해 Grouping, Hierarchy, Focus 이 3가지 원칙을 준수하여 모든 디자인 요소들을 정의하고 관리하고 있습니다.
디자인 시스템의 설계는 화면의 구조를 원자, 분자, 유기체, 템플릿, 페이지 단위로 구성하는 Atomic Design 방식으로 설계했습니다.
이는 재사용 가능한 구성요소를 규칙 내에서 자유롭게 배치하여 유연하고 일관성이 유지되도록 하는 방법입니다.
Atomic Design에 대해서는 아래에서 다시 알아보겠습니다.
여러 명의 디자이너들이 함께 작업을 하다 보니 스타일 가이드가 있음에도 잘 지켜지지 않는 문제들이 있었습니다. 이러한 문제점을 개선하기 위해 디자인 시스템을 문서화하여 공유하고 지속적으로 업데이트하고 있습니다.
문서화의 내용에는 GS SHOP App 디자인의 기반이 되는 Color, Typography, Icon 등의 파운데이션 정의와 컴포넌트들의 기본적인 구조부터 변형 정의 및 개발과 디자인 시 적용 방법 등으로 차차 넓혀 나가고 있습니다.
디자이너들은 정기적인 모임을 가져 업데이트 내용이나 공유해야 하는 사항들을 꾸준히 공유하며 디자인 원칙을 지켜 나가기 위해 노력하고 있습니다. 각 팀 내에서 일정 기간 디자인 시스템 담당자를 지정하여 디자인 시스템 원칙이나 업데이트 내용들을 전파하는 형태로 UI 디자이너 간 협업을 진행하고 있습니다.
디자인과 개발이 서로 다른 방향을 바라보고 있다면 디자인 시스템 구축의 의미는 퇴색되고 맙니다.
디자이너가 피그마에서 디자인한 컴포넌트와 실제 개발에서 사용하는 컴포넌트들을 매핑 시켜 관리하기 위해 디자인 시스템 문서화 도구인 ‘zeroheight’에서 컴포넌트의 스펙과 사용법을 문서화하고 컴포넌트 UI 개발 툴인 ‘Storybook’을 사용하여 디자인 작업을 코드화 시키고 디자인에서 업데이트되는 내용을 스토리북에도 반영하여 업데이트해 주는 작업도 계속해서 진행하고 있습니다.
디자인 작업 툴
기존에는 스케치를 사용하여 디자인 작업을 진행하고 있었으나 합류 시점부터 피그마로 이전하면서 스케치로 작업한 디자인 작업물들을 디자인 토큰이라는 개념을 도입하여 업데이트했습니다.
피그마는 스케치에서 작업한 파일들을 Import 할 수 있어서 기존 작업 파일들을 이전하기가 편리하나, 완벽하게 이전이 되는 것은 아니었기 때문에 그러한 요소들을 업데이트하면서 Color와 Typography, Icon 요소들을 원칙에 따라 재정의하고 컴포넌트들을 토큰과 연결시키면서 진행했습니다.
피그마에는 Variant, Auto layout 등과 같은 기능들이 있는데 이를 사용하여 조금 더 코드화하기 쉬운 구조로 작업하고 있습니다.
Variant는 유사한 구성 요소를 단일 컨테이너로 그룹화하고 속성별로 구분하여 구성하는 것입니다. 이를 활용하면 구성 요소 라이브러리가 단순화되고 작업자들이 필요한 요소를 한눈에 쉽게 찾을 수 있습니다.
Auto layout은 프레임 및 구성 요소에 추가할 수 있는 속성입니다. 이를 통해 채워지거나 축소되는 디자인을 만들고 내용이 변경됨에 따라 재 정렬할 수 있습니다. 새 레이어를 추가하거나 더 긴 텍스트 문자열을 수용하거나 디자인이 발전함에 따라 정렬을 유지해야 할 때 유용합니다.
피그마는 클라우드 기반으로 따로 프로그램을 설치하지 않고 링크만으로도 작업물 확인이 가능하며 가볍고 실시간으로 여러 사람의 공동작업이 가능해서 협업이 용이합니다. 코멘트를 달수 있는 기능이 있어 피드백을 주고받기 용이하여 협업 시에 아주 유용하게 사용됩니다.
또한, 제플린 없이도 핸드오프가 가능하다는 점 등 을 장점으로 뽑을 수 있습니다.
디자인 시스템 구축 방식
앞서서 디자인 시스템 설계 방식으로 도입한 Atomic Design은 가장 작은 단위인 원자가 결합하여 분자가 되고 분자가 결합하여 유기체가 만들어지는 화학 원리를 인터페이스 디자인에 녹여 구축하는 방식을 말하는데 인터페이스에 대한 과학적 접근 방식을 고려하는 모듈식 설계 및 개발의 개념을 요약하고 있습니다.
즉, 원자, 분자, 유체, 템플릿, 페이지의 순으로 작은 것들을 결합하여 템플릿과 화면으로 만들어가는 방식으로 디자인에 접근하는 방법입니다.
Atomic Design 방식으로 설계된 디자인 시스템은 개별 구성요소에 중요성을 부여하고 구성요소들을 체계적인 패턴 내에서 자유롭게 배치하여 유연하고 일관성이 유지되도록 하는 방법을 제시해 줍니다.
원자, 분자, 유기체, 템플릿, 페이지를 실제 화면에서 추출한 요소들로 예시를 들어보았습니다.
ATOMS(원자)
사용자 인터페이스를 구성하는 기본 블록 역할로 최소 단위이지만 고유한 속성이 있습니다.
MOLECULES(분자)
비교적 단순한 UI 요소 그룹으로 목적을 가지고 있습니다. 간단한 UI 분자는 재사용이 가능하며 인터페이스 전체에서 일관성이 향상됩니다.
ORGANISMS(유기체)
분자 구성보다 복잡한 UI 구성 요소로 헤더와 같이 하나의 요소에 여러 크고 작은 인터페이스를 포함하고 있는 것을 유기체라 합니다.
TEMPLATES(템플릿)
구성요소를 레이아웃에 배치하고 디자인의 기본 콘텐츠 구조를 명확하게 표현할 수 있으며 생성한 헤더 유기체는 템플릿에 적용할 수 있습니다.
PAGES(페이지)
템플릿에서 텍스트, 이미지 및 미디어를 템플릿에 적용하며 실제 콘텐츠를 삽입하여 최종 제품을 확인할 수 있습니다.
작업 프로세스
GS SHOP의 디자인 시스템은 시각적 스타일, UI 구성 요소, 문서화, UX 패턴 등의 기능을 검색, 디자인, 빌드, 문서화 및 게시 단계를 따라 제작합니다.
- Propose
팀원들의 요청 분류, 인터뷰, 제품 및 시스템 분석, 내부 인원의 의견 요청과 같은 공식적인 제안 프로세스까지를 포함합니다. 새로운 기능의 가능성과 관련성을 명확히 하고 작업 여부를 결정합니다. - Design
반복적인 디자인 작업과 협의, 아이콘과 일러스트 같은 시각적 스타일, UI Component 또는 색상 페이지 등과 같은 규칙을 정하여 작업합니다. Figma, Illustrator 등 을 사용하여 시스템 규칙과 일치하는 요소들을 작업하며, Code 화하기에 충분한 수준의 변형, 구조, 상태 및 기타 세부 정보를 가지도록 구조화한 UI Component를 디자인합니다. - Design Documentation
디자인적 변형 및 기타 지침에 대한 문서를 1차 작성합니다.
여러 명의 디자이너들이 함께 업무를 진행하기에 생기는 업무 혼란 등을 최소화하고 제작한 UI Component에 대해 디자인적인 사용방법, 용도 등 상세 Spec에 대해 작성합니다. Figma에서 작업된 Variant 유형에 대해 상세 작성하는 것을 우선으로 합니다. - Code
코드 및 자산, 규정된 분기 내에서 관리하기 위한 Git, 주석 작업 등의 작업이 여기 해당합니다.
품질을 검토하고 범위 기능이 제대로 구현되었는지 확인합니다. 접근성을 충족하며 시스템의 코드 스타일 및 규칙을 준수하는지 검토하며 작업을 완료합니다. - Code Documentation
사용시기, 동작, 편집, 기능 및 그 변형과 관련된 기타 지침과 같은 주제에 대한 문서를 작성합니다.
기능을 올바르게 사용하기 위한 사용 시기, 동작, 비주얼 스타일, 콘텐츠 등과 같은 충분한 디자인 지침과 코드 사양을 갖게 됩니다. Component를 사용하여 화면 구성 시 어떻게 사용하는지를 전달하는 데 중점을 두고 있으며 시스템 사용자가 갈망하는 품질과 깊이에 중점을 둡니다. - Publish
문서작성이 완료되면 게시 플랫폼으로 migration 합니다.
이미지, 디자인 템플릿 및 대화형 데모와 같은 자산 업로드, 예제 데모 마무리, 링크 및 기타 게시 QA 테스트 등의 작업을 진행합니다.
디자인과 개발 거리 좁히기
심도 있는 커뮤니케이션을 위해서는 우선, 같은 언어를 사용해야 서로가 뜻하는 바가 정확히 무엇인지 알 수 있습니다.
디자이너와 개발자의 협업 또한 마찬가지입니다. 원활한 협업을 위해서는 같은 용어를 사용하는 것부터 시작해야 합니다.
상단의 이미지는 기존 GS SHOP App에서 디자인과 개발에 사용하던 GS SHOP의 Brand Color인 LeafGreen입니다.
디자인 관점에서만 보았던 색상의 네이밍이나 각 색상마다 용도가 있지만 모든 작업자들이 그 용도에 대해 직관적으로 알기 어렵고 특정 역할에 국한된 네이밍과 제외해도 되는 요소들이 포함되어 네이밍이 길고 어렵게 느껴지기도 했습니다. 같은 색상이지만 네이밍이 다른 요소들도 있어 중복의 문제도 있었습니다.
비슷하거나 의미를 알기 어려운 네이밍은 개발자와의 협업에서만 문제가 아니라 같은 디자이너들 사이에서도 어떻게 사용하는지 파악하기 어렵습니다. 이렇게 되면 일회성 사용이 반복적으로 일어나고 이는 소스의 낭비로 이어집니다.
이번 디자인 시스템을 구축하면서 많은 시간을 쏟은 부분 중 하나인데요!
디자이너와 개발자 구성원 모두가 이해하기 쉽고 단순하면서 네이밍만으로도 상상할 수 있는, 예측 가능하고 명확한 네이밍 규칙을 정해 네이밍을 통일시키기 위해 노력했습니다.
우선 간단하게 살펴보자면 아래와 같은 이름의 값이 있다고 생각해 봅시다.
네이밍은 길고 복잡해 보이지만 어떤 것을 표현하는지 뜯어서 보게 되면 쉽게 의미를 파악할 수 있고 어떤 용도로 사용이 되는지 예측이 가능합니다.
Reference, System, Component 그룹 중 System 그룹 내에서 의도하는 목적에 맞게 사용할 수 있도록 Semantic, Content, Background, Overlay, Border, State. Source 중에서 값을 지정하고 Background 그룹 내에서 Primary, Secondary, Tertiary, InversePrimary, InverseSecondary, InverseTertiary, PrimaryChrom 중에서 필요한 용도에 따라 선택하여 사용할 수 있습니다.
Color뿐만 아니라 반복적으로 사용되는 Typography, Spacing 등 같은 값을 표준화시켜 이름을 붙여준 값들을 디자인 토큰이라고 합니다.
토큰들의 이름을 읽음으로써 해당 토큰 값이 무엇을 나타내는지 디자이너와 개발자 모두 어렵지 않게 의미를 파악할 수 있습니다.
명확한 네이밍은 디자이너와 개발자의 협업에서뿐만 아니라 디자이너들이 디자인 작업을 할 때에도 유용하게 사용되어 UI/UX 디자인 시에 드는 고민의 시간을 줄여줍니다.
Component naming
컬러의 네이밍뿐만이 아니라 새로운 분들이 많이 투입되고 함께 작업을 진행함에 있어 내부 관계자들이 사용하는 Component 용어의 사용이 달라 커뮤니케이션에 오류가 있기도 했습니다.
iOS와 Android 플랫폼 간에 동일한 기능을 하는 UI Component의 명칭이 완벽하게 동일하지는 않습니다.
예를 들어 화면 상단의 뒤로 가기 버튼이 있는 Bar의 이름을 iOS에서는 "Navigation Bar", Android에서는 "App Bar"라고 합니다.
명칭의 불일치는 디자이너와 개발자 등 내부 인원 간 커뮤니케이션의 혼란을 부르고 장기적으로 보았을 때 이는 비용 문제로까지 이어질 수 있습니다.
이러한 혼란을 없애기 위해 내부에서는 iOS와 Android의 Component naming과 GS SHOP의 Component naming을 통일시켜 한눈에 확인할 수 있는 문서를 작성하여 공유하고 있습니다.
Usage
디자인 시스템에서 Core Component만 잘 만든다고 모든 것이 다 해결되는 것은 아닙니다.
가이드를 제공하여 어떤 방식으로 사용되는지 구성원들이 이해하기 쉽게 사용법을 작성해 두고 업데이트가 되면 반영하는 유지 보수를 잘해주어야 합니다. 디자인이 업데이트되었을 때 잊지 않고 스토리북도 함께 업데이트를 해주어야 비로소 디자인과 개발이 하나 되는 디자인 시스템이 됩니다.
구두로 설명하기 힘든 인터렉션과 모션은 포로토 타이핑 툴인 프로토 파이와 피그마의 프로토타입으로 개발자분들과 협의를 진행하고 있습니다.
컬러 정의
컬러는 Typography, Icon, Layout, Motion 등 같이 디자인 시스템에서 Foundation에 해당합니다. 앞에서 이야기한 네이밍 기준에 따라 컬러를 정의하는 과정에 대해 설명합니다.
Color는 브랜드 정체성을 표현하고 사용자에게 상호작용 요소를 직관적으로 이해시킬 수 있으며 버튼 같은 컨트롤에 고유의 색을 부여하고 앱의 전체 화면에 일관성 있게 사용하여 시선을 집중시키고 행동을 유도할 수 있는 중요한 역할을 합니다.
기존 프로젝트에는 다양한 색상들이 있었지만 일정한 규칙에 따라 정의되지 않거나 직관적이지 않은 네이밍으로 일회성으로만 사용이 가능한 케이스도 여럿 발견되었습니다.
이러한 문제를 해결하기 위해 컬러 정의 시에 50, 100, 200, 300, 400, 500, 600, 700, 800, 900과 같은 단계로 각 색상의 명도비를 일관되게 적용하고 시각적으로 개선이 필요한 경우 미세하게 조정하여 세부 색상들을 정의해 주었습니다.
명도 비에 따라 구성된 색상들은 접근성 기준에 적합하고 충분히 대비되도록 지정하였습니다.
GS SHOP 디자인 시스템은 예외 없이 Color System에 정의된 색상으로 모두 매핑할 수 있습니다.
인터페이스를 정의한 색상으로 제한하게 되면 제품 간 일관성이 보장될 뿐만 아니라 올바른 색상 사용에 따른 접근성이 보장됩니다. System Token의 색상들은 최소 대비에 대한 WCAG AA 접근성 요구사항을 충족하도록 정의되어 있습니다.
디자이너들의 작업환경을 방해하지 않고 제한된 범위 내에서 색상을 사용하는데 어려움이 없도록 기본 팔레트에 충분한 컬러를 제공하고 주요 색상과 보조 색상을 지정하고 참조하여 효율적인 작업이 가능하도록 해줍니다. Color System은 사용성을 고려하여 크게 Semantic, Content, Background, Overlay, Border, State, Source 구조로 나누어 필요한 요소들을 큰 고민 없이 그룹 내에서 선택하여 사용할 수 있도록 하였습니다.
디자인 토큰이란?
디자인 토큰(Design Token)은 디자인 시스템의 시각적 디자인 원자입니다. 특히 시각적 디자인 속성을 저장하는 명명된 개체입니다. UI 개발을 위한 확장 가능하고 일관된 시각적 시스템을 유지하기 위해 하드 코딩된 값(예: 색상의 16진수 값 또는 간격의 픽셀 값) 대신 사용합니다.
- 세일즈포스, 라이트닝 디자인 시스템
디자인 토큰은 Salesforce의 jina와 jon에서 시작되었으며 Color, Typography, Spacing, Animation, Component style 등 과같이 제품에서 반복해서 사용하는 디자인 시스템을 구성하고 유지하는데 필요한 다양한 디자인 정보들을 규칙에 따라 저장하여 배포할 수 있는 형식으로 패키지화한 것입니다. 최근 구글도 안드로이드 OS의 머터리얼 3.0부터 토큰을 도입하여 작업하였습니다.
비즈니스 기능에 많은 시간을 할애하려는 경우와 테마 및 멀티 브랜드 제품을 사용하려는 경우에 유용하게 사용됩니다. 여러 규칙에 의해 정의한 토큰 값들은 초반의 구축 작업 이후 작업 시에 고민의 시간을 단축시켜주어 각자의 업무에 더 집중할 수 있습니다.
하드 코딩된 값 대신 사용하여 통일성을 보장하고 유지관리가 편리하며 작업 시 디자이너와 개발자의 의사소통에 드는 시간을 단축시킬 수 있습니다. 디자인 시스템이 발전함에 따라 특정 값이 변경되며 디자인 토큰은 변경사항을 추적하고 앱 전반에 걸쳐 지속적인 일관성을 보장하는 데 도움이 됩니다.
디자인 토큰은 디자인 시스템과 제품 전반에 걸쳐 사용할 수 있어야 합니다.
원하는 플랫폼에서 사용할 수 있도록 변환이 가능하며 모든 플랫폼에서 브랜드 일관성을 보장할 수 있습니다.
디자인 토큰을 중앙 집중식으로 관리하여 제품의 일관성과 유지 관리를 원활하게 하며 어떤 플랫폼이든 대응할 수 있는 json의 형식으로 저장됩니다.
GS SHOP 디자인 토큰
GS SHOP에서는 디자인 토큰을 세 가지로 분류하여 사용하고 있습니다.
사용되는 모든 요소를 정의한 조각들을 Reference Token이라 하고 용도에 따라 사용된 토큰들을 System Token, Component 요소에 맞게 정의한 토큰을 Component Token으로 정의했습니다.
- Reference Token
Global Token으로 표현할 수 있으며 인터페이스에서 사용된 모든 Color, Typography, Spacing 등과 같은 기본이 되는 값을 정의하여 Reference Token으로 지정합니다. 콘텍스트에 구애받지 않는 이름으로 값은 #CAE72D와 같은 16진수 기본값 등을 가집니다.
Reference Token은 다른 모든 토큰 유형에서 상속되며 필요시 직접 사용할 수 있습니다. - System Token
System Token은 정의한 Reference Token을 시스템 내에서 사용하는 테마나 컨텍스트에 맞는 토큰 이름으로 지정하며 Reference Token을 System Token으로 재정의하여 의도된 목적에 맞게 사용될 수 있도록 참조시켜줍니다.
모든 System Token은 Reference Token에서 가져옵니다. - Component Token
System Token에서 정의한 값 또는 Reference Token을 참조하며 Component에 해당하는 값으로 정의한 요소를 나타냅니다.
디자인을 디자인 토큰으로
피그마 토큰은 디자인 요소들을 코드와 매핑시켜 변환해 코드화 시켜주는 피그마 플러그인으로 복잡하고 번거로운 작업을 간편하게 해주는 도구입니다.
피그마에서 Product 내부에 사용되는 Color와 Typography, Spacing 등과 같은 토큰을 만들고 피그마 토큰과 연결시켜 Github, Gitlab, jsonbin에 동기화할 수 있으며 json 파일로 Export 시켜줍니다.
피그마 토큰에서 정의할 수 있는 토큰은 Color에서 Typography, Spacing 설정까지 모두 가능하며 자세히는 sizing, spacing, color, radius, border, box-shadow, opacity, font-family, font-weight, font-size, line-height 등의 요소들을 토큰으로 정의가 가능합니다.
개발자에게는 익숙한 개념인데, 피그마 토큰은 정의한 토큰 값을 참조하여 가져올 수 있습니다. 피그마 프로젝트에서 디자인 요소들을 피그마 토큰과 연결시켜두면 특정 토큰 값을 업데이트했을 경우 연결되어 있는 값이 자동으로 업데이트되어 각각의 값을 업데이트해야 하는 번거로움을 줄여줍니다.
예를 들어, 기존에 aquaBlue500라는 값을 #00AEBD라고 사용하고, sysSourceAquaBlueLight라는 값으로 aquaBlue500을 참조하여 사용하고 있었다고 할 경우, 접근성 이슈 등으로 해당 값을 업데이트해야 하는 일이 생긴다고 가정했을 때 피그마 토큰에서 Aquablue500의 값만 #0AA4B3으로 업데이트해 주면 기존 aquaBlue500의 값을 참조하던 sysSourceAquaBlueLight의 값을 업데이트해 줄 필요 없이 참조한 값들이 한 번에 업데이트됩니다.
피그마 토큰의 또 하나의 장점은 테마 작업을 편리하게 할 수 있다는 점입니다.
기존에는 디자인 작업 시에 두벌의 같은 디자인에 하나에는 A라는 테마를 지정하고 또 다른 하나에는 B라는 테마를 적용하기 위해 각각의 색상 값을 입력하여 만들어 주는 번거롭고 혼란스러운 작업을 했었어야 했습니다. (디자이너뿐만 아니라 개발 반영 시에도 혼란스러움 😿)
피그마 토큰에서는 테마를 하나 더 추가하여 정의한 색상 중 테마가 변경됐을 시에 업데이트될 요소들을 확인하여 반영하여 주면 어렵지 않게 테마 변경 작업이 가능합니다.
테마 생성
피그마 토큰은 기존에는 샘플 값들이 참고하기에 조금은 부족한 느낌이었지만 업데이트 이후 디자이너들도 좀 더 사용하기 쉽게 업데이트되었습니다.
토큰은 Hex, RGB, RGBA, HSLA 방법을 기본으로 하여 작성할 수 있으며 Gardiant, Alpha 값 또한 지원합니다.
- Hex : #ff0000
- RGB : rgb(255, 0, 0)
- RGBA : rgba(255, 0, 0, 1)
- HSLA : hsla(120, 50%, 50%, 1)
테마 적용을 위해 Light 테마와 Dark 테마를 만들어보겠습니다.
디자인 시스템 구축의 틀이 되는 기초를 만들기 위해 플러그인을 실행하고 기본 설정을 가지고 오거나 이미 작업을 진행하고 있었다면 스타일을 로드해서 가지고 올 수도 있습니다.
Global set 내부에는 디자인 토큰 중 Reference Token을 정의해 준다고 생각하면 됩니다.
Reference Token에서는 참조할 값을 만들어주는 것이기 때문에 Hex, RGB, RGBA, HSLA 값으로 입력해 줄 수 있습니다.
New set으로 새로운 Theme set을 만들고 각각을 Light/Dark로 이름을 지정해 줄 것입니다.
여기에서는 Light 테마를 Default 테마로 하여 테마 레벨에서 필요한 값들을 글로벌 토큰 내부에 있는 값들을 참조하여 지정해 줍니다.
Reference Token에서 정의해 준 {ref.gray.900}의 값을 상단 이미지와 같이 System token의 content 그룹 안에 primary 값으로 넣어줍니다.
이러한 형식으로 Light Theme에 필요한 토큰 값을 참조하여 작성해 줍니다.
Light 테마의 구축이 완료되었다면 Dark 테마를 만들어보겠습니다.
name은 Dark로 지정해 주고 이 내부에는 Dark 테마에 해당되는 내용을 정의하겠습니다. Light 테마의 json 파일을 복사하고 방금 생성한 Dark 테마 코드 파일에 추가하고 저장해 줍니다.
이제는 Light 테마에서 참조하고 있던 값들을 변경시켜주어야 합니다.
다크 테마는 배경이 어두운 색으로 변경되기 때문에 내부 콘텐츠들은 읽을 수 있도록 대비를 고려하여 밝은 색상으로 변경시켜 줍니다.
Content와 Background의 값들을 접근성에 맞게 변경하고 나머지 값들도 업데이트가 필요한 부분들을 업데이트해 줍니다.
이제 Github에 작업한 내용을 연결시켜 작업한 내용을 업로드시켜줍니다.
이로써 디자인 값을 하나하나 변수화하여 연결시켜 주어야 하는 번거로운 과정을 ‘push to github’ 버튼 하나로 해결할 수 있습니다.
연결한 Git으로 이동하여 연동시킨 내용이 제대로 업로드되었는지 확인해 줍니다. 내용이 업데이트될 때 commit과 push 과정을 진행하여 동기화시켜주도록 합니다.
작업한 테마를 피그마에서 퍼블리쉬하여 라이브러리로 만들고 Light와 Dark 테마로 라이브러리 스와이프 기능을 통해 테마 교체를 할 수 있습니다.
Dark 테마는 향후 네이티브 영역이 확장되고 디자인 시스템의 실제 반영 영역이 확대될 경우 적용될 수 있습니다.
상단은 GS SHOP의 실제 홈 탭 디자인 화면을 피그마로 테마 적용해 본 테스트 이미지입니다.
Default 테마는 Light 테마이며 Dark 테마로 변경 시 배경 색상이 변경되면서 내부 콘텐츠 색상과 shadow 등의 요소들이 변경되는 것을 확인할 수 있습니다.
이러한 테마 변경 작업이 가능한 이유는 각각의 값들을 토큰화 시켜 컴포넌트에 매핑을 해 놓았기 때문에 테마를 변경함에 따라 해당하는 요소들의 값을 스와이프 하여 변경시켜주기 때문입니다.
아무리 완벽한 디자인이라도 개발에 실제 반영되지 않으면 아무런 의미가 없습니다.
같은 네이밍을 사용하고 디자인과 개발을 동기화시킴으로써 디자이너와 개발자, 서로의 거리도 한 걸음 더 가까워졌을 거라 생각해 봅니다!
디자인 작업물 코드 변환
Github로 Export 시켜준 디자인 토큰을 개발에 적용하기 위해서는 사용하는 플랫폼의 형태로 변환하는 과정을 한 번 더 거쳐야 하는데 이때 Style Dictionary를 사용하여 변환해 줍니다.
Style Dictionary는 플랫폼마다 사용되는 언어가 달라서 작업한 스타일을 다른 플랫폼에서 사용하려면 재정의를 해야 하는 번거로움을 해소시켜주는 시스템입니다.
사용자 경험을 관리할 때 스타일을 일관되게 유지하고 여러 개발 플랫폼에서 적용시키려면 번거로운 작업들이 필요했으나 Style Dictionary는 단일 소스에서 모든 플랫폼에 걸쳐 스타일 정의를 자동으로 생성하여 비효율을 제거해 줍니다.
확장 가능하고 모듈식이며 스타일 사전에서 작업한 파일 하나로 iOS, Android, CSS, JS, HTML, 스타일 문서 등 다양한 형식의 파일로 export가 가능합니다.
아래는 Style Dictionary로 Flutter에서 적용할 수 있는 형식으로 변환한 값의 일부분이며 스토리북 작업에 적용하여 컴포넌트들을 만들어가고 있습니다.
좋은 디자인 시스템은?
좋은 디자인 시스템은 일관성을 유지시켜주고 의사결정에 대한 지침을 명확하게 제시해 주며 디자인에서 개발까지 이어져 통합적으로 관리되고 유지 보수되는 디자인 시스템이라고 생각합니다.
아무리 좋은 디자인이라도 개발에 제대로 반영이 되지 않으면 의미가 없습니다.
작업이 계속 진행됨에 따라 업데이트되는 내용들이 많이 생길 텐데 이 부분들에 대해 끝까지 유지 보수에 신경 써야 합니다.
좋은 디자인 시스템을 만들기 위해 규칙과 원칙을 정하지만 바쁘게 작업이 반복되면서 초반에 정의했던 원칙들이 잘 지켜지지 않고 무의미해질 수 있습니다.
이런 가슴 아픈 일들이 없도록 정의된 디자인 시스템이 어떤 내용이 있는지 확인하고 내부 작업자들 서로 지켜나가야 할 것입니다.
지금까지의 내용들은 작업에 대한 정답이라기보다 디자인 시스템 작업을 하면서 겪었던 과정들을 정리해 과정을 공유했다고 봐 주시면 좋겠습니다.
앞으로는?
계속해서 GS SHOP App의 디자인 시스템을 업데이트하며 반복적이고 공통적으로 사용되는 요소에 대한 재작업을 없애고 작업에 최적화된 투명하고 명확한 디자인 시스템을 설계하는 것을 목표로 가지고 있습니다.
향후에는 모션과 사용자 인터렉션을 강화하여 더 나은 사용자 경험을 제공하는 GS SHOP App이 될 수 있도록 개선하고 발전시켜 나가려 합니다.
현재는 피그마로 컴포넌트들을 디자인하고 피그마 토큰으로 디자인 토큰을 적용한 디자인 컴포넌트들을 팀 내 퍼블리셔 분들과 함께 플러터로 스토리북 제작 작업을 진행하고 있는데 하나씩 만들어져 가는 과정이 흥미롭습니다.
많은 분들이 함께 지켜봐 주셨으면 좋겠습니다.
디자이너와 개발자가 서로 척하면 척하는 사용하기 편리한, 디자인 친화적인 그리고 개발 친화적인 디자인 시스템을 만들고 공유하는 것이 목표입니다.
최종적으로 그리는 그림은 디자이너분들과 개발자분들 그리고 GS SHOP 관련자 모두가 이 디자인 시스템을 사용하여 업무를 효율적으로 진행하여 업무의 무게를 줄여드리고 고객에게 만족스러운 경험을 제공하여 GS SHOP App의 경쟁력을 높이는데 기여하고 싶은 바람입니다.
언제든지 디자인 시스템과 관련한 문의사항이 생기면 편하게 문의주세요.
긴 글 읽어주셔서 감사합니다! 🙇🏻♀️
이인영 | 뉴테크본부 > FO Product 부문 > Mobile 개발팀
UXUI 디자인 / 퍼블리싱 / GS SHOP APP 디자인 시스템 구축을 담당하고 있습니다.
협업하여 효율적으로 일하는 것과 새로운 기술을 습득하는 것에 관심이 많습니다.
참고 자료
Atomic Design Methodology https://atomicdesign.bradfrost.com/chapter-2/
Figma Tokens https://docs.tokens.studio/
Creating design systems with Figma Tokens https://uxdesign.cc/creating-design-systems-with-figma-tokens-31686b8d672e
Style Dictionary https://amzn.github.io/style-dictionary/#/
Material Design https://m3.material.io/
Figma https://www.figma.com/
Introduction to design tokens https://specifyapp.com/blog/introduction-to-design-tokens
Design System Features, Step by Step https://eightshapes.com/articles/design-system-features-step-by-step/
'Design' 카테고리의 다른 글
| [d'sco] 디스코 시선으로 알아본 디자인 트렌드 (7) | 2022.06.14 |
|---|---|
| [d’sco] 디자인시스템 어디까지 해봤니? (6) | 2022.05.10 |
| 인터랙션 디자인 탐구생활 그리고 d'sco 행사 엿보기 (5) | 2022.04.05 |
| 디자인 시스템을 활용하여 기간계 웹화면 개발 생산성 높이기 (0) | 2021.11.15 |