brunch

You can make anything
by writing

C.S.Lewis

by 동교동 Jul 06. 2021

6월: ‘이게 맞나?’ 본격 디자인 가이드 제작기

야매, but 도전해보았습니다. 디자인 가이드 제작하기

주로 프로덕트를 디자인하며 배운 점을 기술하며, 회사 내부의 사업, 기획, 프로덕트 기능에 대해서는 언급하지 않을 예정입니다. (언급하더라도 출시된 기능 위주)


6월에 들어서며 나의 인턴십 계약 종료 시점이 다가오고 있었다. 그 말은 프로덕트를 사수님께 인수인계를 해야 할 때가 오고 있다는 뜻이었다.

Bye~


B2B 서비스는 웹과 앱 모두 대략 MVP 정도의 디자인이 완성되어 있었는데, 사수님께 드리기 전에 디자인 컴포넌트를 정리하고, 페이지도 디자인을 통일해야 할 필요성이 있었다. 이전 ‘참사를 일으킨 3가지 실수'에서 다룬 것처럼 당시 웹 쪽은 페이지 레이아웃도, 컴포넌트도 엉망이었다. 컴포넌트가 뒤죽박죽이었던 이유는 실수 말고도 이슈가 생길 때마다 페이지가 자주 수정되고 있었던 탓도 있었다. 그러다 보니 같은 기능을 하는 컴포넌트도 약간씩 달라, 디자인/개발 리소스를 다시 만들어야 하는 비효율 끝판왕 일들이 발생하고 있었다.


B2B 프로덕트는 짬짬이 사수님과 디자인 과정을 공유한 것 말고는 전적으로 내가 맡고 있었다. 그래서 내가 없어도 사수님이 어려움 없이 새로 페이지를 제작할 수 있게 드리고 싶었다. 그러려면 내가 만든 컴포넌트가 언제, 어떻게 쓰이는지에 대한 ‘정의서’와 조합하기만 하면 화면을 만들 수 있는 ‘컴포넌트를 디자인’ 해야 했다.


소위 ‘디자인 시스템’을 만드는 것이 이 회사에서의 마지막 과업이라 생각했다. 디자인 시스템에 대해 처음 안 것은 2018년 토스의 강수영 디자이너님이 우리 학교에 오셔서 강연을 하셨을 때였다.


2018년 토스의 강수영 디자이너님 강연에서 기록한 노트


당시 토스는 디자이너가 늘어나고 있었다. 디자이너가 각자 컴포넌트를 만들고, 각자 다른 레이아웃으로으로 UI를 디자인했기 때문에 통일성 있게 다시 화면과 컴포넌트를 작업해야 하는 비효율적인 문제가 있었다고 한다.


이런 단순 노동을 줄이기 위해 도입한 것이 TDS(Toss Design System)! 디자인 시스템을 만드는 데는 1년이나 걸렸으나, 후에 리소스 개발, 커뮤니케이션 등 비용을 줄이고 프로덕트 자체에 더 집중할 수 있었다고 한다.

외쳐! 전설의 레전드 TDS (Toss Design System)


지금도 UX/UI를 열심히 공부하는 입장이지만 2018년, UX/UI 병아리를 넘어 알도 못 깼던 나로서는 강연에 앉아있으면서 ‘저게 무슨 말일까’하던 기억이 난다. 단순히 프로덕트를 디자인한 것에 그치지 않고 유지/보수한 경험이 있는 현재, 디자인 시스템의 필요성을 절실히 느끼고 있다.


디자인 시스템이 좋다는 것은 알겠어. 그래서 디자인 시스템이 뭔데?


디자인 시스템에 대한 글도 많은 만큼, 정의도 다양했다. 수많은 아티클을 정리해보자면 디자인 시스템이란 이렇다:                    


간단히 설명하자면 이런 것


브랜드 원칙, 가치/아이덴디티(슬로건, 브랜드 컬러 등) + 각각의 UI 컴포넌트(버튼, 서치 바 등) + 이를 언제 써야 하는지, 어떻게 조합해야 하는지에 대한 가이드라인이 합쳐지면, 회사/팀의 모든 관계자가 일관된 UI를 빠른 시간 안에 만들 수 있다. 이를 문서화한 것이 디자인 시스템이라는 것이다.


즉, 디자인 시스템을 구축하게 된다면, 프로젝트에 참여하는 디자이너가 많아도 같은 컴포넌트를 동일한 맥락에서 사용하기 때문에 서로 다른 형태의 UI를 제작하게 되는 일이 줄어들고, 개발자와 디자이너 간 커뮤니케이션을 줄여준다. 또한, 컴포넌트를 새로 제작할 필요 없이 필요할 때마다 라이브러리에서 골라 꺼내 쓰기만 하면 된다.


이러한 장점 덕분에 에어비앤비, 마이크로소프트, 토스, 라인, 쏘카, 리디북스 등 웬만큼 들어본 국내외 서비스는 각자 자신의 디자인 시스템을 가지고 있다. 이처럼 업계에서 핫한 디자인 시스템, 회사에서는 언제 만들어야 할까?


디자인 시스템 제작 시기

2019년 원티드에서 주최한 스펙트럼 콘에서 강연한 토스 디자이너 두 분은 디자인 시스템이 필요한 시기를 이렇게 말했다:


*출처 김유진, 정지현 님이 정리하신 노션 페이지에서 발췌했습니다.

나는 같은 버튼을 N곳에 쓰고 있다

나의 회사나 팀에는 디자이너가 N명이다

내가 만드는 제품의 페이지는 N개다

→ N x N x N = 0 이상인 회사는 디자인 시스템을 만들어야 한다!


…라고 한다.


그러나 내 인턴 계약이 끝나면 회사의 디자이너는 사수님 한 분이었고, MVP정도의 웹 페이지만 디자인한 것이라 페이지 수가 많다고는 할 수 없었다.


빠르게 성장해야 하는 초기 스타트업의 경우 당장 ROI가 발생하지 않는 디자인 시스템에 시간을 들이는 것이 불필요할 수 있다. 또한 디자인 시스템을 제작하는 데는 개발자, 디자이너, 기획자 등 구성원의 콘센서스가 필요하나, 이 필요성을 알고 적극적으로 추진하는 데는 디자이너 역할이 크다. 디자이너가 다른 구성원을 설득할 수 있는 힘이 없으면 조직 내에 디자인 시스템 제작 필요성이 받아들여지지 않는 경우도 있다는 것이다.


그래도 만들었다. 디자인 시스템은 아니더라도 디자인 가이드.


그럼에도 나는 퇴사 전에 디자인 시스템은 아니더라도, 반복되는 컴포넌트를 제작하고, UI 가이드는 만들고 가야겠다고 생각했다. 주된 이유는 위에 언급한 것처럼 ‘사수님께 인수인계를 잘 해 드려야 한다’고 생각했기 때문.


내가 만든 것을 다른 디자이너가 쓰기 위해서는 간결하고 명확한 설명과 함께 정리된 컴포넌트를 제작해야 했다. 이 작업은 꽤나 오래 걸릴 것 같아 퇴사 2주일 전부터 사부작사부작 작업을 시작했다.


Sketch가 회사에서 사용하는 디자인 툴이었으나, 기한 내에 맞추기 위해 디자인 가이드는 Figma로 작업하였다. 평소 내가 사용하던 툴이다 보니 작업 속도도 빨랐고, web 기반 서비스였기 때문에 프로그램이 없어도 파일 공유가 가능한 점 때문에 선택했다. 디자인 프로그램이 없는 개발자 분들도 이 파일을 보면서 작업한다면 도움이 많이 될 것 같다는 생각이 들었었다.


그러나 Figma를 사용할 수 있었던 대전제는, Figma에서 Sketch로 변환할 수 있는 플러그인을 찾았기 때문이다(사수님은 스케치 쓰는데 피그마 파일로 넘길 수는 없잖아!)


보안상 멀~리 찍은 디자인 가이드


버튼, 타이포그래피, 컬러, 모달 등 컴포넌트 옆에는 실제 어느 상황에 적용하면 되는지 설명을 써놨다. 이후 컴포넌트를 최대한 활용하여 그동안 Sketch에서 작업한 화면을 거의 동일하게 카피하는 작업을 했다. 놀랍게도 몇몇 화면의 90%은 컴포넌트로 구성할 수 있었다.


사실 처음에 디자인 가이드를 만들겠다고 마음먹고 컴포넌트를 만들고 있을 때, 시간이 너무 오래 걸려 사수님께 징징거렸던 기억이 난다.(나 퇴사할 때까지 못 끝내면 월급 더 주세요~~ 엉엉~) 화면에 공통적으로 쓰이는 특정 컴포넌트를 뽑아내고, 그것의 상태 변화까지 정의하려니 속도가 너무 안 나는 것이다! 그러나 컴포넌트를 제작하고 나서 웹페이지를 만들기 시작하니 가속도가 붙었다. 거의 시간 분배가 컴포넌트 만들기 (5–6일), 웹페이지 만들기 (2–3일) 정도?


시간 단축에 도움을 준 Figma의 Auto-Layout과 Variant

인내심의 한계를 시험하게 한 극초반 컴포넌트 정리! 시간을 끌게 된 배후에는 이 작업이 있었다.

Auto-Layout과 Variant 기능


Auto-Layout을 사용하여 컴포넌트를 만들게 되면 어떤 점이 좋을까? 위에 보이는 것처럼 오토 레이아웃을 설정해놓으면 라벨(콘텐츠)의 크기가 달라져도 컨테이너(버튼) 크기도 일정하게 크기가 바뀐다. 패딩을 고정했기 때문이다. 그래서 오토 레이아웃을 적용시킨 컴포넌트들을 빠른 속도로 상황에 맞게 변형할 수 있었다.


Click, Hover 등 유저와의 인터렉션에 따라 버튼의 색깔이 바뀌었던 경험이 있을 것이다. (없다면 당장 아무 웹사이트나 켜서 버튼을 눌러보세요) 또는 클릭할 수 없다는 뜻으로 버튼이 회색이 되어 유저의 행동을 유도할 때도 있다. 이렇게 컴포넌트는 여러 상태로 변하는데, Figma의 Variant 기능은 컴포넌트의 상태 변화를 쉽게 관리할 수 있게 한다.


어떤 디자이너가 버튼의 디폴트 상태 색깔, 눌린 상태 색깔을 설정하고 두 가지 상태를 Variant로 묶어놓았다고 하자. 만약 디폴트인 버튼을 눌린 버튼으로 바꾸고 싶다면 오른쪽 패널 드롭다운에서 눌린 상태를 선택하면 된다. 또한, Variant를 만든 디자이너가 아니라 다른 관계자들도 단순히 패널의 드롭다운을 클릭하여 버튼이 상황에 따라 어떻게 변하는지 알 수 있다. 따로 가이드 문서를 읽지 않아도 된다는 뜻!


처음에 컴포넌트에 일일히 패딩을 설정해주고, 상태변화들을 묶어놓는 것이 여간 쉬운 일이 아니었다. 그러나 처음 컴포넌트 제작에만 시간이 오래 걸리고 힘들지, 이렇게 해놓은 덕분에 후반 인터페이스 작업에서는 훨훨 나는 속도로 작업할 수 있었다. 드롭다운 눌러서 바로바로 컴포넌트를  바꿔주기만 하면 되니까!(심볼 스왑 기능도 시간 단축에 도움이 됐다)


그동안은 단기간에 프로젝트를 기획하고 디자인하는 작업만 했기 때문에 Auto-Layout이나 Variant를 사용할 필요가 없었다. 그러나 프로덕트를 장기적으로 유지/보수할 계획이라면 이 기능을 알아두는 게 비용을 줄이는 데 큰 역할을 할 것 같다는 생각이 들었다.



출근 마지막 날, 회의실에 들어가서 사수님께 디자인 가이드를 설명해드렸다. 사수님이 ‘칭찬 잘 안 하는 타입인데, 잘하셨네요. 덕분에 편하게 쓸 수 있을 것 같아요’라고 했을 때 기뻤다. 잠깐 동안 회사에 있었지만, 조금이라도 이 조직에 실질적으로 기여하고 싶었다. 물론 실력이 내 기대만큼 미치지 못한 때도 많았다. 그때마다 책임감과 실망감에 휩싸였지만, 프로덕트 하나를 맡아 디자인하는 것만큼 뿌듯한 것이 없었다. 내가 한 일이 회사가 도약하는 데 작은 발판이 되었으면 좋겠다. 감사합니다.




참고한 페이지

https://www.notion.so/08-b8c2afd5adaf4107b0da4cd0af33137e


작가의 이전글 5월: 알면 알 수록 심오한 ‘버튼’의 세계
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari