디자인 시스템, 실제로 어떤 결과물이 나오나요?
피그마 중심의 워크 프로세스
근래의 디자인 시스템은 단순 가이드를 넘어 실시간 공유되는 도구의 모음으로 발전했습니다. 디자인 시스템의 결과물 또한 정적인 문서를 넘어 동적인 체계, 재사용성 높이는 UI 개발 프로세스 자체에 가까운 의미로 변화하게 되었습니다.
하지만 디자인 시스템이 고도화 될수록 처음 이 시스템을 도입하는 입장에서는 그 실체를 이해하기 어려운데요, 이 글은 디자인 시스템에 대한 초심자 이해를 돕기 위해 피그마를 중심으로 한 예시를 통해 동적인 체계로서의 디자인 시스템 산출물에 대해 다룹니다.
결과물 1 : 디자인 토큰 (Design Tokens)
→ 도구 : 피그마 배리어블 (Figma Variables)
디자인 토큰은 최소 단위의 시각적 속성에 이름을 붙여 정리한 결과물입니다.
반복적으로 사용되는 색상이나 타이포그래피, 간격 등의 값을 골라내어 이름을 붙인 후, 이름표가 붙은 속성들을 사용하여 인터페이스를 디자인 함으로써 재사용성을 극대화하기 위한 목적으로 만듭니다. 토큰은 디자인 시스템의 가장 기초적인 결과물이라고 볼 수 있습니다.
피그마에서 디자인 토큰을 정의하기 위해서는 피그마 고유 기능을 활용하거나 서드 파티 플러그인을 사용할 수 있는데요, 추천하는 방법은 피그마 고유 기능인 배리어블을 사용하는 것입니다. 배리어블은 스타일 팔레트보다 다양한 속성을 유연하게 다룰 수 있는 장점이 있으며, 서드 파티 플러그인을 사용할 때의 비용과 호환성 문제를 줄여주기 때문입니다.
Material Design 3 - 피그마 배리어블을 활용한 디자인 토큰 예시결과물 2 : 컴포넌트 라이브러리 (Component Library)
→ 도구 : 피그마 팀 라이브러리(Figma Team Library)
컴포넌트 라이브러리는 디자인 시스템의 핵심입니다. 라이브러리로 만든 컴포넌트는 새 프로젝트에서 그대로 불러와 사용할 수 있습니다. 라이브러리는 개발과 디자인 파트에서 각각 구축해야하며, 디자인 파트는 피그마에서 팀 라이브러리를 활용하여 배포할 수 있습니다.
배포된 컴포넌트 라이브러리는 다음과 같은 방법으로 새 프로젝트에서 쉽게 불러와 사용할 수 있습니다.
새 문서 만들기 → 팀 라이브러리 불러오기 → 탐색/검색 → 드래그앤 드랍 → 컴포넌트 사용
피그마를 활용한 컴포넌트 라이브러리 예시결과물 3 : 스타일 가이드 (Style Guide)
→ 도구 : 피그마 (Figma), 제로하이트 (Zeroheight)
가이드는 '풀어 설명한 글과 그림'을 의미합니다. 라이브러리는 '가져다 쓰는 것', 가이드는 '가져다 쓸 때 참고하는 매뉴얼' 이라는 측면에서 둘은 구분됩니다.
가이드는 ①스타일 가이드와 ②API 가이드로 구분할 수 있습니다.
스타일 가이드는 기획자와 디자이너를 위한 문서이며, API가이드는 개발자를 위한 문서입니다.
스타일 가이드작성 도구는 선택지가 비교적 다양합니다. 이 작업에 가장 특화된 도구는 제로하이트이지만, 학습 곡선과 비용을 고려하면 피그마나 노션도 좋은 선택입니다.
Material Design 3 - 스타일 가이드 예시결과물 4 : API 가이드
→ 도구 : 스토리북 (Storybook)
API 가이드는 개발자를 위한 문서입니다. 컴포넌트마다 어떤 속성이 있는지, 어떻게 사용하는지 설명합니다.
가장 인기 있는 도구인 스토리북을 활용하면 컴포넌트 단위의 문서를 만들고, 마우스를 올리거나 클릭했을 때 디자인 변화를 바로 테스트해볼 수 있습니다. 스토리북은 웹 브라우저에서 누구나 쉽게 확인할 수 있습니다.
Adobe Spectrum UI - 스토리북을 활용한 API 가이드 예시결과물 5 : 코드화 된 디자인 토큰
→ 도구 : 스타일 딕셔너리 (Style Dictionary)
디자인-코드 적용 프로세스를 개선하는 일도 중요한 결과물입니다. 디자인 토큰을 JSON 파일로 관리하면 빠르고 정확하게 코드화 할 수 있으며 변경도 쉬워집니다. 피그마 배리어블을 JSON 파일로 추출 한 후 스타일 딕셔너리를 활용하여 플랫폼에 맞는 스타일 시트로 변환할 수 있습니다.
피그마에서 추출한 토큰을 css로 변환한 예시결과물 6 : 코드-디자인 일관성 검토
→ 도구 : 스토리 투 디자인 (story.to.design)
토큰을 넘어 컴포넌트 단위에서도 디자인-코드 일관성을 확보하려면 많은 노력이 필요합니다. 디자인-코드가 통합된 프레이머와 같은 도구를 사용하지 않는 한, 컴포넌트 하나하나를 디자이너가 검토해야하는 작업을 피할 수 없습니다.
검토는 스토리북이나 테스트 화면 등 어디에서나 가능하지만 스토리 투 디자인을 사용하면 컴포넌트를 피그마에 불러와 빠르게 검토할 수 있습니다.
스토리 투 디자인을 활용한 UI 검토 예시결과물 7 : 디자인 시스템 변경 영향 관리
→ 도구 : 크로마틱 (Chromatic)
크로마틱은 UI 스냅샷을 찍어 변경사항을 비교할 수 있는 도구입니다. 디자인 시스템을 업데이트 할 때, 기존 화면에 미치는 영향을 관리하려면 이 도구를 프로세스에 포함하면 됩니다.
크로마틱을 활용한 변경 관리 예시"디자인 시스템은 작업 포트폴리오가 아니라
디자이너와 개발자가 더 빠르게 작업할 수 있는
기능적 툴킷 또는 리소스로 생각해야 한다.
- NNgroup, Design System 101"
디자인 시스템은 구성원들이 쉽게, 효율적으로 사용할 수 있야합니다. 디자인 시스템 자체가 디자이너와 개발자가 사용하는 도구이자 업무의 생산성을 향상하기 위한 수단이기 때문입니다. 이 글의 사례는 피그마를 중심으로 한 하나의 예시일 뿐, 더 다양한 도구와 워크 플로우를 검토해볼 수 있습니다. 중요한 것은 생산성을 최적화할 수 있는 규모와 방법을 채택하는 것입니다. 그러면서도 특정 도구에 지나치게 의존하지 않도록 주의하는 것이 중요할 것 같습니다.
