아이콘 에셋 사용성 개선기
아이콘을 사용하는 방법에 대해 고민해 보기
아이콘은 디자인 시스템의 근간(foundation)을 이루는 요소입니다.
브랜드의 정체성을 표현하는 시각물이기 때문이기도 하지만, 무엇보다 컴포넌트의 가장 최소단위로 쓰이는 기초적인 디자인시스템 요소이기 때문이에요.
많은 글들에서 아이콘에 브랜드 이미지를 투영하여 일관적인 서비스경험을 전달하는 법 또는 조형적으로 아름답게 디자인하는 법을 공유하는데요. 그렇다면 시스템 관점에서는 무엇을 고려해야 할까요?
이번 글에서는 디자이너, 개발자가 효율적으로 아이콘을 사용하기 위한 아이콘 시스템 개선 경험을 공유하고자 해요.
이 글의 내용
- 효과적인 아이콘 네이밍 컨벤션을 통한 아이콘 사용성 개선
- 포그라운드 스타일 적용을 통한 이미지 아이콘 사용성 확장
- Figma ↔ Github 연동을 통한 아이콘 에셋 동기화
문제발견: 업무 비효율을 불러오는 아이콘 사용법
기존에 이미 아이콘 가이드가 존재했음에도 불구하고, 문제가 지속적으로 누적되어 메이커들이 불편함을 겪고 있었는데요.
문제 1. 아이콘을 적용할 때마다 시간을 낭비한다.
기존 아이콘 네이밍 컨벤션 중 필요 없는 규칙이 있어서, 디자이너와 개발자는 때때로 자신의 업무환경에 적합한 네이밍으로 아이콘을 사용하고 있었던 게 원인이었어요.
서로 아이콘을 부르는 이름이 각기 달랐기 때문에 개발자가 UI를 구현할 때마다 피그마와 동일한 모양의 아이콘을 패키지에서 직접 찾는데 시간이 소요되었어요.
문제 2. 아이콘 에셋 유지 및 관리 비용이 많이 발생한다.
저희가 서비스하는 앱은 네이티브로 개발되었어요. iOS는 아이콘을 이미지 형식으로 적용할 수 있는데요. 그렇기 때문에 아이콘 형태는 하나이더라도 색깔별로 파일을 생성해야 하는 번거로움이 있었어요.
앱 내에서 아이콘에 적용할 수 있는 색깔은 12가지였고, 아이콘 형태의 수는 70개 이상이었기 때문에 약 850개의 아이콘 파일을 생성해야 했어요. 또, 아이콘 그래픽을 편집한다면 11개의 파일도 마저 수정하고 업데이트해야 했어요. 이런 방식은 디자이너 1명(바로 나)이 감당하기 어려운 구조였어요.
목표: 아이콘 사용성을 개선해 업무효율을 높이자
여러 개의 타사 디자인 시스템을 참고하며 이 문제를 어떻게 해결할 수 있을지 개발자분들과 함께 상의하고,
아래와 같이 문제에 따른 목표를 선정했어요.
1단계: 아이콘 네이밍 컨벤션 다시 계획하기
기존 네이밍 컨벤션의 사용 경험을 토대로 새로운 네이밍컨벤션을 구성했는데요,
첫 번째, 개발자분들과 함께 사용 중인/사용하지 않는 규칙을 분류했어요. 그 결과, 아래 이미지처럼 공통적으로 사용하지 않는 규칙을 소거할 수 있었어요.
두 번째, 한쪽 파트에서 사용하지 않는 규칙을 개선했어요. 디자인 파트에서는 [assetType]과 [color]를 사용하지 않았는데요.
아이콘 핸드오프 방식과 새로운 기술을 도입함으로써 소거할 수 있었어요. assetType의 경우, 아이콘을 추출할 때 ‘icon/gas’ → ‘ic_gas’로 변환될 수 있도록 스타일딕셔너리 포맷을 설정했고, color의 경우, 이미지의 색상을 변환할 수 있는 foregroundStyle을 활용해 소거했어요. 이 두 가지는 글의 후반부에서 자세히 기술할게요!
마지막으로, 공통 규칙을 개선했어요. 똑같은 형태지만, 아이콘 이름이 달라 개발자분들이 헤매는 문제가 있었는데요. (ex: category_fuel과 gasstation) 에셋명 작성규칙이 존재하지 않았기 때문에 생겨난 일이라고 판단했어요. 따라서 에셋명 작성 규칙을 정의했습니다. iOS 개발자님의 제안으로 애플의 SF Symbols를 참고해 아이콘의 목적이 아닌 형태를 중심으로 작명하여, 범용성을 높였어요.
규칙을 정리하고 난 후, SwiftUI와 Compose의 코딩 컨벤션을 수렴하여 반영했어요. 그리고 사내의 모든 디자이너가 규칙을 이해할 수 있도록 가이드를 작성해 전파했어요.
2단계: foregroundStyle로 아이콘 관리포인트 줄이기
다음으로는 아이콘을 이미지로만 관리해야 하기 때문에 색상별로 파일을 생성하는 문제가 있었는데요.
(제 짧은 개발지식으로) 웹에서는 css filter로 이미지에 필터를 씌워 여러 색상으로 변경할 수 있음을 알고 있었습니다. 컴포즈와 스위프트 UI에서도 필터와 유사한 기능이 있는지 개발자 분들과 소통하였고, 네이티브에서도 문자열을 활용해 이미지의 전경색을 바꿀 수 있음을 확인했어요.
3단계: Figma 아이콘 에셋을 개발 패키지와 완전 동기화하기
마지막으로 아이콘을 생성/수정할 때마다 발생하는 커뮤니케이션을 줄이기 위해 Figma와 Github을 연동하기로 했어요. 디자이너는 figma 커스텀 플러그인을 사용해 아이콘 파일을 디자인파트의 github repository로 전송해요. 그다음 디자인 레포에서 iOS와 안드로이드가 아이콘 에셋을 관리하는 패키지에 각각 전송하여 최종적으로 개발자에게 전달되는 방식으로 구성했어요.
아이콘 파일이 단방향으로 전달되기 때문에 디자이너만 레포지토리를 관리하면 되고, 에셋 패키지의 업데이트가 자동화되므로 개발자가 하나하나 아이콘명을 수정하거나 파일을 삭제할 필요가 없어요.
또한, 스타일딕셔너리에 포맷을 설정하여 각 플랫폼 코딩 컨벤션에 맞게 아이콘명을 변환했어요. 예를 들어서 아이콘을 카멜표기(checkCircle)로 github에 업로드했을 때, 안드로이드 패키지에는 (ic_check_circle)로 저장되게끔 지정했어요.
추가 개선 : Figma에서 foregroundStyle 구현하기
아이콘 사용성을 개선한 후, 직접 시스템을 사용해 보면서 추가 문제점을 발견했는데요. 피그마에서 아이콘 모양을 변경했을 때 내가 적용했던 아이콘 컬러가 유지되지 않는 번거로움이 있었어요.
아이콘을 바꿀 때마다 색상을 다시 지정하는 것 또한 반복적이고 비효율적인 업무였어요. 디자이너는 아이콘을 바꾸려면 아래의 업무 프로세스를 거쳐야 했어요.
아이콘 프레임에 모양과 색상정보가 함께 묶여있기 때문에 발생하는 일이었는데요. 따라서 모양정보와 전경색정보를 구분할 수 있는 방법을 찾아야 했어요. 여러 피그마 오픈소스를 탐색하여 wanted design system과 blade design system에서 레이어를 활용해 모양정보와 색상정보를 독립해서 사용하는 방식을 발견했어요.
아이콘 프레임을 한 번 더 감싸는 상위 레이어를 만들어서, 해당 레이어의 색상을 조정했어요. 이를 통해 아이콘 프레임은 모양 정보만 제공하고, 상위 레이어에서 색상을 결정하기 때문에 아이콘 프레임의 모양을 바꿔도 색상이 그대로 유지되었어요. 덕분에 디자인 작업이 단축되었어요.
결과: 아이콘 사용 시 업무효율 10배 증가!
개선 3달 후 시스템을 사용하는 같은 팀 개발자분들과 피드백하는 시간을 가졌어요. 프로젝트 전/후를 비교했을 때, 디자이너와 개발자 모두 업무효율이 크게 개선되었다는 평가였어요.
디자이너
- foregroundStyle로 아이콘 관리가 매우 간결해졌습니다. 더 이상 색상별로 파일을 생성하지 않아도 되기 때문에, 파일 작업이 대략 8개에서 1개로 줄어들었습니다.
- 아이콘이 정리되어 모양 수정 시 라이브러리에 존재하는 모든 동일형태의 아이콘을 찾아서 수정할 필요가 없습니다.
- 기존에는 직접 라이브러리에 들어가 아이콘을 찾아야 했지만, 아이콘 에셋규칙이 통일되어 이제 검색만으로도 쉽게 찾을 수 있습니다.
- 컴포넌트 디자인 시 아이콘 사이즈, 색상을 일일이 수정하지 않아도 되어 편리해졌습니다.
개발자
-아이콘 업로드 자동화 및 토큰 자동화로 개발자가 수동으로 입력해야 하는 부분이 매우 단순해지고 추적이 가능해졌습니다. 최초 아이콘을 설정하는 시간이 약 10분(네이밍 입력이 많은 경우)에서 1분 정도로 감소했습니다.
-아이콘이 정리되어 다양한 크기, 색을 적용할 수 있어 아이콘을 사용하는 데 있어서 불편함이 없습니다. 거의 모든 사례를 커버할 수 있습니다.
-디자인 화면 UI 관리 코드 품질이 매우 향상되었습니다. 기존에 없던 시스템의 추가로 개발의 편의성이 증가하였습니다.
사용자 경험을 ‘시각’으로만 제한하지 않는다
이 프로젝트를 통해 프로덕트 디자이너가 마냥 단순한 직업이 아니라는 걸 다시금 실감하는 계기가 되었어요. 기존 아이콘 사용 시 발생하는 병목을 해결하기 위해 아이콘명, 아이콘의 피그마/개발 컴포넌트 구조, 파일 전달 방식등 다방면에서 사용성을 향상시켰는데요.
만약 1차원적으로 ‘프로덕트 디자이너는 사용자 경험을 개선하기 위해 UI를 구성하는 직업’이라고 생각했다면, 지금과 같은 아이콘 시스템은 절대 탄생할 수 없었을지도 몰라요. 프로덕트 디자이너는 사용자 경험을 ‘시각’으로 국한하지 않는 직무라는 걸 명심해야겠어요.
읽어주셔서 감사합니다!