Posted in

피처링 디자인 시스템 1.0 구축기

by Ive
FigmaUX/UI디자인시스템

피처링 디자인시스템

“우리도 디자인 시스템이 필요해요.” 디자인 시스템을 구축하고 싶은 분들이 읽으면 좋은 글

안녕하세요. featuring의 프로덕트 디자이너 아이브입니다. 이번에는 디자인시스템을 구축한 경험을 들고 왔습니다. 만약 지금 디자인시스템을 통해 반복적인 업무를 줄이고 효율적으로 일하길 원한다면 이 글을 읽어보세요. 디자이너가 여러명이면 디자인 시스템을 만들 이유가 넘쳐나고 디자이너가 1명이라도 개발팀과 협업을 해야한다면 한번 도전해보시길 바랍니다.

1. 디자인 시스템, 무엇이 좋을까?

“문제는 곧 기회다.”

디자인 시스템의 필요성을 느낀 건 지난 여름이었습니다. 원래는 ‘개발의 기술 부채를 청산하기 위해 서비스를 전체 개편한다.’ 라는 목적하에 레거시 없는 새 판에서 자유롭게 디자인을 하고 있었습니다. 더군다나 디자이너가 저 혼자라 디자인의 일관성도 쉽게 유지할 수 있어 디자인 시스템이 필요 없었죠. 그런데 페이지가 하나둘 많아지고 일관성을 위해 비슷하게 가져갔던 레이아웃이 나중에 변경이되면 전부 일일이 바꾸어주어야 했습니다. 그 순간 생각이 들었습니다.

‘아 이거 너무 비효율적이다.. 해결 해야겠다.’

이대로 진행하다간 디자인에도 부채가 쌓일 것이고 이는 다시금 개발 기술 부채로 이어질게 눈에 보였습니다. 그래서 디자인 시스템을 도입하기로 했습니다. 처음 시작할 때 리소스가 좀 들지만 결과는 디자이너인 저도, 개발자분들도 만족하며 사용하고 있습니다. 디자인 시스템의 장점은 크게 3가지입니다.

Slide 16_9 - 58.png

첫째, 생산성이 증가했습니다. 플랫폼 특성상 비슷한 화면의 UI가 많습니다. 디자인 시스템 도입 후 반복적으로 그리는 일은 없어지고 에셋에서 컴포넌트를 검색하여 불러오는 경험으로 대체되었습니다. 반복적인 화면에 소모되는 시간이 줄어 제품에 더 집중할 수 있었습니다. 그리고 개발적으로도 생산된 컴포넌트를 props만 바꾸어 사용할 수 있어 화면을 그리는 난이도도 줄일 수 있었습니다.

둘째, 유지 보수와 변경이 쉬워졌습니다. 기획을 하던 중 문제가 생겼습니다. 원래 Material Design 3를 따라 Body 텍스트를 16px로 설정하여 작업했습니다. 근데 문제가 큰 데스크톱 화면에선 괜찮지만 노트북 화면에선 요소 일부가 잘려 한 눈에 확인하기 힘들었습니다. 그래서 전체적으로 폰트를 2px 줄이고 폰트에 맞춰 여백도 폰트에 맞춰 더 촘촘하게 바꿔야했습니다. 만약 디자인 시스템 도입 전이라면 모든 컴포넌트의 텍스트를 다 바꿔주어야 했을 겁니다. 다행히 시스템으로 구조화 되어 있어 단 반나절 만에 상위 폰트 레벨과 컴포넌트 여백만 수정하여 모든 화면을 수정했습니다. 개발단에서도 똑같은 구조를 가지고 있어 일괄적으로 변경하기 편했습니다.

셋째, UI와 UX 그리고 Code 일관적이게 만들 수 있습니다. 디자인 시스템을 작성하면 개발팀과 정렬하기 쉽습니다. 그리고 디자인도 컴포넌트를 가져다가 쓰기 때문에 여백과 폰트 크기부터 하나의 스타일로 통일이 됩니다. 또한 화면을 그릴 때 부터 컴포넌트를 활용해야하기 때문에 이전 화면을 생각하면서 더 구조적으로 생각하게 됩니다. 이 뿐만 아니라 개발적으로도 동일하게 하나의 컴포넌트에 하나의 코드가 있기 때문에 코드 구조도 일관적으로 가지고 갈 수 있었습니다. 이는 기업 구조상 내부 서비스들과 외부 구축 등 동시에 여러 프로젝트를 관리해야하는 입장으로서도 큰 이점이 되었습니다.

2. 디자인 시스템, 하나부터 하나하나

“시작하는 데 있어서 나쁜 시기란 없다.”

그렇다면 디자인시스템은 어떻게 만들어야할까요?

일단 자료를 수집합니다. 다른 기업들은 어떻게 할까? 아래는 제가 참고한 레퍼런스와 글입니다.

자료를 참고하다보니 세상에는 똑똑한 사람들과 좋은 시스템들이 많다는 것을 피부로 느꼈습니다. 이걸 다 적용하고 싶은 마음은 굴뚝같지만 기초부터 조금씩 적용하기로 했습니다. 디자인 시스템은 크게 두가지로 이뤄져있습니다. 스타일 가이드와 컴포넌트 라이브러리로 스타일 가이드는 색상과 타이포, 네이밍 등이 정리된 문서입니다. 그리고 컴포넌트 라이브러리는 컴포넌트는 활용되는 기능, 화면들을 구조화한 것을 말합니다. 이 중 스타일 가이드에 먼저 집중하기로 합니다.

  1. 스타일 가이드 작성 (필수)
    • 기본 에셋
      • 아이콘
      • 로고
    • 스타일
      • Color
      • Typo
      • Shadow
      • Radius
  2. 컴포넌트 정리
    • 아톰

스타일 가이드는 color, typo, shadow, radius로 정리했습니다. 가장 집중한 건 컬러였습니다.

↑ 피그마에선 styles라는 항목 밑에 정리해두었다.

↑ 피그마에선 styles라는 항목 밑에 정리해두었다.

2.1. 컬러 가이드

↑ 컬러 가이드 전체 색상

↑ 컬러 가이드 전체 색상

먼저, 컬러의 색상을 gray와 primary, system으로 나누어 만들었습니다. 그리고 primary, 컬러와 gray 컬러는 주로 사용하기 때문에 다양한 레벨의 색상을 두었고 system 컬러는 간헐적으로 사용되기 때문에 주요 레벨만 남겨두었습니다.

(호버 등 인터렉션시 표현 때문에 시스템 컬러도 양 옆으로 한가지 단계씩 추가하면 좋을 것 같다.) (다크모드도 대응해야하면 저 구조를 그대로 쓰긴 힘들 것 같다.)

gray.png

primary.featuring.png

system.png

그리고 자주 사용되는 색상에 의미론적인 네이밍을 덧붙였습니다. gray05_bg 와 gray80_text 같이 배경색과 텍스트를 알려주고 그와 같은 레벨에 lighten과 darken을 붙였습니다. 배경색과 텍스트의 명도비는 A11y를 통해 테스트하여 웹접근성에 맞추어 만들었습니다.

↑ 피그마 플러그인 A11y, 명도비 검사를 해준다.

↑ 피그마 플러그인 A11y, 명도비 검사를 해준다.

개발적으로는 JSON형태로 만들었는데 특이점이 여러 프로젝트의 키컬러가 달라서 gray 와 system 은 Core에서 참조받고 primary 는 각 프로젝트에서 정의하여 통합 관리할 수 있게 만들었습니다.

↑ 개발 화면, Primary컬러는 각 프로젝트에서 정의하고 그 외는 전부 Core에서 참조 받는다.

↑ 개발 화면, Primary컬러는 각 프로젝트에서 정의하고 그 외는 전부 Core에서 참조 받는다.

2.2. 타이포 가이드

Title.png

body.png

타이포는 타이틀과 바디폰트로 나누었으며 본고딕 기반인 SUIT폰트를 사용했습니다. 똑같이 본고딕 기반이고 UI폰트로서 완성도가 높은 프리텐다드와 고민을 했는데 a의 모양이 필기체의 형태라서 영문 폰트가 직선적인 SUIT폰트로 선택했습니다.

본문에 경우 줄간격이 1.5~1.75가 되어야 가독성이 좋으나 타이틀에 경우 1.2~1.3으로 해야 응집력이 생깁니다. 그 중 1.25를 적용한 이유는 줄간격또한 소수점이 아니라 정수로 떨어지는 것이 좋아서 1.25를 곱했습니다.

폰트 두께의 경우 bold, medium, light 세가지를 썼지만 타이틀은 bold만 사용하고 바디폰트에는 medium과 light로 제한하여 디자인적으로 위계가 생길 수 있게 만들었습니다.

2.3. 기타 가이드

radius.png

elevation.png

radius와 shadow는 구체적인 가이드라인을 작성하진 못했으나 구조적으로 단계는 나누었습니다.

여기까지만 만드셔도 디자인이 한결 쉬워집니다. 갑작스런 폰트 변경 요청에도 전혀 당황스럽지 않죠.

3. 디자인 시스템, 컴포넌트로

“소통은 상대방과 같은 단어를 쓰는 것부터 시작된다.”

컴포넌트부터는 개발팀과 협업으로 이루어졌습니다. 개발팀도 기술 부채 청산을 위해 프로젝트를 실행한 만큼 유지보수와 변경, 확장이 용이한 구조를 고민하고 있었습니다. 이미 여러 레포지티를 한 곳에서 관리 할수 있도록 모노레포를 도입하기로 했었다. 그래서 아토믹 패턴으로 컴포넌트를 관리하는 걸 제안했더니 흔쾌히 수락해주셨습니다.

아토믹 패턴이란 Atoms(원자), Molecules(분자), Organisms(유기체), Templates(템플릿), Pages(페이지) 이렇게 5단계로 나누고 아래 단위가 합쳐져 상위 단위를 이루는 패턴입니다. (자세한 건 아래 참고 자료를 보시면 됩니다.)

저희는 아토믹 패턴을 그대로 수용하진 않았습니다. 각 단위를 나누는 단위가 주관적이라 각자마다 다른 판단을 하고 그걸 조정하는데 비용이 크다고 생각했습니다. 그래서 단계를 줄이고 재조합했습니다. 일단 Templates 단위는 재활용할 일이 적어보여 단계를 줄였습니다. 그리고 Pages와 다른 단위를 분리시켜 다른 단위는 Component 하위로 위치 시켰습니다. 마지막으로 용어는 좀 더 저희가 알아보기 쉽게 바꾸었습니다.

  • Components
    • Atoms (원자) → atoms
    • Molecules (분자) → widget
    • Organisms (유기체) → layout
  • Templates (템플릿) ← 사용X, 유의미한 재활용 불가라고 판단
  • Pages (페이지) → 페이지 폴더는 Next 라우팅 설정에 따라 독립적으로 구성.

Slide 16_9 - 59.png

전체 구조는 모노레포 구조로 각 프로젝트 폴더가 나누어져 있고 모든 폴더는 코어를 참조 받는 형태로 구조화했습니다. 코어 폴더를 수정하면 모든 폴더를 한번에 바꿀 수 있는 형태로 발전시켰죠. 이 시점에 모든 프로젝트의 컴포넌트를 분석해서 atoms, widget, layout으로 나누어 모두 정리하면 좋습니다. 그러나 그럴 시간과 리소스가 부족해서 저희는 atoms 단위만 다 정리하고 프로젝트를 시작했습니다.

  • Atoms
    • Button
    • Input
    • Selections
    • Chips
    • Badge & Tag
    • Avatar
    • Progress

3.1 버튼 컴포넌트

Primary Button.png

Large Primary Button.png

Small Primary Button.png

피그마에선 형태가 유의미하게 변할 때 분기하여 컴포넌트를 불리했습니다. property 속성을 줄여 디자이너가 아닌 기획자분들도 쉽게 사용할 수 있도록 하려고 형태가 변하는 지점에 따라 나눴습니다. 그런데 코드에선 불필요한 중복된 코드가 발생하여 통합했습니다.

그래서 피그마에서도 추후에는 통합 예정입니다. 베타 기능인 Nested Instances를 활용하면 사용성을 쉽게 하면서 통합할 수 있을 것 같습니다.

3.2 인풋

Input.png

3.3 셀렉션

Frame 484.png

Switch.png

Select.png

3.3 태그&배지

Tag.png

3.4 칩스

Fillter Chips.png

3.5 아바타

Round Avatar.png

전체적인 구조와 자세한 스펙은 material3 가이드를 많이 참고했고 피그마 구조를 만들 땐 연정’s Figma를 많이 참고했습니다. 가이드가 자세히 나와 있어 참고하시면서 정리하면 금방 정리할 수 있습니다. 이외에 widget이나 layout 단계에 있는 GNB (글로벌 네비게이션), Tilte Bar (타이틀바), Modal(모달) 등은 문서까지 정리하진 않고 개발팀과 커뮤니케이션하며 유연하게 정리했습니다. 피그마를 보며 중복이 많은 컴포넌트부터 정리했습니다.

여기까지 디자이너가 혼자인 팀에 디자인시스템을 도입한 이야기를 설명드렸습니다. 여러분들도 디자인 시스템을 만들어 비효율적이고 반복적인 업무에서 해방되시길 바라겠습니다.

마지막 세줄 요약.

⏰시간이 없으신 스타트업 디자이너 분들을 위한 세줄 요약입니다.

  1. 디자이너가 혼자라도 디자인 시스템이 있으면 좋습니다.
  2. 처음부터 완벽히 보단 스타일 가이드부터 작성하세요.
  3. 컴포넌트도 조금씩 정리해가면 됩니다.

디자인의 모든것