디자인 토큰 네이밍 규칙
프로덕트를 만드는 데 있어서 '디자인 시스템'을 구축하는 것은 매우 중요하다.
여러 디자이너가 하나의 프로덕트를 만든다면 더더욱이나 디자인 시스템이 반드시 필요하다.
디자인 시스템을 통하여 디자이너는 일관성 있는 디자인으로 유저에게 통일된 UX 환경을 제공함으로써 브랜딩을 강화하고 업무의 효율을 높일 수 있으며 개발자 또한 업무 시간을 효과적으로 단축시킬 수 있다.
디자이너와 개발자가 소통함에도 통일된 디자인 토큰명을 사용하면 커뮤니케이션에 오해가 없고 업무 프로세스를 줄일 수 있다.
현재 우리 팀의 디자인 시스템(내가 입사하기 전)은 피그마로 디자인 시스템을 구축하고 storybook 서비스를 활용하여 웹상에서 디자인 시스템을 확인할 수 있는 환경을 구축하고 있었다.
하지만 프런트팀과 디자인팀에서 사용하는 컴포넌트 명칭의 불일치, 버전 관리와 관련된 이슈들이 발생하였고 이에 따라 디자인 시스템을 새롭게 개편하기로 하였다.
그 첫 번째 스텝으로 디자인 토큰의 네이밍 규칙을 정하기로 하고 리서치를 진행하였다.
RIDI는 컴포넌트 이름을 띄어쓰기나 ‘-’이 없는 *파스칼 표기법을 적용하였다.
디자인 토큰의 네이밍 규칙은 찾을 수 없었으며, 아이콘 명은 형태의 이름을 따라가나 형태보다 기능이 명확한 경우 기능의 이름을 적용한다.
*표기법에는 파스칼, 스네이크, 케밥 표기법이 있다.
파스칼은 띄어쓰기 없이 첫 글자를 대문자로 표기하여 쓰는 방식이다.
스네이크 표기법은 모두 소문자로 표기하며 단어 사이에 '_'을 기입한다.
ex) user_login_01
케밥 표기법은 글자 사이에 '-'를 넣는다.
ex) user-login-page
라인은 명확히 디자인 네이밍 규칙을 명시한다.
라인은 제공하는 서비스가 많기 때문에 가장 첫 부분에 해당 서비스 명을 붙이고 그다음에는 color, typography와 같은 비주얼 요소 명칭 그리고 그 뒷부분에 세세한 속성 값들을 합의한 순서대로 기입하여 디자인 토큰을 생성한다.
ic, typo처럼 약칭을 사용하지 않고 풀네임을 사용하여 명확히 어떠한 요소인지 알 수 있다는 장점이 있으나 디자인 토큰명이 길어진다는 단점이 존재한다.
밀리의 디자인 시스템은 네이밍 규칙을 명시하고 있지 않다.
폰트, 컬러와 같은 foundation 영역에는 앞부분에 토큰을 명시하고 있다.
$표시는 Sass(SCSS)에서 사용하는 변숫값으로 우리 조직에서는 Sass를 사용하고 있지 않기 때문에 토큰명 앞에 $를 붙이지 않기로 하였다.
아이콘의 컴포넌트 명은 케밥 형식으로 명칭 되어 있으며 풀네임을 적용하였다.
비주얼 요소인 'icon'을 명시하고 해당 아이콘의 기능에 기반하여 'feed'를 뒤에 붙였다.
그다음에는 아이콘 크기와 선 굵기를 표기하였다.
버튼 같은 경우에는 피그마에서 활용할 수 있는 variants를 활용하여 다양한 변수를 두었는데
명칭은 btn의 약칭을 사용하고 뒤에 /로 구분하여 primary를 적었다.
아래의 브런치 글은 어떻게 아이콘 명을 지정할 것인지에 대해 자세히 써놓아 많은 도움이 되었다.
한번 읽어보기를 추천!
출처 : https://brunch.co.kr/@pizzakim/26
우리 조직은 모든 디자인 토큰을 스네이크 형식으로 작성하며 풀네임을 표기하기로 하였다.
ex) icon_setting_solid_24
ic, btn 등의 약어는 당장 보기에는 편해 보일 수 있으나 추후 다른 컴포넌트가 추가됐을 시 명칭을 세팅하고 다시 학습하는 시간이 발생함으로 누가 보아도 알 수 이게 풀 명칭으로 작성하는 것이 효율적이라 판단하였다.
또한 아이콘과 같이 상세하게 작성해야 하는 명칭에 관련해서는 변수 값을 어디까지 줄 것인지(라인, 솔리드, 컬러, 크기 등), 변수의 순서는 어떻게 할 것인지 프런트팀과 협의하여 정의하고 피그마에 동일하게 적용하기로 하였다.
그리고 디자인 시스템 가장 앞부분에 우리의 디자인 토큰 네이밍 규칙에 대해 명시하기로 하였다.
p.s
다음 디자인 시스템 만들기-2에서는 Typography 세팅에 대해 공유됩니다.☺️