디자인 시스템 구축 (Icon Naming)
프로덕트 디자이너의 디자인 시스템 제작 이야기 - 3
하나의 폰트로 변경 후, 작업자들의 혼란을 주었던 아이콘 네이밍 규칙을 정하기로 했다.
작업자들 사이에서 공통된 이름이 없으니 서로 다른 말을 하고 있는 경우가 많았고,
“아이콘 이름을 어떻게 써야 작업자들이 서로 편할까?”라는 고민으로 진행했던 이야기를 해보려 한다.
Chapter 3. 아이콘 네이밍 규칙 정하기
- 변수 표기법에 대해 알아보기 (리서치)
- 타 브랜드 네이밍 규칙 살펴보기 (리서치)
- 브런치 글 참고하기
- 우리만의 규칙 세우기
나는 어떤 프로젝트든.. 리서치의 시간이 중요하다고 느끼고 많은 정보를 얻기 위해 시간을 쏟기도 한다.
이번 프로젝트에서는 변수 표기법, 타 브랜드의 네이밍 규칙에 대해 리서치를 했고, 리서치 도중 알게 된 브런치글을 참고해서 진행했다.
1. 변수 표기법에 대해 알아보기
변수 표기법의 종류에는 기본적으로 카멜, 스네이크, 파스칼, 케밥 표기법이 있다.
이 4가지 특징은 무엇이 있는지 살펴보았다.
카멜 표기법 (Camel case)
카멜 표기법은 단어 전체를 소문자를 사용하지만, 맨 첫 글자를 제외한 각 합성어의 첫 글자만 대문자로 표기한다. 합성한 단어의 모양이 쌍봉낙타의 등과 비슷하다는 뜻에서 이름이 붙여졌다고 한다.
Ex. isCamelCase
스네이크 표기법 (Snake case)
스네이크 표기법은 단어 전체를 소문자로 사용하고, 띄어쓰기를 언더바(_)로 표기한다.
변수의 형태가 뱀과 같다는 뜻에서 이름이 붙여졌다고 한다.
Ex. is_snake_case
파스칼 표기법 (Pascal case)
파스칼 표기법은 카멜 표기법과 유사하지만, 맨 첫 글자도 대문자로 표기한다.
그래서 이 표기법을 쌍봉낙타 표기법이라고 불린다고도 한다.
Ex. IsPascalCase
케밥 표기법 (Kebab case)
케밥 표기법은 스네이크 표기법과 유사하지만, 언더바(_) 대신 하이픈(-)을 사용하여 표기한다.
하지만 많은 개발 언어가 하이픈을 지원하지 않기 때문에 해당 예시는 제한적이다.
Ex. is-kebab-case
정보 출처 : 위키백과 / 구글
2. 타 브랜드의 네이밍 규칙 살펴보기
Line
라인은 제공하는 서비스가 글로벌하여, 맨 처음에 글로벌인지, 패밀리 서비스인지 서비스 명을 먼저 보여주고, 비주얼 요소, 상세 카테고리를 조합하는 방식으로 나열했다.
아래 예시를 보면 사용되는 단어를 축약시키지 않고 풀 네임으로 사용해 직관적으로 어떤 요소인지 알기 편하게 해 두었다. 다만, 네이밍이 길어질 수 있다는 단점도 있어 보였다.
밀리의 서재
밀리의 서재의 아이콘 네이밍은 케밥 표기법과 스네이크 표기법을 혼합해서 활용했다.
맨 마지막 라인 두께에만 언더바(_)를 사용했다.
'비주얼 요소 - 아이콘 기능 - 사이즈 - 라인 두께' 순으로 이름을 표기했고, 라인과 마찬가지로 네이밍을 축약하지 않고 풀 네임을 사용하고 있었다.
G마켓
G마켓의 아이콘 네이밍은 케밥 표기법을 활용했으며, 다른 브랜드 가이드와는 다르게 기능보다 형태의 기준으로 이름을 표기하고 있었다. 형태보다 기능이 명확한 경우에만 기능의 이름을 붙이도록 가이드되어 있다.
이미지 B의 예시를 보면 기능은 favorite이지만, 모양 형태인 heart로 표기하는 등 아이콘 이름은 직관적이고 재활용 가능하도록 설계되었다.
3. 기타 (다른 디자이너의 브런치글 참고)
디자인 시스템 관련 구글링하다가 "Pizza Kim"님의 브런치 글을 보게 되었다.
글에는 이름 짓기를 할 때 공통으로 지켜야 할 5가지, 네이밍 규칙의 큰 구조 등 도움이 될 만한 내용들이 많았다. 이 글이 이번 프로젝트를 진행하면서 저에게 큰 도움이 되었으며, 저와 같은 고민을 하고 있다면 한 번 읽어보면 좋을 것 같다.
https://brunch.co.kr/@pizzakim/26
4. 우리만의 규칙 세우기
네이밍 규칙에 관해서 개발 코드에서 오류 없이 표기하기 용이해야 하므로, 이번 프로젝트에서 개발자들의 의견을 많이 수렴했다.
우선 스네이크 표기법을 활용해서 언더바(_) 표기를 하기로 결정했다.
그리고 우리는 리서치와 다르게 풀네임 표기법보다는 icon = ic / image = img / button = btn 등 축약을 사용하기로 했다. 그 대신 그 뒤로 붙는 사이즈, 특징, 상태 값에 대해 더 세분화하기로 했다.
asset type ⇒ icon (ic로 표기)
namespace ⇒ 크게는 해당 화면 or 공통적으로 쓰인다면 위치
asset name ⇒ 아이콘이 가지고 있는 기능
add a qualifier ⇒ 특징 (방향 + 면 or 라인 + 상태 + 사이즈 + 컬러)
우리는 사이즈가 마지막이 아니라 컬러를 마지막으로 했다. 생각보다 같은 사이즈에 다양한 컬러를 사용하고 있는 아이콘들이 많아 컬러 베레이션이 더 중요하다고 느껴졌다.
글을 마치며..
구축하면서 함께 디자인 가이드를 정립해 나가는 프로젝트는 많이 해봤지만,
이렇게 기존에 있던 디자인에서 개선을 하는 건 어려운 일이었다.
개발자는 코드에서 아이콘을 하나하나 다 찾아서 네이밍과 아이콘 이미지를 변경하고,
디자이너인 나도 피그마 화면에서 새롭게 컴포넌트화 시킨 아이콘을 기존 화면에서 하나하나 찾아서 변경하는 노가다 수작업을 하고 있지만 이번 한 번의 고생이 앞으로 작업이 수월해질 거라 믿는다..
"Chapter4. 후기"로 다시 올게요:)
