디자인 시스템 만들기-디자인 토큰(1)
디자인 토큰 규칙을 정하는 것에 대하여
들어가며
"디자인 시스템은 확장할 수 있고 지속 가능한 방식으로 디자인을 위한 구성 요소를 출력하는 체계적인 접근법이다" - 쉐인 윌리엄스(Shane Willams)
디자인 시스템 관련하여 공감 가는 문구가 있어 가져와보았다.
맞다. 디자인 시스템은 지속 가능하면서 통일된 디자인을 효율적으로 할 수 있도록 해주는 시스템이다.
이것은 비단 디자이너뿐 아니라 개발자에게도 적용될 수 있으며 '디자인'이라는 단어가 들어가 있다고 해서 디자이너에게만 국한되는 것이 아니다.
이러한 디자인 시스템을 구축하는 데 있어서 가장 고민이 되는 것 중 하나가 네이밍 규칙을 정하는 부분이다. 네이밍 관련해서는 디자인 시스템 만들기-1편에서 다루었으나 그 뒤에 현재 펼쳐지고 있는(?) 나의 상황을 보았을 때 부족한 부분이 많다고 생각되어 추가적으로 디자인 토큰에 관련한 글을 정리하려 한다.
우리 팀은 앞으로 디자인 토큰 하나로도 머릿속에 어떠한 디자인인지 그려질 수 있게끔 디자인 토큰명을 설정하려 하고 있으며 통일된 규칙의 디자인 토큰으로 개발팀과 동일한 네임으로 소통할 수 있고자 노력하고 있다. (개발자 코드와 피그마에 설정된 컴포넌트 명의 일치를 꿈꾸며)
1. 디자인 토큰이란?
디자인 토큰은 색상, 애니메이션, 간격, 글꼴 등과 같은 것을 설명하는 디자인 변수를 저장하는 데 사용하는 요소이다. 디자인 토큰은 디자인 시스템의 시각적 디자인 요소로 구체적으로 시각적 디자인 특성을 저장하는 것이라고 볼 수 있다.
출처 https://uxdesign.cc/design-tokens-cheatsheet-927fc1404099위 이미지의 컬러 토큰을 보면 'color-background-button' 명칭으로 해당 컬러가 버튼의 배경 색상에 쓰이는 컬러라는 것을 누구나 머릿속에 그릴 수 있다.
2. 그럼 이제 디자인 토큰 정하면 되는거 아니야?
디자인 토큰명을 정하여서 개발자와 디자이너 모두 편하게 사용하면 되겠구나!라는 것이 첫 번째 접근이었고 이렇게 쉽게 끝이 나나 싶었다. 하지만 막상 디자인 토큰명을 정하다 보니 넘어야 할 산들이 하나둘씩 나타나기 시작했다.
첫 번째, 디자인 토큰명을 표기하는 방식에 대한 개발자와 디자이너의 관점 차이
네이밍 규칙 1탄에서 우리 디자인팀은 스네이크 방식의 풀네임 소문자로 디자인 토큰을 표기하기로 하였다.
하지만 막상 개발팀과 회의를 하다 보니 개발팀에서는 최대한 약어로 코드를 짜기를 원하였고 스네이크 방식보다는 카멜 방식에 익숙하였다.
예를 들어 헤더의 폰트 크기를 디자인팀에서는 header_01로 하고 싶다면 개발팀에서는 h1으로, 액티브 버튼을 디자인팀에서는 button_active라고 하고 싶다면 개발팀에서는 btnActive 이런 식으로 하기를 원했다.
숫자 표기도 디자인팀에서는 01, 02처럼 두 자릿수로 표기하는 것이 익숙하였으나 개발팀에서는 1,2 이런 식으로 사용하는 게 익숙하였다.
어떤 것이 더 좋은 방식이냐라고 할 수 없는 것이 각자 일하는 포지션에 따라 사용하는 방식들이 다르고 그러다 보니 이건 이게 맞으니 이렇게 갑시다!라고 누구 하나 단칼에 정할 수가 없었다.
그래서 이 부분은 다시 여러 레퍼런스들을 찾아보고 이야기하기로 하였다. 각 팀의 편의성이 아닌 프로덕트 제작이라는 하나의 목표를 두고 어떠한 것이 가장 효율적인 지를 알아보기로 하였다.
두 번째, 디자인 토큰 이름 짓기의 어려움
라인의 디자인 토큰 네임LINE은 위와 같은 디자인 토큰 네이밍 규칙을 갖고 있다. 맨 첫 부분에는 서비스명을 놓고 그다음에는 비주얼 요소 그리고 카테고리 등의 순서를 취하고 있다.
이런 식으로 우리팀의 토큰 네이밍 규칙을 정한다고 했을 때 지금 총 4명의 디자이너가 토큰을 생성할 때마다 어느 곳에 어떤 것을 넣어야 하는지를 알기 어렵다는 것이다.
내가 만약 'brunch'라는 서비스를 오픈하는 데 있어 텍스트 컬러를 설정한다고 한다면 brunch_typography_color_blue_100 이렇게 해야 하는 것인지 아니면 brunch_color_typography_blue100으로 해야 하는지 순서와 명칭이 헷갈리고 이는 디자이너 각자마다 다를 수 있다. 왜냐하면 각자가 생각하는 카테고리가 다를 수 있기 때문이다.
그리고 매번 디자인 토큰명을 생성하고 업데이트하고 공유하는 것도 굉장히 번거롭고 효율적이지 못하다. 그래서 디자인 토큰명을 자동 생성해주는 Generator가 있는지 알아보기로 하였는데 지금까지는 찾지 못했다.
그래서 이러한 Generator가 없다면 토큰으로 나올 수 있는 요소들을 각 카테고리마다 정리하여 놓고 그 안에서 디자이너들이 조합하여 쓰는 것이 좋을 것 같다는 의견이 나왔다.
어떠한 디자인 토큰을 만든다고 했을 때 미리 만들어 놓은 선택지에서 선택하여 자동으로 완성되는 이상적인 프로세스!를 만들기 위해서.
지금까지의 결론
이처럼 디자인 토큰명을 정하는 데에 개발팀과의 합의, 그리고 어떠한 규칙으로 토큰 네이밍 규칙을 정하고 이를 효율적으로 운영할 수 있을까에 대한 고민 등 디자인 토큰을 정하는 데에 상당히 신경 써야 할 것들이 많았다.
하지만 이 부분을 최대한 세세하게 설정하여 가져 가야지만 뒤에 본격적으로 시스템들을 만들어가기 시작할 때 혼동이 없고 빠르게 진행할 수 있기에 조금 시간이 들더라도 이 부분을 다시 짚고 넘어가기로 하였다.
만약 디자인 시스템을 처음부터 구축하시는 분들이 계시다면, 꼭! 디자인 토큰명을 어떻게 가져갈 것인지 레퍼런스를 많이 찾아보고 디자인팀 안에서 협의하고 그리고 개발팀과 협의하여 이 부분을 정하고 시작하기를 바란다.
우리 팀도 지금 다시 네이밍 규칙에 관련하여 조사하고 개발팀과 회의를 하기로 하였는데,
어떻게 합의가 되었고 진행이 되기로 하였는지는 (2) 탄에서 공유! 하겠다.
p.s. 여기 디자인 토큰 네이밍을 보면 우리가 지향하는 것과 가장 닮은 것 같다
https://www.lightningdesignsystem.com/design-tokens/#category-border-color
