Back

디자이너를 위한 디자인시스템,

개발자를 위한 디자인시스템

들어가며

안녕하세요. TOKTOKHAN.DEV 프로덕트 디자이너 수지입니다.

디자인시스템이란 디지털 제품에서 디자이너와 개발자가 공용으로 활용할 수 있는 하나의 언어 형태로서, 디자인 원칙, UX 패턴, UI 툴킷, 코드(Code) 등이 전부 포함되는 **'시스템 라이브러리'**를 의미합니다.

디자인과 프론트 단계에서 공용으로 관리되는 컴포넌트들을 활용해 효율적으로 커뮤니케이션 할 수 있고, 이를 통해 프로덕트 작업 시간을 단축하며, 사용자 경험과 로직에 집중해 구축 과정을 동기화 할 수 있는 효율적인 도구입니다.

지난 10월 부터 똑똑한개발자에서는 내부 디자인시스템 구축을 위한 디자인 정의 및 컴포넌트 개발 과정이 이루어졌습니다.

디자이너의 입장에서, 또 개발자의 입장에서 서로에게 더 시너지를 낼 수 있는 디자인시스템에 대한 아젠다가 명확했기 때문에, 프로덕트와 사용자 경험에 좀 더 집중할 수 있도록 초반부터 구체적인 목표를 설정, 프로젝트와 병행하며 진행하게 되었습니다.

현재 TOKTOKHAN.DEV는 Figma Library Assets로 이루어진 공통의 Parent Design System 산하에, 제품마다 별도의 디자인시스템을 구축해 관리하고 있습니다. 각 제품 별 브랜드 가이드에 따라 컬러, 로고 등의 일부 요소를 간단하게 변경 적용하면 Parent System과 손쉽게 동기화 되는 형태로 구축, 관리합니다.

지난 8개월 간 이루어진 Tok.D 디자인시스템(Beta) 버전의 정의와 구축 과정, 베타 오픈 관련사항에 대해 소개합니다.

1) Tok.D 구축 배경

디자이너 입장에서는 다음과 같은 Agenda가 존재했습니다.

플랫폼 특성상 반복적으로 사용되는 컴포넌트, 페이지를 디자이너마다 매번 새로 다시 제작함.
비교적 우선순위가 낮은 페이지(ex. 공지사항, 설정 등)에 소모되는 시간에, 제품 전반의 사용자 경험에 더 집중하고 디벨롭하고 싶음.
디자인 팀 내부에서 공유된 재사용 컴포넌트는 정해진 가이드라인이 없어 디자이너마다 아웃풋이 조금씩 다르게 완성됨. 결국 재사용과 관계없이 개발자는 매번 새로 컴포넌트를 개발해야 했음.
웹앱 특성상 반응형에 대응해야 하는데, 반복되는 레이아웃의 경우에도 구체적인 페이지 디자인이 없으면 개발자가 임의대로 반응형 화면을 작업할 수 없었기 때문에 일일이 디자이너가 작업해 전달해야 했음. 이 과정에서 비효율적인 시간이 소모됨.

개발자의 경우에도 마찬가지였죠.

디자이너가 재사용을 했는지 아닌지, 개발자끼리 어떤 컴포넌트를 어디에 사용했는지 공유되지 않아, 동일한 컴포넌트를 제품마다 매번 새로 개발함.
디자인이 빠르게 끝나도 프론트 시간이 오래 걸려, 제품 출시 및 유저 테스트 또는 데이터 수집 후 디벨롭이 되기까지 오랜 시간이 소요됨.
디자이너가 재사용한 컴포넌트 또는 Color, Spacing 등의 요소가 개발 과정에서 효율적으로 전달되지 않아, 비효율적인 확인 절차 및 질문이 반복됨.
같은 디자인 컴포넌트도 개발자에 따라 구현 아웃풋이 달라지고, 몇 번의 소모적인 QA 과정이 반복됨.

이와 같은 아젠다를 취합해, 크게 세가지를 목표로 디자인시스템을 구축하게 되었습니다.

디자이너-개발자 간 효율적인 컴포넌트 재사용 및 공유를 통해, 제품 전반의 사용자 경험에 더 집중할 수 있는 시스템을 구축한다.
최종적으로는 플랫폼에 최적화 된 템플릿 형태로 시스템을 구축해, 각 컴포넌트를 반응형 환경에 동기화 시켜 대응할 수 있도록 한다. (ex. 디자이너가 모바일 컴포넌트를 디자인하면, 따로 PC 디자인이 없어도 개발자는 가이드라인에 맞춰 한 번에 반응형을 구축할 수 있다.)
Figma - Storybook - Notion 가이드라인 연계를 통해, 라이브러리 형태로 공유 가능한 오픈디자인(Open Design) 시스템을 구축한다. 플랫폼에 특화된 최소한의 가이드를 제공해 다양한 프로덕트에서 다양한 사람들이 시스템을 활용할 수 있도록 한다.

2) Tok.D 정의

Design Principle & Pattern

앞서 설정한 세 가지 목표에 맞춰 디자인 원칙을 정의합니다.

1) 디자이너-개발자 간 효율적인 커뮤니케이션과 공유, 2) 반응형 환경에 동기화 시켜 대응할 수 있는 템플릿 형태의 시스템을 구축하기 위해 아래와 같은 원칙을 정의했습니다.

일관성 : 제품 전반에서 컴포넌트가 통일성 있게 조합되며, 제품에서 느껴지는 일관성을 유지할 것.
확장성 : 다양한 조합과 반응형 환경에 대응 가능한 확장성을 가지고 있을 것.
효율성 : 디자이너와 개발자가 효율적으로 소통하며 컴포넌트를 관리 및 수정할 수 있을 것.

2**) 라이브러리 형태로 공유가능한 '오픈디자인(Open Design)' 시스템 구축**을 위해 아래와 같은 디자인 패턴을 구성합니다.

재사용성 : 제품의 특성에 맞게 대응해 시스템 가이드를 제공하며, 다양하게 적용해 활용할 수 있을 것.
운용성 : 디자인 및 코드 상에서, 간단한 조작 및 변경으로 컴포넌트 조합과 시스템 가이드 재적용이 가능하게 구성할 것.

Atomic Design

아토믹 디자인 방법론을 적용해 시스템 단위를 구축합니다.

Tok.D에서는 가장 작은 단위의 Elements인 Core System > Core 요소들을 조합한 Example > 페이지 단위로 Example이 조합 된 Template. 세 가지 단계로 시스템을 정의해 구분하고 있습니다.

가장 작은 요소인 Core Elements에서 시작해 템플릿과 페이지로까지 컴포넌트가 확장됩니다. 이와 같은 아토믹 디자인 단위를 활용하면, 누구나 쉽게 페이지 단위로 반응형 디자인 또는 플랫폼을 구성하고, 몇 번의 조합으로 다른 구성의 에셋을 활용할 수 있게 됩니다.

3) Tok.D 구축과정

Design Process

아토믹 디자인으로 단위를 논의하면서, 개발자와 디자이너는 각각 아래와 같은 프로세스로 시스템을 구축하게 되었습니다.

디자이너의 입장에서는 '이미 완성했던 제품의 디자인에서 주로 쓰이는 요소'를 분류, 취합해 시스템 컴포넌트를 만들고 있었기 때문에, 가장 큰 단위인 Template(Page)에서 시작하는 프로세스가 좀 더 효율적이었습니다. 페이지 단위에서 컴포넌트의 상호 레이아웃과 Spacing을 고려해 에셋을 구성하고, 이후 Example, Core의 작은 단위로 컴포넌트를 쪼개 분류 배치하며 Assets Library를 구성하게 되었습니다.

반대로 개발자의 경우, Example / Template 단위의 시스템 구축을 위해선 필수적으로 Core System 컴포넌트 구축이 선행되어야 했습니다. 결국은 Core의 조합이 Example / Template로 확장되는 것이기 때문이었죠.

따라서 디자이너와 개발자가 서로 마주 보는 위와 같은 프로세스로 시스템을 구축하게 되었습니다.

Components 분류

1차적으로 기존에 적용되었던 디자인 및 레이아웃에서 자주 활용되었던 에셋 위주로 컴포넌트를 분류하고 취합했습니다. 이 과정에서 중복되거나 반복되는 요소를 선택적으로 채택하고 수정합니다. 이후 플랫폼에 최적화 된 UI 구성으로 Page 단위부터 순차적으로 쪼개며 Core Elements를 구성합니다.

Assets Rabeling

효율성 확장성을 고려하며 각 컴포넌트의 레이블링 과정을 거칩니다.

디자이너와 개발자가 모두 알아보기 쉬운 형태로 구성하며, Device / Type / State 등에 따라 순차적으로 이름을 조합합니다.

Tok.D는 세 단계로만 구분되는 Brand Color Variation을 적용하고 있습니다.

Color Style의 경우, Parent System에서 파생되는 제품에 따라 최소한의 변경과 Variant를 포함하기 위해, Primary, Secondary, Tertiary 세 단계로만 구성합니다.

너무 많은 컬러 단계가 시스템에 적용되면 재사용성 / 운용성 면에서 어려울 수 있기 때문에, 사용하는 디자이너 혹은 개발자의 초기 셋팅 및 조작 과정을 최소화하고자 했습니다.

하나의 프로덕트에만 적용되는 시스템이 아닌, 다양한 제품에 대응하기 위한 시스템이기에 확장성 면에서도 적합하다 판단했습니다.

필요한 경우 제품에 따라 Color Variation 단계를 추가할 수 있습니다.