[STUDY] 디자인 시스템 네이밍

구름·2024년 3월 1일

study

📃디자인 시스템 명명 규칙

1. 명확성, 직관성, 자명함 (clarity, obviousness, self-evidence)

혼동하지 않고 바로 이해할 수 있는 이름
약어를 쓰더라도, 바로 어떤 것을 의미하는지 파악할 수 있어야 함

2. 조직적 일관성 (consistency & organization)

명칭은 일정한 순서와 규칙을 지니고 있어야 찾고 사용하기 쉬움
동일한 객체에 대하여 동일한 명칭을 적용

3. 접두사와 접미사의 활용 (prefixes & suffixes)

서로 다른 타입의 디자인 요소를 구분하기 위하여 접두사, 접미사 활용
- 예) button - btn, label - lbl 축약하여 명칭의 앞 뒤에 붙임

4. 카멜 케이스나 케밥 케이스와 네이밍 규칙

명칭을 만들 때 스펠링 적용에 있어서 특정 스타일을 표시해야 함

5. 상호배제성 (uniqueness)

중복 사용으로 인한 충돌을 방지하기 위해 상호배제된 네이밍을 사용함

6. 버전 관리 (version control)

숫자나 날짜를 표기하여 각 디자인의 이력을 추적하고, 최신 버전의 디자인을 사용할 수 있도록 함

7. 문서화 (Documentation)

디자인 시스템에 대한 문서화를 지속적으로 업데이트하여 새로운 팀원이 빠르게 적응할 수 있도록 함

💡효과적인 디자인 시스템 구조화 방법

1. 알파벳 순서로 분류

2. 디자인 원자에 맞는 분류
- 텍스트 스타일, 폰트, 컬러, 버튼, 아이콘 등

3. 사용 목적에 따른 분류
- 탐색 (Navigation) : 사이트나 어플리케이션으로 이동하는 요소
- 양식 (form) & 인풋 (input) : 버튼, 텍스트 박스, 체크 박스와 같이 양식에서 사용되는 요소
- 미디어 요소 : 이미지, 비디오, 갤러리와 같은 멀티미디어 컴포넌트
- 표시 (indicator) & 알림 (notification) : 진행 바(progress bar), 오류 메시지, 알림 등
- 페이지 구조 : 헤더, 푸터, 사이드바와 같은 페이지의 구조적 요소

4. 콘텐츠 타입에 따른 분류
- 텍스트 콘텐츠 : 제목, 문단, 인용 등의 요소
- 멀티미디어 콘텐츠 : 이미지, 비디오, 아이콘과 같은 요소
- 목록 : 숫자 목록, 글머리 기호와 같은 목록과 관련된 요소
- 표 : 표의 스타일과 디자인 요소
- 양식 : 인풋, 버튼, 드롭다운 등의 요소

5. 디자인 복합성에 따른 분류
- 기본 요소 : 버튼, 텍스트 필드와 같은 간단한 컴포넌트
- Compound 요소 : 카드, 패널 등 여러 기본 요소들을 조합하여 만든 디자인 컴포넌트
- 페이지 : 다양한 컴포넌트와 디자인 요소를 포함하여 완성된 페이지

6. 사용 맥락에 따른 분류
- 홈페이지, 프로필, 블로그와 같이 특정 사용 맥락에 따른 단위로 묶는 것

✅Naming Convention 네이밍 컨벤션

스네이크 케이스 : html class 명으로 주로 사용
- 단어 사이 띄어쓰기 대신 언더바 사용
- 예) snake_case
케밥 케이스 : html class 명으로 주로 사용
- 단어 사이 띄어쓰기 대신 하이픈(-) 사용
- 예) kebab-case
카멜 케이스 : html id 명, JS의 함수 명명으로 주로 사용
- 단어 사이 띄어쓰기 대신 대문자로 표기
- 예) camelCase
파스칼 케이스 : JS의 객체 명명에 사용
- 단어의 시작을 모두 대문자로 표기
- 예) PascalCase
헝가리언 표기법
- 단어의 접두어를 사용하며 표기
- 예) strName (str -> string)
- 예) btnStart (btn -> button)
- 예) bBusy (boolean -> b)

✅ICON 네이밍

💡Basic Principle

1. 제작한 아이콘들에 대해 일반적, 규칙적, 범용적 네이밍 시스템을 사용하자.

이미지 파일들의 이름이 관련 있는 것 끼리 디렉토리 내에서 그룹핑 되도록!

2. 논리적이고 예측 가능한 직관적인 명칭을 붙여주자

아이콘의 기능이 아니라 형태에 맞춰서 이름을 붙이자.
그 아이콘이 다른 곳에서는 다른 요소로 재활용 될 수 있음

3. 아이콘에도 효율적인 관리가 필요하다

밀도는 다르지만 이미지는 같은 아이콘 파일은 동일한 이름을 사용하자.
저장 시 밀도별 리소스 디렉토리에 각각의 경로로 저장되어 충돌이 일어나지 않음(안드로이드 스튜디오 한정)

4. 디자인 팀 단위, 프로젝트 단위의 명명 규칙을 설정하면 누구나 따라야 한다.

일관성 있는 네이밍 룰 : 시스템이 커지더라도 아이콘의 속성과 해당 에셋이 어디에 사용되는지 쉽게 알 수 있음
비정형적, 추상적, 외우기 어려운 전문 용어는 피하자 : 커뮤니케이션에 혼선을 가져옴
임시 이름은 사용하지 말자 : 배포 이후 네이밍 변경은 번거로움

5. 좋은 네이밍 규칙은 디자인 리소스를 아낄 수 있다!

How to❓

기본적인 규칙

미국식 알파벳 소문자 a-z, 언더바, 숫자 0-9가 유효하다.
아이콘 이름의 첫 글자는 숫자가 될 수 없다.
확장자에도 대문자를 사용하지 않는다.
공백을 사용할 수 없다.
- AOS : 언더바(_) 사용
- iOS : 하이픈(-) 사용
에셋 이름은 앱/화면 전체에서 고유해야 한다.
- 크기가 다른 두 개의 add 버튼이 있을 경우, 같은 네이밍으로 지정할 수 없다.
- 두가지 이름을 붙여 다양한 밀도에 대응하자.

네이밍 규칙의 구조

🔴 asset type : What? 이 리소스는 무엇인가?
- 예) icon - ic, button - btn, image - img, background - bg
🔴 namespace : Where? 논리적으로 속한 위치
- 여러 화면에서 사용되는 아이콘은 namespace를 따로 붙이지 않는다.
- 구체적인 하위 클래스에 속하는 아이콘에만 location에 해당하는 namespace를 추가한다.
  - 예) 내비게이션 - 'ic_navi_xxxx.png'
    - 예) 런쳐 - 'ic_launcher_xxx.png'
    - 예) 탭바 - 'ic_tab_xxxx.png'
🟡 root : 에셋의 고유 이름
- 해당 아이콘을 가장 잘 설명할 수 있는 명사
- 구체적이고 특징적인 묘사 or 메타포로 네이밍
  - 예) arrow, check_box, chevron, error, cancel, radio_btn, star 등

🔵 suffix : 🔴영역과 🟡명사의 조합으로 이름을 만들었으나, 동일한 이름이 이미 다른 아이콘에 사용되어 충돌하는 상황에 부가적으로 한정자(qualifier)를 추가
```
	- direction : 모든 방향을 지닌 것들을 추가
```
- 예) right, left, up, down, horiz, vert
- shape : 아이콘의 고유 형태에 대한 구체적인 언급이 필요할 때
- outline : 축약하여 o만 붙이기도 함. filled가 디폴트일 때 예외 케이스에서 아웃라인만의 아이콘이 필요할 경우 (iOS처럼 아웃라인이 디폴트일 경우 생략)
- status : control status에 대한 묘사가 필요할 때
- color : black, white, pink, gray500 등 외의 다른 특별한 설명이 필요하다면 HEX코드로 표기
- size : 구체적인 dp값, small/medium/big 또는 @2x, @3x 등