디자인시스템을 만드는 과정 - (2) 토큰 생성하기
이전 편을 보고 오시면 글을 읽는데 도움이 됩니다!
[이전 편] 디자인시스템을 만드는 과정 - (1) 기획 https://brunch.co.kr/@sumsumhouse/2
지난 글에서 기존 디자인 시스템이 갖고 있던 문제 4가지를 발견했어요.
문제정의를 통해 디자인 시스템 v.2를 만들기로 결정하고, 디자인 토큰을 생성하기로 했는데요.
왜 오일나우 디자인 시스템을 개편하려면 디자인 토큰을 개발해야 했는지 그 이유를 먼저 알려드리고자 합니다!
[이런 내용을 담고 있어요]
- 제가 느낀 디자인 토큰의 장점(디자인 가이드/디자인 동기화)에 대해 설명해요.
- 기존 서비스 화면을 토대로 디자인 토큰을 구축하는 과정을 설명해요.
디자인 토큰, 왜 만들었나요?
디자인 토큰은 디자인 시스템의 가장 기본적인 구성 요소를 이루는 근간이에요.
서비스 내에서 공통적으로 사용하는 색상, 글꼴 크기, 간격, 그림자, 둥근 모서리 등의 디자인 요소를 정리하고,
그 값이 쓰이는 규칙에 따라 이름을 지어줘요. 예를 들어 —color-red-400: #F8535A 과 같은 형태가 있어요.
디자인 토큰의 가장 큰 장점은 1) 디자인 가이드의 역할을 하고,
2) 디자인↔개발을 완전동기화할 수 있다는 점 때문에 디자인 토큰 개발이 필요했는데요.
어떻게 디자인 가이드 역할을 하나요?
디자인 토큰은 색상, 타이포그래피, 간격, 그림자 등의 디자인 요소가 우리 서비스에 어떻게 쓰이고 있는지 의미를 담을 수 있기 때문에 디자인 가이드가 될 수 있어요.
이전에는 디자인 가이드로 ‘에러를 나타낼 때는 #F8535A를 사용합니다.’를 설명해야 했지만,
이제는 color-feedback-error 라는 색상의 이름만 보고도 에러를 나타내는 텍스트인 걸 알 수 있어요. 디자인시스템을 함께 공유하는 메이커가 ‘오류를 나타낼 때는 텍스트에 이 토큰을 쓰면 되겠다’고 인지할 수 있죠.
앞으로 모든 디자이너가 오류를 표현할 때마다 이 토큰값이 사용될 거고, 이를 통해 제품 전체에서 일관된 시각적 경험을 제공할 수 있어서 여러 디자이너와 개발자가 작업해도 통일된 결과물을 만들 수 있어요.
어떻게 디자인↔개발 간 완전 동기화가 가능한가요?
토큰은 중앙(디자인)에서 통제하는 시스템이기 때문이에요. 토큰의 생성 및 사용 흐름은 아래와 같은데요.
디자이너가 생성 및 수정 → 배포 → 스타일 딕셔너리로 변환 → 안드로이드 / iOS / 웹 패키지에 업로드 → 개발자가 사용
디자인 변경 시 토큰 값만 수정하면 연결된 모든 컴포넌트와 페이지에 자동으로 반영할 수 있어요.
예를 들어 브랜드 리브랜딩으로 디자인 컬러 팔레트를 수정해야 하거나, 특정 컴포넌트의 폰트나 모서리값 등을 변경하고 싶을 때, 수백 개의 파일을 각 파트의 개발자들이 개별적으로 수정할 필요가 없어져요.
따라서 디자인 가이드가 부족하고, 개발과 디자인이 동기화되어있지 않던 기존 디자인시스템의 문제를
디자인 토큰으로 해결할 수 있었으며
디자인 가이드를 제작하거나 다른 방식을 고려하는 것보다 효율적이었기 때문에 토큰 구축을 계획했어요.
디자인 토큰 제작기
라고 쓰고 두 달 삽질기라 부릅니다
STEP 1) 우리 제품의 디자인 규칙 정리하기
디자인 토큰을 생성하기 전에 우리 제품에 어떤 디자인 규칙이 존재하는지 알아야 했어요.
예를 들어
‘브랜드 키 컬러는 #4500FF를 사용하고 있다’,
‘error를 나타낼 때는 #000EFS를 사용한다’,
페이지 타이틀은 24pt, 28pt 크기의 텍스트를 사용한다’,
‘폰트패밀리는 한글은 pretendard, 영어는 suits를 사용한다’ 등이에요.
이렇게 떠올리면 끊임없이 발산하게 되죠. 어떻게 규칙을 정리할지 기준을 먼저 찾아야 했어요. 오일나우 앱 화면을 띄워놓고, 디자이너가 어떤 값을 수정해서 화면을 만들어내고 있는지를 이해하고자 했어요.
컴포넌트를 기준으로 규칙을 찾아볼까?
첫 번째로, 디자이너는 페이지 내에서 컴포넌트를 수정할 수 있어요. 버튼, 카드, 입력필드, 배너 등의 디자인을 변경해서 화면을 만들어요. 그렇다면 컴포넌트를 기준으로 토큰을 규정해야 할까요?
컴포넌트를 기준으로 토큰으로 규정했더니 똑같은 색상인데 의미가 다른 토큰이 무수히 많아졌어요.
버튼의 컴포넌트와 색상을 대응시켜 토큰을 생성하면 컴포넌트별로 색상을 정의해줘야 하는데, 만약 #5783FC 라는 색상 대신 #ffffff을 사용하게 된다면, 컴포넌트별로 찾아서 색상을 바꿔줘야 하니 매우 비효율적인 토큰체계가 되거든요.
따라서, 여러 컴포넌트에 범용적으로 사용할 수 있는 더 작은 단위를 찾아서 토큰명을 정의해야 했어요.
컴포넌트보다 더 작은 구성요소를 기준으로 규칙을 찾아볼까?
컴포넌트보다 더 작은 단위로 화면을 분석해 보았어요.
오일나우의 주유소 카드는 background, text, icon와 몇 button로 구성되어 있어요.
background는 색상, 그림자 등과 관련되어 있고,
text는 타이포그래피와 색상,
icon은 에셋, 색상, 크기를 수정할 수 있어요.
그렇다면 색상, 크기 등에 대한 규칙이 필요하고, background, text, icon 등에 규칙이 적용되어야 한다는 걸 깨달았어요. 우리가 어떤 체계의 규칙을 만들어야 하는지 명확해졌어요.
다음으로 오일나우의 모든 페이지가 정리된 파일에 들어가서, 모든 콘텐츠들을 복사하여 하나하나 분류하는 가내수공업을 거쳐서 아래와 같은 색상 규칙을 정리할 수 있었는데요.
이때 색상 별 공통점을 또 발견할 수 있었어요.
warning을 표현하기 위해 red/400을 사용함
주의/경고를 표현하는 상황에서, 모두 공통된 색상으로 시스템 피드백을 반환한다는 사실을 발견했어요. 그래서 text, icon, background 각각에 warning 색상 토큰을 생성하지 않고, feedback/warning이라는 토큰을 만들어서 보다 효율적인 토큰 시스템으로 변경했어요.
*혹시라도 UI별로 경고에 쓰이는 색상을 차별할 가능성이 있다면,
color/text/feedback/warning, color/icon/feedback/warning .. 으로
요소별 토큰을 한 번 더 추상화하는 걸 권장드려요.
컴포넌트 위계를 높이기 위해서 브랜드 키 컬러인 blue 계열을 사용함
모든 값에 강조를 위해 브랜드 키 컬러인 blue/400을 사용할 수 있었어요.
이 또한 프로퍼티별로 토큰을 개별 생성하기보다 강조의 의미를 담은 토큰명으로
‘accent/blue’라는 토큰을 생성하여 통일했어요.
text와 icon의 위계별 색상이 매우 유사함
텍스트와 아이콘은 disabled의 색상만 다를 뿐, 다른 위계와 상태에서는 비슷한 값을 사용했어요.
text, icon으로 각각 분류하지 말고, label이라는 토큰을 둬서 text와 icon에 쓸 수 있도록 했어요.
색상값이 다른 disabled는 feedback/disabled/normal, feedback/disabled/heavy 라는 토큰을 만들어서 사용하고자 했어요.
그래서 더 효율적인 시스템이 되었을까요?
아뇨, 다시 삽질해야 했어요 (ㅠㅠ)
STEP 2) 도그 푸딩을 통해 토큰 카테고라이징 개선하기
토큰을 개발에 전달하기 전에, 피그마 라이브러리에만 토큰을 퍼블리싱하여 시범운영을 해보았는데요..
좀 더 적은 효율적으로 색상을 관리하기 위해 탄생한 ‘disabled’ 토큰에 문제가 있었어요.
이전에는 text가 disabled 상태라면 text/disabled 토큰을 사용하면 됐는데,
토큰 생성 후에는 disabled/normal을 사용해야 하는지, disabled/weak를 사용해야 하는지 헷갈렸어요.
불명확한 디자인 가이드를 개선하고자 도입한 디자인 토큰이 오히려 디자이너에게 혼란을 줬어요. label토큰을 다시 text와 icon로 분리하고, 각각 disabled 토큰을 생성해서 관리하기는 걸로 변경했어요.
변경 후에는 요소마다 disabled가 있기 때문에, 고민하지 않고 색상을 선택할 수 있게 되었어요.
디자인 토큰을 구축하며 "디자인 시스템은 메이커들의 생산성을 효율적으로 올려주는 제품이니, 무조건 효율적으로 만들어야 해!"라는 생각에 매몰되어 있었는데요.
단순한 것이 무조건 효율적인 게 아니라는 걸 알게 되었어요. 쉽게 이해할 수 있고 더 많이 쓰이는 시스템이 되려면 서비스 뒷단에서 더 많은 케이스를 고려하고 결정해야 한다는 걸 느꼈어요. 또한, 직접 써보지 않고 그대로 토큰을 생성했다면 이후에 수정사항이 매우 많았을 거예요. 디자인시스템 또한 시스템 사용자들의 꾸준한 피드백을 통해 개선해야 함을 깨달았어요.
디자인 토큰이 정리되면 개발에서도 사용할 수 있도록 토큰을 내보내야 해요.
다음 글에서 오일나우는 어떤 방법으로 디자인 -> 개발로 토큰전송을 하고 관리하는지를 토큰 자동화 구축기와 함께 알려드리고자 합니다!
읽어주셔서 감사합니다!
저는 다음 글로 찾아올게요.