Handy 디자인시스템 토큰 구축과정
디자인시스템 구축기#7
어느 정도 Founation 구축이 완료된 시점이다.
개발팀과의 회의를 통해 Handoff룰을 정하고 기본적인 primitive 컬러토큰과 타이포를 전달했다.
이제는 디자인토큰을 정립해야 했다.
디자인토큰이란?
디자인 시스템 관점에서 디자인 토큰(Design Tokens)은 디지털 제품의 디자인 속성을 표준화하고 일관되게 유지하기 위해 사용되는 중요한 구성 요소이다. 디자인 토큰은 색상, 타이포그래피, 간격, 그림자 등의 디자인 속성을 코드로 정의한 것이다. 이로 인해 다양한 플랫폼과 장치에서 일관된 디자인을 유지할 수 있다.
쉽게 설명하면, 디자인 토큰은 디자이너와 개발자 사이의 공통 언어 역할을 한다. 예를 들어, 특정 브랜드의 주 색상을 #FF5733이라고 정의한다고 가정해 보자. 이 색상을 사용하는 모든 곳에 "primary-color"라는 토큰을 사용할 수 있다. 이렇게 하면 디자이너가 색상을 변경하면, 코드의 모든 "primary-color"가 자동으로 업데이트되어 일관성을 유지할 수 있다.
디자인토큰 구축 과정
이전 디자인시스템에서는 variable 기능을 사용하지 않고 style로 모든 토큰을 구축했다고 한다. 하지만 이번 디자인시스템 구축에서는 피그마의 variables기능을 적극 활용해 보기로 했다. 먼저 위와 같이 variables 창에서 primitive page를 생성해서 Handy의 팔레트와 기본 간격을 구축해 뒀다.
그리고 Primitive Token은 디자이너들이 디자인을 하면서 사용하는 컬러가 아닌 Semantic Token에 참조되는 역할이기에 Scoping 기능을 통해 사용하지 못하도록 설정해 두었다. (이전 디자인시스템에서는 Style을 활용했기에 Primitive Token을 사용하는 경우가 있어 여러 문제가 발생했다고 하는데, Variables 기능의 효율을 느낄 수 있는 작업과정이었다)
Primitive 구축이 끝났다면 이제 실제로 사용될 컬러에 기능을 정의해 주는 Semantic Token을 구축할 차례이다.
Semantic Token을 구축하기에 앞서 두 가지 문제점이 있었다.
1. 토큰의 네이밍 방식을 어떻게 정의할 것인가?
2. 컴포넌트마다 모두 컬러토큰을 만들어주면 UI디자이너가 스타일을 넣어줄 때 스타일창의 너무 많은 컬러로 인해 혼동이 올 수 있지 않을까?
먼저 1번에 대한 네이밍 방식 문제는 다음과 같은 네이밍으로 해결했다. 우리는 Primary, Secondary와 같이 버튼에도 계층을 나누어 다른 색상을 적용하기에 variant값을 두 번째로 넣어주고, 상태에 따른 색상도 구분하기에 세 번째로 상태값을 넣어주었다. Size는 컴포넌트마다 있는 경우가 있고 없는 경우도 있어서 경우에 따라 생략이 가능한 방식으로 정의했다. 마지막으로 모든 토큰 맨 앞에 어떤 컴포넌트를 위한 토큰인지 인지가 가능해야 하기에 당연히 Property를 앞단에 넣어주었다. 예시는 btnPrimaryDisabled와 같은 방식으로 네이밍이 될 예정이다.
2번 문제에 대한 해결책의 결론은 '간결한 토큰을 구축하려다 오히려 헷갈림이 생길 수 있다'였다. button, checkbox, FAB와 같은 컴포넌트에 모두 같은 bg토큰을 넣으면 토큰 개수가 줄어드는 건 사실이다. 하지만 우리의 사용자는 디자인시스템을 구축한 고학년 디자이너가 아닌 디자인시스템에 아직 익숙하지 않을 수 있는 대학교 1, 2학년 저학년 디자이너다. 따라서 토큰의 개수가 많아지더라도 정확히 어떤 요소에 어떤 토큰을 넣어야 하는지 명시를 해주는 것이 오히려 쉬운 디자인시스템으로 갈 수 있다는 결론이 나왔다.
위 이미지를 보면 button의 계층별로 자세하게 토큰을 정의한 것을 확인할 수 있다.
