디자인 시스템 구축기 1편
디자인 시스템을 만들기로 결심하고 피그마로 이사하기까지
2020년 2월부터 약 2년간 고군분투하며 디자인 시스템을 설계하고 구축해온 과정에 대해 적어보려 한다.
디지털 제품 개발 환경에서 디자인 시스템은 점점 더 중요해지고 있기 때문에 디자인 시스템을 빨리, 잘 만들기 위해 노력했고 지금도 계속 발전하고 있다. 그 과정을 돌아본다.
1편 - 디자인 시스템을 만들기로 결심하고 피그마로 이사하기까지
2편 - 목표와 원칙, 정기 미팅, 모듈 시스템, 그리드, 컬러
3편 - 타이포그래피, 프로젝트 관리, 연말 회고, 구축 과정에서 배운 것
목차
1. 디자인 시스템은 무엇인가?
2. 디자인 환경에서 문제를 찾다
3. 디자인 시스템으로 문제를 해결하자
4. 더 빠르게 더 효율적으로
5. Sketch에서 Figma로 이사하기
1.
디자인 시스템은
무엇인가?
디자인 가이드에는 여러 종류가 있다. 간단히 살펴보면 3가지 정도로 나눌 수 있다.
UI 가이드라인 (스타일 가이드)
UI를 표준화하고 화면 간의 일관성을 확보하기 위한 가이드.
주요 화면에서 사용되는 공통 UI 패턴과 주요 컴포넌트를 추출해 정의하고 상세 속성을 규정하여 디자이너와 개발자가 정해진 기준에 따라 UI를 설계할 수 있게 한다.
UX 가이드라인
서비스와 브랜드 측면에서 사용자가 일관적이고 차별화된 경험을 하도록 하기 위한 가이드.
사용자 콘텍스트를 재구성하여 사용자 입장에서 서비스를 설계하도록 가이드라인을 구성한다. 브랜드 측면에서는 해당 브랜드의 정체성이나 색을 일관되게 전달하도록 하는 기능 정의, 네이밍, 어투, GUI적 요소를 정의한다.
디자인 시스템
디자인 원칙과 규격, 재사용 가능한 UI 패턴과 컴포넌트, 코드를 포괄하는 시스템.
단순 스타일 가이드, 패턴 라이브러리 역할만 하는 디자인 시스템도 있고, 브랜드 원칙과 UX 원칙에 이르는 하나의 철학을 구성하는 시스템도 있다. 정해진 디자인 패턴과 컴포넌트를 재사용하여 제품을 구축하고 개선하는 시간을 단축시켜준다. 일종의 레고 세트라고 볼 수 있다.
A design system isn't a project. It's a product serving products.
- Nathan Curtis, EightShapes
디자인 시스템은 조직에 많은 이점을 가져다준다. 여러 디자이너가 프로젝트에 참여하고 있는 경우에도 모든 제품의 인터페이스가 일관성을 유지할 수 있도록 도와준다. UI를 다시 만들거나 옛날 디자인 파일을 찾아 헤매지 않고 더 중요한 문제를 해결하는 데 집중할 수 있다.
설문 조사에서 디자인 시스템을 사용하는 응답자의 약 90%가 주당 최소 1시간의 작업 시간을 절약했다고 보고했습니다. 약 50%는 매주 6시간 이상 작업을 절약할 수 있다고 말했습니다.
- Invision DSM
출처: Link
2.
디자인 환경에서
문제를 찾다
디자인 시스템을 구축하기로 마음먹은 시기는 2020년 2월, 입사한 지 한 달 정도 되었을 때다. 당시 회사는 여느 회사들처럼 Sketch와 Zeplin 조합을 사용했다. 나는 입사 전까지 XD를 사용했고 Sketch는 이직을 준비하며 한 달 정도 사용해본 게 다였다. 일단 디자인 파일을 둘러보며 서비스 구조를 파악하고 툴을 빨리 익히는 데 집중해야겠다는 생각이 컸다. 입사 후 한 달 동안은 선임 디자이너의 도움을 받으며 Sketch를 익혔는데 이 과정에서 3가지 문제를 발견했다.
1) 일관되지 않은 디자인
2020년 1월 당시 디자인 중일관되지 않은 UI가 사용성을 떨어트리고 있었다. 터치 디바이스인 앱과 마우스를 사용하는 웹의 환경 특성상 다른 UI를 사용할 수는 있지만 폰트 굵기, 외곽선 둥글기, 외곽선 컬러 등 디자인 스타일이 다른 것은 별것 아닌 것처럼 보일 수 있어도 자칫 고객의 신뢰를 잃게 만들 수도 있는 문제였다. 또한 비슷한 화면의 디자인이 다르다는 것은 곧 심볼로 연결되어 있지 않다는 것이고, 디자인 관리가 어려워진다는 것을 의미한다.
왜 이런 문제가 생겼는지 궁금해져 선임 디자이너에게 물어보니 이렇게 될 수밖에 없던 이유가 있었다.
신규 제품의 첫 디자인을 디자이너A가 했다. 그런데 제품 출시 후 디자이너A가 다른 프로젝트로 옮겨 가면서 디자이너B가 이 제품을 맡게 되었다. 그러다 신규 기능 개발, 마케팅 등 업무가 늘면서 그래픽 디자이너인 디자이너C가 들어왔고 디자이너B와 함께 UI를 디자인하게 되었다. 디자이너B와 C는 디자인 원칙이나 기준 없이 한 제품의 UI를 나눠서 각자 디자인을 했고 일관성과 사용성을 잃어갔다.
디자이너 간의 커뮤니케이션에도 문제가 조금 있었던 것 같지만 디자인 시스템이 있었다면 적어도 일관되지 않은 UI로 사용자 경험을 해치는 일은 없었을 것이다.
2) 비효율적인 작업 발생
Input, Button 등 UI의 디자인이 변경되면 스케치 파일마다 하나씩 찾아서 교체해줘야 하는 비효율적인 작업이 자주 발생하고 있었다. 다행히 선임 디자이너도 문제를 인지하고 일부 UI 심볼을 라이브러리로 만들어 두긴 했지만, 여전히 컬러가 잘못 연결되어 있거나 로컬 심볼을 사용하는 페이지가 많았다. 이로 인해 새로운 기능을 디자인하거나 개선하려고 할 때마다 불편을 겪게 되었다.
개발 상태는 어땠을까? 개발자는 페이지마다 개별적인 Button, Color 등을 구현하여 개발하고 있었다. 그래도 일부 UI는 컴포넌트 형태로 만들어 사용했던 것 같은데, 이마저도 페이지마다 다른 컴포넌트를 사용했다. 그래서 전달한 디자인과 다르게 구현되는 문제가 종종 생겼고, QA를 하는 데 불필요한 시간이 소요되기도 했다. 결과적으로 코드 관리가 어려워지고 기술 부채가 쌓였으며 제품의 완성도를 떨어트렸다.
3) 확장성 부족
국내에서 서비스하던 제품A를 복제해 글로벌 서비스인 제품B를 출시했는데 초기 디자인은 동일했지만 제품A의 디자인이 개선되더라도 제품B에 반영되지 않았다. 복제 서비스지만 사실상 별개의 프로젝트로 진행되었기 때문이다. 또한 새로운 기능을 개발하거나 새로운 제품을 만들 때 기존의 리소스를 그대로 복사해 사용한다 해도 심볼이 연결되어 있지 않았기 때문에 매번 새로 디자인을 해야 했다. 이는 곧 문제 해결에 집중해야 할 시간을 반복되는 UI를 구현하는 데 사용하게 만들었다.
3.
디자인 시스템으로
문제를 해결하자
평소 효율적이고 생산적인 하루를 보내기 위해 치밀한 계획을 세우고, 목적지까지 가장 빠른 경로를 찾으며 모든 파일과 폴더를 분류하여 관리하는 나로서는 이런 비효율을 보고만 있을 수 없었다. 더군다나 이건 나 혼자만의 문제가 아니라 동료 디자이너와 개발자 모두의 문제였다.
한 가지 다행이었던 건 당시 선임 디자이너도 문제를 인지하고 Sketch의 심볼 기능을 활용해 라이브러리를 만들고 있었다는 것이다. 다만 그것은 아직 디자인 시스템이라기보다는 스타일 가이드에 가까웠다. 모든 요소들이 유기적으로 연결되어 있는 것이 아니라 정의해둔 심볼들을 따로 가져다 쓰는 상태였고, 개발상의 컴포넌트로 관리되지 않았기 때문이다.
이러한 상황에서 Button, Color, Input 등 재사용되는 UI를 개발자들과 함께 체계적으로 시스템화하면 위에서 이야기한 3가지 문제를 모두 해결하고 효율성을 극대화하여 많은 시간을 절약할 수 있을 것이라고 판단했다. 하지만 앞에서 이야기했듯 나는 Sketch를 두 달 정도 사용해본 상태였고 디자인 시스템에 대해 잘 알지 못했다. 학습이 필요했다. 다행히 당시에도 디자인 시스템에 대한 업계의 관심이 높아지던 시기였기 때문에 관련 글들을 찾을 수 있었다. 퇴근 후에도 주말에도 계속 찾아보며 디자인 시스템을 어떻게 구축해야 할지 윤곽을 잡아갔다.
당시 도움을 받았던 아티클
인상 깊었던 내용
디자인 시스템은 완전한 제품이며, 우리의 제품을 만드는 프로젝트에 투입되는 사람들을 도울 것이다. 모든 좋은 제품들이 그러하듯 일이 밀리기도 할 것이고, 반복적인 일을 수행해야 하고, 유저들(디자인, 개발자, 프로젝트 오너)을 최전방에서 관리해야 한다.
3개의 제품에서 디자인 시스템을 사용하고 있는 지금, 디자인 시스템은 정말 제품처럼 작동하며 내부의 여러 유저들에게 제공되고 있다.
4.
더 빠르게
더 효율적으로
1) 디자인 파일과 심볼 정리
디자인 시스템 구축을 시작하기에 앞서 먼저 디자인 파일과 심볼을 정리해야 했다. 당시 사용되던 20여 개의 Sketch 파일을 하나하나 열어보면서 반복적으로 사용되는 심볼을 속성에 따라 총 6개의 라이브러리(Button, Color, Font, Icon, Viewer, Common)로 분류하여 옮기고, 사용하지 않는 심볼과 파일은 지웠다. 당시에는 Button, Color, Font 등 라이브러리를 나누는 게 낫다고 생각했는데, Figma로 옮겨온 지금은 하나의 파일로 관리한다.
라이브러리로 분류한 후에는 다시 각 디자인 파일에 있는 심볼을 라이브러리의 심볼로 교체해주었다. 이로써 Web, App 등 여러 Sketch 파일에서 동일한 심볼을 사용하게 되었다. 버튼의 디자인이 바뀌더라도 라이브러리를 업데이트하면 연결된 모든 Sketch 파일에 변경사항이 적용되었다.
2) 네이밍 규칙 정의
라이브러리로 옮긴 후에는 원하는 심볼을 빠르게 찾을 수 있도록 심볼의 네이밍 규칙을 정의했다. 당시 스케치는 숫자와 알파벳을 앞에 붙이면 정렬이 쉽게 되어서 위와 같은 형식을 사용했다.
지금은 Figma의 Variants 기능을 사용해 컴포넌트를 디자인하기 때문에 숫자나 알파벳을 사용하지 않고 아래처럼 관리한다. 숫자나 알파벳이 앞에 붙지 않는 게 가독성이 더 좋고, 알파벳 순으로 정렬되어 예측하고 찾기 편하다.
3) 장인은 도구를 탓하지 않는다지만..
네이밍 규칙을 정의하는 데까진 큰 어려움이 없었는데 동료 디자이너와 협업하는 과정에서 또 하나의 비효율을 발견했다. 당시 Sketch는 여러 명이 동시에 작업할 수 없었고, 심볼을 모아둔 라이브러리 파일을 Dropbox로 공유하여 사용하다 보니 작업에 딜레이가 발생했다. 한 명이 파일을 열어 작업하는 동안 다른 디자이너는 기다려야 했다. 게다가 개발자에게 디자인을 전달하려면 Zeplin을 사용해야 했는데 매번 수정된 디자인을 업로드하여 전달하는 과정이 번거로웠다. 시안을 보고 논의하고 수정 사항을 반영하고 다시 공유하는 과정이 비효율적이라고 느꼈다.
4) 찾았다, 피그마!
이 문제를 해결할 방법을 찾던 중 Figma라는 툴을 발견했는데 웹사이트를 살펴보니 놀랍게도 내가 겪던 문제를 완벽히 해결해줄 수 있을 것 같았다. 곧바로 동료 디자이너에게 Figma 도입을 제안했다. 하지만 오래 사용해오던 툴을 당장 버리고 가는 것은 리스크가 있으니 먼저 한 달간 스터디를 해보기로 했다.
5) 본격 스터디
한 달 동안 Figma를 쓰면 쓸수록 확신이 생겼다. 장점이 명확했다.
· 동시에 여러 명의 디자이너가 하나의 디자인 파일에 들어와 함께 작업할 수 있다.
· 개발자는 언제든 들어와 디자인을 살펴보고 코멘트를 남기거나 Code를 볼 수 있다.
· 간단하게 고퀄리티의 프로토타입을 만들 수 있다.
· 링크만 공유하면 누구든 들어와서 의견을 남길 수 있다.
처음엔 내가 디자인하는 걸 누가 지켜본다는 게 불편했지만 금방 익숙해졌고, 오히려 디자인을 보면서 빠르게 의견을 주고받을 수 있어서 훨씬 효율적이었다. Zeplin이라는 툴을 거치지 않아도 되니 커뮤니케이션 시간도 단축되었으며 마치 워드 쓰다가 구글 독스로 넘어온 느낌을 받았다. (포토샵으로 어떻게 디자인했나 싶다.)
물론, 단점도 있었다.
· Sketch에서 기본 제공하는 마법봉이 없다.
· 컬러 스포이드가 툴 밖에선 작동하지 않는다.
· 브라우저의 이미지 드래그 앤 드롭이 제한적이다.
· Auto Layout 설정이 제한적이다.
· 한글 입력 버그가 있다.
마법봉은 플러그인을 통해 대체 가능하고, 컬러 스포이드는 해당 화면을 캡처해서 Figma로 가져오면 되고, 브라우저에서 이미지를 가져올 땐 이미지 복사해서 가져오면 되고, Auto Layout은 계속 발전해서 이젠 Sketch보다 더 유연하고 편리하다. 한글 입력 버그는 아직 존재하지만 가끔 발생해서 많이 불편하진 않다. 그리고 이때 느꼈던 많은 불편함들은 지속적인 업데이트를 통해 대부분 해결되었다.
6) 스터디 결과는?
스터디는 성공적이었다. 디자이너뿐만 아니라 마케터, 개발자의 피드백을 받은 결과, Sketch보다 Figma가 훨씬 더 효율적으로 협업할 수 있게 해 준다는 것을 확신할 수 있었다. 곧바로 회사에 공식적으로 Figma 구매를 요청했고, 이사 준비를 시작했다.
5.
Sketch에서
Figma로 이사하기
이사는 생각보다 간단했다. '.sketch' 파일을 Figma로 끌어다 놓으면 import 된다. 하지만 짐 정리는 매우 고단한 과정이었다. 지금은 import해도 많이 깨지지 않아 거의 그대로 사용 가능한데 당시엔 깨지는 요소가 많았다. Sketch의 artboard 개념과 Figma의 frame 개념의 차이로 생기는 문제도 많았고, 레이어 마스크가 깨지는 경우도 있었다.
이런 상황에서 조금이라도 고생을 덜기 위해서는 먼저 Sketch 파일을 정리해야 했다. 플러그인의 도움을 받아 사용하지 않는 심볼은 지우고 같은 심볼인데 이름이 다르면 맞춰주며 심볼을 정리하는 과정을 거쳤다.
많이 사용했던 Sketch 플러그인
· Symbol Organizer: 심볼을 자동으로 정렬해준다.
· Unused Style Remover: 정의된 스타일 중 사용하지 않는 스타일을 지워준다.
· Symbol Instance Renamer: 심볼 인스턴스의 이름을 마스터 심볼의 이름으로 변경해준다.
위 플러그인을 사용해 깔끔하게 정리한 .sketch 파일을 Figma로 가져오면 안타깝게도 라이브러리와 연결된 심볼이 모두 끊어진다. 즉, Figma에서 라이브러리를 배포하고 디자인 파일의 컴포넌트들을 교체해줘야 한다는 것이다. 이 반복적이고 고된 작업을 빠르게 하기 위해 Figma의 플러그인을 사용했다.
많이 사용했던 Figma 플러그인
· Select Layers: 이름이나 타입으로 원하는 요소를 선택할 수 있다.
· Rename It: 레이어의 이름을 바꾸는 플러그인. 지금은 Figma에서 cmd + R로 비슷한 기능을 지원해서 사용하지 않는다.
· Clean Document: Sketch 파일을 Figma로 가져왔을 때 숨겨진 레이어가 가끔 있어서 한 번에 지우거나 정리할 때 사용했다.
· Design System Organizer: 컴포넌트를 조금 더 쉽고 효율적으로 관리하고자 사용했다. 관리를 위한 관리가 되는 것 같아 지금은 사용하지 않는다.
2년이 지난 지금도 그때 Figma로 넘어오길 참 잘했다는 생각을 한다. 툴은 툴에 불과하다는 말도 있지만 때로는 툴을 바꿈으로써 생산성을 향상시킬 수도 있다고 생각하고, 깊이 실감하고 있다.
2편에서는 Figma로 옮긴 후 본격적인 디자인 시스템 구축 과정에 대해 이야기해보려 한다.
<2편에서 계속>
