내가 필요해서 정리한 디자인 시스템에 관한 모든 것

최근에 디자인 시스템을 대체 어떻게 만들어야할지 고민도 많고 공부도 많이 하고 있습니다. Figma에서는 디자인 시스템 파일을 만들어두고 컴포넌트를 재 사용하고 있지만 디자인 팀 내에서만 사용하는 디자인 시스템은 반쪽 짜리 디자인 시스템임을 뼈저리게 느끼고 있어요..

대체 어떤 툴을 사용해야 하는지, 라이브러리를 써도 되는지, 추후에 수정 및 관리는 어떻게 하는지 궁금한게 참 많아지더라구요. 그래서 정말 수십 개의 글을 읽고 수십 명에게 물어본 것들을 정리한 없는거 빼고 다 있는! 요약본입니다.

아직 디자인 시스템 제작 전이라 정보 요약 밖에 없어요, 몇달 뒤에 디자인 시스템 제작 후기도 올릴 수 있길 소망합니다. (제가 사내 디자인 시스템 관련해서 여쭤봤을 때 흔쾌히 정보 공유해주신 모든 분들 소중한 경험 공유해주셔서 정말 감사합니다!)

디자인 시스템이란?

  • 디자인 시스템은 팀들이 제품을 디자인하고, 실현하고, 개발할 수 있도록 하는 모든 요소들을 묶는 하나의 진실의 원천 (The single source of truth)
  • 디자인 시스템은 팀이 브랜드에서 일관되게 느껴지는 프로덕트와 디지털 경험을 만드는 방법
  • 디자이너와 엔지니어가 일관된 제품 및 웹 설계를 위해 공유 언어를 제공하는 ‘재사용 가능한’ 구성요소, 원리 및 지침 집합

디자인 시스템이 필요한 이유

  • 프로덕트와 인터페이스의 일관성
  • 크로스 펑셔널한 협업 가능
  • 디자인/개발의 속도와 확장성 → 조직의 시간과 비용 절약

⇒ 큰 도약을 위해 반드시 필요한 과정

디자인 시스템 구성 요소는?

디자인 시스템은 단순히 패턴 라이브러리나 스타일 가이드가 아니다.

  • Design principles | 디자인 원칙
  • Style guide | 스타일 가이드 : Typography, colors, icons and etc 타이포그라피, 색상, 아이콘
  • UI component library | UI 컴포넌트 라이브러리 : Button, widget and etc 버튼 위젯 등
  • Design process guidelines | 디자인 프로세스 가이드라인

디자인 시스템 제작 시 유의할 점

  • 디자인 시스템은 결코 완성되지 않는다. 제품이 발전함에 따라 디자인 팀은 새로운 UX/UI를 추가할 것이다. 디자인 원칙을 기반으로 구축하면 일관된 언어를 유지하는데 도움이 된다.
  • 엄격함과 유연성 사이에서 밸런스를 찾는것이 중요하다.
  • 디자인 시스템을 효과적으로 공유하고 운영하기 위해서는 프론트엔드 인프라구조를 포함해야한다.

디자인 시스템 설계 가이드

  1. 기존에 사용하던 컴포넌트와 디자인 확인
  2. 다른 디자인 시스템 사례 리서치
  3. 컴포넌트 리스트로 정리
  4. 타임라인 계획
  5. 컴포넌트에 관해 리서치하고 토론
  6. 컴포넌트 제작
  7. 디자인 시스템 공유 및 관리를 위한 디자인
  8. 디자인 시스템 구현

디자인 시스템을 위한 툴

일반적으로는 1) 디자인 팀이 피그마/스케치/XD에서 디자인 → 2) 개발 팀이 디자인을 보고 똑같이 개발 → 3) 스토리북 등의 툴을 이용해서 실제 컴포넌트 공유 → 4) 추후 수정이 필요하면 반복 하는 과정을 거칩니다. 제 지인 분들에게 물어본 결과 일반적으로는 Figma+Storybook 조합이 가장 많았습니다.

Framer나 UXPin 같은 경우에는 디자인을 했을 때 실제 리액트 코드로 변환해서 볼 수 있고 개발까지 걸리는 시간을 줄여주고, 개발한 코드를 디자인 할 때 재사용할 수 있게 하는 툴입니다. 이론적으로는 가장 최상의 툴이지만, 디자이너에게는 디자인 자유도가 낮고 러닝커브가 상대적으로는 높다는 단점이 있습니다.

디자인 툴: 디자인 팀이 디자인을 하기 위한 툴

  • Figma
  • Sketch
  • XD

공유 및 관리를 위한 툴: 개발한 컴포넌트를 가시화하고 도큐멘테이션을 공유하기 위한 툴

디자인-개발 통합 툴: 디자인-개발 연동이 잘되어 관리 및 재사용을 쉽게 하는 툴

라이브러리 사용 vs 자체 디자인 시스템 제작

대부분의 경우 고도화된 외부 라이브러리를 사용하지 않고 자체 디자인 시스템을 제작하고 있었습니다. 초기에 라이브러리를 커스터마이징해서 사용하다가도 결국에는 자체적인 디자인 시스템을 제작하는 경우가 많았는데요.

고도화된 라이브러리를 커스터마이징해서 사용하는 경우의 문제점

  • API 확장시 자체 디자인 시스템과 맞지 않는 경우가 생긴다. 확장해서 사용할 때 원본 컴포넌트에 의존성이 생긴다.
  • 라이브러리에 따라 컴포넌트 수정, 속성 추가가 어려운 경우가 있고, 디자이너가 만들고자 하는 형태로 커스텀하기 어렵다.
  • 라이브러리를 Fork해 수정된 버전을 사용하더라도, 라이브러리 코어에 버그가 발견될 경우 일일이 업데이트를 해야한다.
  • 라이브러리에 없는 컴포넌트가 있을 때 완전히 새로 구현해야한다.

결론, 서비스 복잡도가 현저히 낮다면 고도화된 라이브러리를 사용해서 제작해도 괜찮다. 하지만 복잡도가 높거나 브랜드 보이스가 담긴 프로덕트를 구축하고 싶다면 자체 디자인 시스템을 제작하자!

관련해서 참고했던 아티클 첨부합니다. 또 Design compass 오픈채팅방에서 관련해서 친절히 응답해주신 디자이너님도 감사합니다!

관련해서 읽었던 모든 레퍼런스 링크입니다.

References

디자인 시스템 실제 제작기가 담긴 완전 도움된 아티클!

General

--

--

SaaS 프로덕트 실무자들이 직접 스터디하고 아카이브 하는 커뮤니티입니다.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jiyu Han

Jiyu Han

B2B SaaS Product Designer @hyperquery | We’re building a product for data analytics team to innovate data collaboration workflow. (Email: jiyu0719@gmail.com)