안녕하세요, 피처링의 프로덕트 디자이너 Sini입니다🙂
이번 글에서는 약 1년 전, 피처링에서 디자인 시스템을 새롭게 구축하게 된 계기와, 그 이후 실제 제품에 적용하며 얻은 경험들을 공유하고자 합니다.
2024년, 피처링은 신규 서비스 ‘데이터이펙트’의 런칭과 함께, 기존 서비스 ‘피처링’의 일본 시장 진출을 본격적으로 준비하며 빠르게 성장하는 시기를 맞이했습니다. 제품과 시장이 동시에 확장되는 환경에서 디자이너와 개발자 간 협업 효율은 무엇보다 중요한 과제가 되었습니다.
하지만 당시 내부 디자인 시스템은 화면 단위의 일회성 설계가 많아 재사용이 어렵고, 컴포넌트 크기나 스타일 또한 정보 밀도가 높은 B2B 환경에 적합하지 않아 개선이 필요하다는 판단을 하게 되었습니다.
이에 따라 디자인팀과 FE팀은 기존 디자인 시스템의 구조적 한계를 보완하고, 우리가 지향하는 사용자 경험과 개발 효율을 체계적으로 구현하기 위해 디자인 시스템을 전면 재설계하게 되었습니다.
디자인 시스템은 무엇이고, 왜 중요한가
디자인 시스템은 디자이너와 개발자, 그리고 제품을 만드는 모든 사람들이 공통된 기준으로 협업할 수 있게 하는 커뮤니케이션 도구로서, UI 구성 요소들을 토큰, 컴포넌트, 패턴 등으로 체계화한 가이드입니다.
제품이 확장되거나 구성원이 많아질수록 디자인의 일관성과 개발의 생산성은 점점 유지하기 어려워지게 되는데, 디자인 시스템을 통해 이러한 문제를 해결할 수 있습니다.
디자인 시스템이 중요한 이유를 정리해보자면 다음과 같습니다.
- 디자이너 <> 개발자 <> 메이커들 간의 언어 통일
– 디자인 요소에 대한 용어와 컴포넌트 정의가 명확해져 여러 직군 간의 커뮤니케이션 비용이 줄어듭니다. - 일관된 사용자 경험 제공
– 여러 서비스, 프로젝트 간의 스타일, 패턴 등을 유지할 수 있어 브랜드의 일관성을 유지할 수 있습니다. - 재사용성과 생산성 향상
– 매번 반복적으로 UI를 새로 만들 필요 없이, 등록된 컴포넌트를 활용하는 방식으로 디자이너와 개발자 모두의 작업 속도가 향상됩니다. - 유지보수의 효율성
– UI 요소들이 시스템적으로 연결되어 있기 때문에 전체적인 수정사항 반영 및 관리가 용이합니다.
초기 구축 과정
디자인 토큰 (token)
디자인 시스템 구축의 첫 걸음은 바로 ‘디자인 토큰(token)’을 이해하고 정의하는 것이었습니다.
당시 디자인팀과 FE팀 모두가 토큰에 대해 대충은 이해하고 있지만 실제 시스템에 적용하는 것이 낯설었기 때문에, 먼저 토큰의 개념부터 학습하는 시간을 가졌습니다.
디자인 토큰(token)은 Color, Typography, Icon, Spacing, Elevation, Radius 등과 같은 스타일의 기초값(=Foundation)을 변수로 정의한 시스템의 최소 단위로, 이러한 값들을 이름과 규칙으로 정의해두면, 디자이너는 물론 개발자도 동일한 기준으로 UI를 구현할 수 있습니다.
디자인 토큰은 디자이너와 개발자 모두가 쉽게 사용하고 이해할 수 있도록 네이밍하는 일이 가장 중요했습니다. 따라서 토큰에 대한 티어(Tier)를 Global / Semantic / Component 세 가지로 나누었습니다.
- Global Token : 가장 기본적으로 정의된 토큰.
- 예) g-color-primary-60, g-radius-50
- Semantic Token : Global Token을 사용해 재정의 된 토큰. 역할이나 상태 등 ‘의미’를 전달하는 이름으로 구성됨.
- 예) s-color-background-1, s-color-support-error
- Component Token : 특정 컴포넌트에서만 사용되는 토큰. ring system의 경우 global을 재정의하였고, 특정 컴포넌트 내에서만 사용되고 있음.
- 예) c-color-tag-primary-default, c-color-button-primary
위 세 티어에 따라 네이밍 구조를 다음과 같이 설정하였습니다. (피그마나 코드 상에서는 tier와 category 없이, depth만 축약하여 주로 사용하였음)
–{tier}-{category}-{depth1}-{depth2}…
디자인 시스템 설계 방법
디자인 토큰을 이해한 뒤 본격적인 디자인 시스템 설계는 Atomic Design 원칙에 따라 진행되었습니다.
먼저 디자인 토큰을 활용한 Foundation들을 설계하고, 이들을 활용해 Component를 구성하였습니다. 이후 실제 화면 작업을 진행하면서 자주 보이는 Component 구성을 Pattern, Template, Feature 순서로 활용했습니다.
디자인 시스템을 처음 설계하며 가장 어려웠던 점은 기존 레거시들을 고려하지 않고, 미래에 새로 개발될 기능들을 상상하며 디자인 시스템을 설계해야 했던 점입니다. 새롭게 출시할 ‘데이터이펙트’에도 동일한 디자인 시스템이 사용되어야 했기에, 기능 개발과 병행하며 확장성 있는 디자인 시스템을 만드는 것이 커다란 과제였습니다.
이 과제를 해결하고자 먼저 여러 B2B SaaS 서비스들의 디자인 시스템을 살펴보고, 피처링의 서비스들에도 적용할 수 있는 특징들을 참고하며 디자인 시스템을 제작하기 시작했습니다. 이렇게 레퍼런스를 참고하여 제작한 초안을 기존 피처링 화면에 얹혀 보며 테스트를 진행하였고, 이 과정을 통해 Foundation, Component 등을 좀더 안정적으로 제작할 수 있었습니다.
* 주로 참고한 레퍼런스 목록
레퍼런스를 어떤 방식으로 참고하며 초안을 제작했는지, Typography를 설계한 사례를 통해 그 방법을 간단히 소개해보겠습니다.
먼저 Typography의 구조를 이해하고, 다양한 사용성을 비교해보기 위해 여러 B2B SaaS 서비스들의 Typography 시스템을 조사하였고, 이를 한눈에 볼 수 있는 하나의 표로 정리했습니다. 이후 서비스마다 사용 중인 텍스트 스타일, 계층 구조, 적용 방식 등을 화면별로 직접 살펴보며, 표에 정리된 Typography가 어떤 화면에서, 어떤 스타일과 역할로 쓰이는지를 분석했습니다. 이 과정을 통해 피처링의 화면 구조와 콘텐츠 특성에 맞는 텍스트 스타일, 계층 구조 초안을 설계했고, 실제 피처링의 화면 위에 초안으로 제작된 heading, body 스타일을 테스트해보며 Typography System을 정립하였습니다.
여러 레퍼런스를 통해 디자인 시스템의 초안을 제작해본 경험은 검증된 구조를 기반으로 시작할 수 있어 속도가 빨랐을 뿐만 아니라, 여러 레퍼런스를 나란히 비교해보며 우리에게 필요한 스펙에 대한 판단 기준을 세우는데 큰 도움이 되었습니다.
특히, 누락된 항목이나 예외 케이스에 대해 미리 파악할 수 있어서 처음이지만 비교적 안정적인 시스템을 설계할 수 있었습니다.
계단식 컴포넌트 구조(Cascading Components)를 활용한 피그마 세팅
디자인 시스템 설계 과정에서 가장 심혈을 기울인 동시에, 가장 까다로웠던 작업이 바로 Figma 세팅이었습니다.
한 번 세팅된 디자인 시스템은 이후 수많은 화면 작업에 활용되기 때문에, 초기 구조가 잘못 잡히면 전체 시스템을 무너뜨릴 수 있어 처음 세팅 단계에서 많은 고민과 실험이 필요했습니다.
특히 다양한 상태(status)와 상황(state)를 고려해야 하는 컴포넌트의 경우, 단 한 번의 설정 실수로 인해 모든 variant UI를 수정해야 하는 경우도 많아, 예상보다 훨씬 많은 시간이 소요되기도 했습니다.
그래서 선택한 설계 방식이 ‘계단식 컴포넌트 구조(Cascading Components)’입니다.
계단식 구조는 컴포넌트를 설계할 때 상위 요소부터 점차 세분화되는 위계 구조(hierarchical structure)를 활용한 방식입니다. (참고 자료: Cascading Components: a different way to organize Figma variants)
Button 컴포넌트의 제작 과정을 예시로 들자면, 계단식 구조 없이 모든 케이스들에 대한 UI를 시스템화 했을 때 다음 이미지처럼 컴포넌트가 구성될 수 있습니다.
하지만 여기서 문제는 Label이나 Icon처럼 모든 variant에 공통으로 들어가는 요소의 스타일이 조금이라도 바뀌면,
총 54개의 버튼 variant에 각각 들어 있는 요소를 모두 직접 수정해야 하는 상황이 발생합니다. (참고로 Button은 variants의 수가 비교적 적은 편에 속합니다…)
이럴 때 유용한 방식이 바로 계단식 컴포넌트 구조(Cascading Components)입니다.
위 이미지처럼 컴포넌트를 base, style 단위로 나누어 제작한 뒤, 이를 조합하여 최종 Button 컴포넌트를 구성하면,
전체 variant 수를 크게 줄이면서도 각 속성을 시스템적으로 관리할 수 있습니다.
실제로 이 구조를 적용했을 때, 총 54개의 variant로 구성되던 버튼도 단 14개의 variant만으로 동일한 속성과 상태를 모두 표현할 수 있었습니다.
(여담이지만 계단식 컴포넌트 구조를 알기 전에는 피처링의 Button도 몇 개인지 세지도 못할 개수의 variants로 구성됐던 적이 있습니다…)
피처링 디자인 시스템 중 계단식 컴포넌트 구조를 잘 활용한 예시로는 text input이 있습니다.
label과 validationIcon, textInput, inputContainer, options 그리고 variants까지 총 6가지 종류의 컴포넌트를 조합하여 하나의 text input이라는 컴포넌트를 구성하였고, 각 컴포넌트별로 수정 사항을 반영할 수 있어서 유지보수가 굉장히 용이하였습니다.
이처럼 계단식 구조를 도입하면서, 가장 크게 느낀 변화는 관리 편이성이었습니다.
변경이 잦은 요소들을 base 단위에서만 수정하면 전체 컴포넌트에 자동 반영되기 때문에, 디자이너 입장에서는 수정 작업이 훨씬 수월해졌고, 개발자 역시 매번 새로운 컴포넌트를 일일이 구현하는 수고 없이 일관된 구조 안에서 컴포넌트를 관리할 수 있었습니다.
마치며..
디자인 시스템을 이렇게 본격적으로 제작해본 것은 처음이라 우여곡절도 정말 많았습니다.
좋은 레퍼런스를 선별하는 일부터, 수많은 컴포넌트들을 구조화하고, 계단식 구조라는 설계 방식을 발견하기까지.. 매 순간이 시행착오와 선택의 연속이었다고 느껴집니다.
하지만 그 과정을 통해 피처링 팀은 단순한 UI 정리를 넘어, 우리가 추구하는 사용자 경험과 개발 효율을 실현할 수 있는 기준과 구조를 갖추게 되었습니다. 디자인 시스템은 지금도 계속 다듬어지고 있지만, 앞으로 기능이 추가되거나 새로운 서비스가 개발될 때, 더 빠르고 유연하게 대응할 수 있는 기반이 되리라는 확신이 생겼습니다.
디자인 시스템은 완성된 결과물이 아니라, 팀이 더 잘 일하기 위한 구조를 함께 만들어가는 과정이라는 걸 이번 프로젝트를 통해 체감하게 되었고, 이 경험이 비슷한 고민을 하고 있는 분들에게 작게나마 참고가 되었으면 좋겠습니다.
읽어주셔서 감사합니다.
참고 자료
- https://bradfrost.com/blog/post/extending-atomic-design/
- https://uxdesign.cc/cascading-components-a-way-to-organize-figma-component-variants-5c272b4ad7ab
등록된 댓글이 없습니다.