💻 UI 디자인 가이드 만들기 #1._Icon naming

Posting : 05.10.2022
Designer : 김세원
#Icon #Naming #DesignSystem #Guide

아이콘과 이미지의 네미밍 약속 [made by.sewon]

디자인 가이드 제작기 #1. Icon 과 Button의 네이밍을 정해보자.

[프론트 개발팀과 함께한 디자인 가이드 만들기]

개발자와 소통할 때마다 아이콘을 말할 때마다 너무나도 중구난방이고, 회사의 규모가 점차 커지면서 “다른 디자이너와 협업할 시에 가이드 작업을 꼭 필요하겠다.” 라고 생각을 하게 되었다.

서비스를 들어가는 초입부에 지금 확정하지 않으면 눈덩이처럼 불어나게 될 시련이 예상되었고, 하루 빨리 만들어야겠다는 생각이 들어 개발자분에게 제안을 했다. 다행이 흔쾌히 수락해주셔서*(흔쾌히 수락해주시고, 힘써주신 개발자 동료여러분 감사합니다)* 서클을 만들어 작업을 수행하게 되었다.

Progress 01_일단 시급한 것부터, 범위를 정해보자!

[컴포넌트는 왜 필요한가에 대한 니즈 정리]

일단 가장 시급한 건 아이콘이었다. 그 중에서 네이밍을 정하는 것이 급선무라고 판단을 했다.

각각의 개발자와 디자이너가 느끼는 needs 사항을 정리해서 이 작업이 왜 필요하고, 어떻게 개선이 되어야할지 정리를 해보았었다.

[시급한 우선순위부터 업무 범위 정하기]

그래서 결론적으로 큰 [카테고리]로는 Icon, 그리고 [업무 scope] 은 Icon naming, 패딩값, Button naming (Button naming은 추후에 또 다루도록 하겠다.) 까지를 이번 업무로 지정했다. 이 역시 Icon에 대해서 우리가 무엇이 필요한지 개발자와 디자이너는 각각 어떤 needs 사항들이 있는지를 정리했다.

Progress 02_작업을 수행하기 위해 리서치, 레퍼런스 찾기

디자인 시스템과 가이드 작업을 수행하기 위해 여러 기업들의 디자인 시스템 사이트들을 참고하였다. (디자인 시스템으로 만들려고 했으나 난관을 발견하여 가이드를 우선적으로 잡업하는 것으로 했다. 해당 난관 스토리는 추후 블로그에 올리도록 하겠다.)

[레퍼런스 링크]
- Ant 디자인
- 구글의 타이포, 아이콘 화
- 아틀란시안의 컴포넌트 시스템 페이지

레퍼런스 같은 경우 수많은 기업의 사이트가 있었고, 가이드도 있었으나 회사의 내부 방식에 맞는 즉, 디자이너와 개발자가 함께 이해할 수 있고 관리하기 적합한 페이지들의 부분들을 참고하였다.

디자인 시스템과 가이드를 설계하기 위해 참고한 자료들…[made by.sewon]

결국 내렸던 결론은 서비스와 디자이너, 개발자에게 맞는 아이콘 네이밍의 약속을 정하는 것이 가장 현명하겠다는 판단을 했다.

Progress 03_네이밍 작업을 수행해보자!

결과적으로 만들어진 Icon naming guide [made by.sewon]

많은 논의와 상의 끝에 우리에게 가장 맞는 방식으로 위와 같이 네이밍 규칙을 정했다. 이 때 중점을 뒀던 부분은 ’관리하기 편한가?’ + ‘한 눈에 어떤 아이콘인지 인지가 가능한가?’였다.

01. 관리하기 편한가

카테고리의 분류를 보면 /로 구분을 했다. /로 표현했을 때 figma 에서 variant를 쉽게 관리할 수 있고, variant 의 요소들을 DopDown 클릭만으로 쉽게 아이콘을 바꿀 수 있다.

피스마나 스케치에서 /로 구분한 아이콘들은 Export 하게 되면 자동으로 파일을 생성해서 관리하기 편하도록 해준다. 개발자 코드에 파일 안으로 들어가는 코드가 /를 사용하기 때문에 따로 파일관리 하지 않아도 바로 코드로 아이콘 적용이 가능하다.

피그마 페이지를 이용해 개발자 export 용을 나눠놓았다.

또한 피그마에서 디자이너들이 관리할 수 있는 asset 페이지와 개발자들이 한 번에 모든 아이콘, 이미지, 로고, gif 를 다운받을 수 있는 페이지를 나눠놓았다.

개발자들은 피그마에서 export 한 버튼만 누르면 디자이너가 설정한 파일로 관련된 모든 아이콘들을 한 번에 다운받을 수 있게 된다. 이렇게 했을 때 개발자들은 아이콘들을 찾아서 일일이 다운받거나 하지 않아도 되고, 간편해져서 편리하다는 피드백을 주었다.

02. 한 눈에 어떤 아이콘인지 인지가 가능한가?

[ 02–01. 네이밍 순서 ]

위의 네이밍 가이드를 정하기 전에 많은 도움이 되었던 사이트와 다양한 기업들의 시행착오들을 살펴보았다. 그러면서 우리에게 맞는 아이콘의 방식을 정하기 위해 아이콘들의 특성을 나타낼 수 있는 큰 [카테고리]가 prefix, suffix 에 들어가게 되었다.

[표기법]
주로 파스칼 표기법을 따랐다. 개발상에서 한눈에 직관적으로 파악할 수 있도록 함이다. 그 중에서 direction-property와 color는 direction과 property가 둘 중 하나, 혹은 둘다 사용되는 경우가 있고, color도 gradient로 작업되어 색상이 2가지가되는 경우가 있어, 한 카테고리 내에서 특성의 분류를 위해 케밥 표기를 부분적으로 차용했다.

[Prefiix]
Prefix에서는 Icon, Image, Logo, gif 로 크게 4가지로 나누었다. 기능별로 코드작업이나 특성들이 달라지는 것을 위주로 크게 분류를 했다. Icon 의 경우, 프론트에서 .svg로 작업하며 디자이너들의 작업에도 일정한 크기, 패딩값이 존재하지만, Image는 .png의 확장자로 작업하고 패딩값이 존재하지 않는다.
prefix는 분류만 크게 되면 되기 때문에 쉽게 알아볼 수 있고 코드의 길이를 줄일 수 있는 줄임말을 사용했다.

[Suffix]
suffix 에서는 주로 사용되는 상태값과 표현할 수 있는 특성들을 차례로 나열하였다.

03. 결과적으로 소통하기가 편리해졌다!

결과적으로 개발자와 디자이너 모두 아이콘을 보고 한 줄로 표현할 수 있게 되었고, 한 줄을 보고도 어떤 아이콘인지 바로 파악이 가능하게되었다. 이를 통해, 슬랙으로 워딩만 입력했을 때, 혹은 말로 전달했을 때, 바로 소통이 가능해졌다.

그 전에는 요청이 오게되면 “ ㅇㅇ님, 요기 요 아이콘이요.” 하면서 화면을 보면서 얘기하거나 캡쳐하거나 했을텐데 개발자에게 문서 작성하기도 훨씬 수월해지고 소통하기도 편리해졌다.

Insight_네이밍 작업을 마치며..

01. 난관 _ 마크업 개발자의 필요성을 깨달음.

(이 부분은 추후 난관이나 우여곡절에 대해서 글을 써볼 계획이다.)

네이밍을 진행하면서 서로 이해도의 차이가 있었다. 개발자와 디자이너 서로 생각하는 게 달랐던 것이다.

→ 마크업 개발자가 따로 아이콘을 코드화 작업을 해서 프론트 개발자가 코드로 빠르게 적용가능하도록 만들어야하는 과정이 시스템을 만들 때 필요하다는 것을 알게 되었다.

02. 개발자의 언어에 따라 type, 네이밍 방식이 변화된다.

개발자의 언어방식에 따라서 $나 / ,등 써야 하는 방식이 달라졌다. 또한, class 를 지정할 지, 타입별로 지정할 지가 달라진다.

그렇기에 네이밍을 정할 때 협업하는 개발자들과 엄청난 소통을 함께 하면서 디자이너들의 방식과 개발자들이 사용하는 방식을 맞춰나가야 한다.

또 네이밍에는 순서가 있는데, 개발자들이 업무에 적용할 때 순서는 중요하지 않다. 그러나, 소통을 할 때 이는 역량을 발휘한다. 순서는 개발자와 디자이너가 아이콘의 상태를 말할 때 일종의 약속처럼 역할을 하게 되기 때문에 중요하다고 할 수 있다. 또한, 디자이너들에게 파일관리와 asset 관리를 위해서는 네이밍 순서는 중요하다.

03. 아이콘 네이밍 영역에는 추후에 디자이너 영역과 개발자 영역의 구분 필요

(Progress 3 에 참조)

현재 방식은 디자이너의 asset 관리와 개발자가 바로 파일에 넣을 수 있는 방식으로 진행을 했는데, 이 방식의 장단점과 낱개 파일의 장단점이 있기에 각자 실무자들이 업무를 효율적으로 활용할 수 있는 방식을 고민하여 네이밍을 정해야겠다는 생각이 들었다.

04. 파일로 정리 vs 한 파일에 낱개로 정리

현재 필자(UX/UI디자이너)의 방식은 파일로 정리를 하는 방법을 택했다. 그러자 프론트 개발자분들의 방식에서 둘다 상관은 없으나 각각 장단점이 있는 듯 해 보였다.

앞으로 해야할 것.

우리팀의 디자인 가이드가 필요한 카테고리들이 많기 때문에 한 카테고리를 깊이있게 하는 것은 잠시 미뤄두고, 한 카테고리들의 큰 틀부터 정립해나가자고 결론을 내리게 되었다.

1. 앞으로 해야될 것은 많지만, 이 다음으로는 Color Guide 를 완성해 나갈 계획이다.
2. 지금 현재로서는 svg 파일을 코드에서 color값을 바로 바꿀 수 없어서 컬러별로 디자이너가 아이콘을 만들고 개발자가 다운 받아서 사용하는 형태였다. 이의 단점은, 파일용량이 커지면서 웹이 느려지게 되기 때문에 이를 해결하기 위해 svg 를 코드화하여 용량을 줄이는 방식을 다음 아젠다로 가져갈 예정이다.

[SOCAR FRAME 만들기 #3] 컴포넌트, 제대로 만들어 쉽게 쓰자! (1탄)

Design Tokens

디자인 시스템 만들기-디자인 토큰(1)

Comprehensive Guide: When to Use Em vs. Rem

아이콘에 제대로 된 이름 붙여주기