1. 프로덕트 디자인 부채 해결하기
배경
나는 모빌리티 업계(회사 명: 카티니 서비스 명: 타이어픽) 1인 프로덕트 디자이너며, 운영 배포하는 디바이스 (APP, MW, PC)와 서비스(B2C, B2B)가 여러 가지고, 2022년 10월 서비스 리뉴얼 및 앱 론칭 이후 여러 디자이너와 개발자의 손을 거치며 피그마 디자인과 운영 중인 화면 사이 부채가 많이 쌓여있는 상황이었다. 따라서 7개월 전 합류한 이래로 '피그마 화면과 운영 화면 싱크 맞추기'를 올해의 목표로 삼았으며, 배포 퀄리티 향상을 위해 피그마로 일관된 <디자인 배포 시스템>을 만들기로 했다.
요약
특징이 아래와 같다면 이 글이 도움이 될 것 같다!
1. 프로덕트 디자이너는 나 혼자다.
2. 디자인 부채가 많다.
3. 관리하고 배포하는 서비스가 하나 이상이다.
4. 피그마 Organization Plan을 사용하고 있지 않다.
*피그마에서 Organization Plan을 구독 중이라면 브랜치 기능을 이용할 수 있는데, 설명하고자 하는 방법이 해당 기능을 따라 하고 있기 때문에 피그마가 잘 만들어놓은 branch 기능을 활용하면 된다.
문제정의
피그마가 운영 화면에 맞춰 현행화 되지 않았을 때 가장 큰 문제는 히스토리 파악이 어렵다는 것이고 디자이너가 히스토리 파악이 되지 않으면 불필요한 작업을 두 번 세 번 하게 된다는 것이었다. 맡은 서비스의 경우, 운영&개선 피그마가 크게 3가지 버전으로 흩뿌려져 있었고, 실제로 업무를 파악하고 작업을 진행할 때 3가지 버전과 운영중인 웹,앱을 모두 확인해 싱크를 맞춰 업무를 진행해야 했다. 굉장히 비효율적인 방식이었고, 개선의 필요성을 절실히 느꼈다.
해결방안
Step 1. 디자인 시스템 정리로 기초 잘 다지기
디자인 시스템 정리하는 법은 글을 따로 파야할 정도로 방대한 이야기지만, 부채 해결을 위해 큰 골자를 이야기해야 하니 간단하게 설명하자면, 타이어픽의 디자인 시스템은 크게 Foundations, Icon& Illust, Comomponets로 분리되어 있고, 해당 체계를 기반으로 정리하며 고도화하고 있다.
컴포넌트 종류 이미지로 보기- Foundations : 폰트, 컬러, 레이아웃 가이드 등 아주 Atomic 한 단위
- Icon & Illust : 공통으로 활용되고 있는 모든 아이콘과 일러스트
- Components : Web / APP&MW / Root&Crew 컴포넌트
* Root - 타이어픽 관리 어드민. Crew - 장착점 사장님들 B2B
아이콘 합치고 합치고 합치기...디자인 시스템에 속한 아이템들은 서비스의 교집합이라고 생각한다. 서비스마다 중복적으로 사용하는 것을 어떻게 추려서 정리하느냐가 핵심인데, 가장 최근 진행한 컴포넌트 고도화는 아이콘이다. AS-IS의 경우, B2C와 B2B 서비스 별로 아이콘이 나뉘어 있었다. 다만 장착점 사장님들이 사용하는 Crew가 2024년부터 모바일 앱으로 구현될 예정이기 때문에 그 전에 B2C Web 개발자, B2C 앱 개발자, Root&Crew 개발자가 통합적으로 쓸 수 있는 아이콘 세트를 만들어 서비스를 통일시킬 필요가 있었다.
아무튼 현 상황은 이렇다. 계속 서비스를 운영하면서 합칠 건 합치고, 뺄 건 빼는 등 끊임없이 발전시켜야 한다. 아직 갈 길이 멀다!
Step 2. 마스터 화면 정리하기 ※ 매우 중요
<Master란?> 운영 중인 화면으로 실제 고객이 보는 현행화된 디자인을 Master Screen으로 명명했다. 이 개념은 개발자들이 브랜치에서 사용하는 Master 개념을 동일하게 착안했다.
디자인 부채 많이 쌓여있는 상태면 이 마스터 화면을 정리하는 것부터 고달프다. 그러나 처음부터 다 정리한다고 생각하면 힘드니까 그렇게 하지 말고... 마스터 파일 하나를 제대로 생성하겠다는 목표를 가지고 배포할 때마다 Merge 된 화면들을 하나씩 채워 넣어주듯이 정리해 주면 된다. 사내 어드민인 Root는 방대한 나머지 엄두가 안 나서 정말 배포할 때마다 마스터 파일을 정리했더니 아직 저만큼 밖에 정리하지 못했다. 이것도 갈 길이 멀다...!
추가적으로, 1인 디자이너 구조라면 기능 별로 파일을 다 뜯어내는 것보다 디바이스나 서비스 별로 합쳐서 관리하는 게 용이하다고 생각한다. 너무 세분화시켜도 효율이 떨어지는 느낌... 그리고 마스터 파일을 잘 채워 넣고 관리하기 위해서는 피그마 내에도 배포 시스템을 설계해줘야 한다.
Step 3. 피그마에 배포 시스템 만들기 (브랜치 기능 대체 방법이다)
피그마 브랜치 기능이 표방하고 있는 것은 개발에서 사용하고 있는 Git Flow다. Git Flow에는 Master, Develop, Feature, Hotfixes, Release의 개념이 존재하는데 피그마 브랜치 기능은 Git Flow의 개념을 디자인 친화적으로 고도화했고, 나 역시 같은 개념을 도입해서 쓰기로 했다.
구조는 아래와 같다.
이때, 아이디어 / 진행 중 / 개발 중 메뉴는 Git Flow에서 Feature 단위다. Feature를 기획, 디자인, 개발로 상세하게 쪼개고 피그마 페이지를 해당 카테고리로 올리는 방식으로 반영했다. 예시는 아래와 같다.
피그마 메뉴로 보는 배포 구조이때, 중요한 건 쪼개놓은 메뉴 단위를 활용해서 [아이디어]에 쌓아놨던 TASK의 디자인이 시작되면 [진행중] 메뉴로 옮기고, 디자인이 완료되면 [개발중] 메뉴로 잘 넘기는 것이다. [개발중]으로 올라간 메뉴에서는 개발자들이 보고 개발을 하고, 개발이 완료된 후 개발 배포를 진행하면 페이지를 [디자인QA] 로 메뉴를 넘겨 피그마 안에서도 TASK가 배포 사이클을 탈 수 있도록 하는 것이다.
Step 4. 디자인 QA는 피그마로 진행한다.
맡은 프로덕트 같은 경우, 디자인 부채가 많이 쌓여있었기 때문에 세세한 픽셀 단위의 수정사항도 우선순위를 높여 전부 꼼꼼하게 챙겨야 했다. 이대로 우선순위를 낮추면 더더욱 부채가 늘어가 싱크가 안 맞는 상황이었던 터라 어떻게 하면 UX를 비롯해 UI까지 꼼꼼하게 수정할 수 있는 효율적인 디자인 QA 방식을 만들까? 가 디자인 부채를 해결하는데 매우 중요한 과제 중 하나였다.
노션으로 진행했던 디자인 QA예시기존 디자인 QA는 주로 기능 QA와 함께 진행하면서 위의 예시와 같이 노션이나 엑셀을 이용했다. 그러나 배포 과정에서 상대적으로 디자인 QA 시간이 짧기 때문에 세세한 수정사항들을 2차 3차로 노션이나 엑셀에 기록하는 것은 비효율적이라는 판단이 섰다. 게다가 해당 방식은 피그마 화면을 이용하는 것보다 상세 수정사항들을 설명하는 것에 한계를 느껴 디자인 QA 자체를 개발자들과 피그마에서 댓글 방식을 이용해 진행하기로 했다.
디자이너가 아니면 놓칠 수 있는 아주 사소한 부분들까지 전부 체크하자개발 배포가 완료된 시점 디자인 QA를 진행하고 개발자들은 ✅ 체크 이모지를 사용해 'QA사항이 반영됐음'을 알렸다. 그럼 디자이너가 수정사항을 체크하고 완료된 건은 [댓글 삭제] 2차 수정이 필요한 건은 [새 댓글]을 남겨 진행했다.
디자인 QA중 달린 댓글들이렇게 여러 번의 사이클을 돌고 난 후 느낀 점은, 피그마에서 디자인 QA를 진행할 경우 개발자들과 소통이 더욱 수월하다는 것이다. 노션으로 QA사항들을 기록할 경우 캡처해서 어떤 영역이 수정되어야 하는지 세세하게 PPT식 설명이 필요한데, 피그마의 경우 수정이 필요한 지점에 단어 하나까지 콕 집어 댓글을 남길 수 있기 때문에 디자이너 입장에서는 불필요한 시간도 단축하고, 개발자들에게 설명하기도 용이했다.
결론
서비스를 운영하면서 피그마 상 디자인과 운영 상 디자인 사이 괴리가 생긴다면 앞서 설명한 네 가지 스텝들이 잘 활용되고 있는지 점검해 볼 필요가 있다고 생각한다.
실제 고객이 만나는 화면은 피그마 상 화면이 아니라 운영 중인 웹, 앱 화면이다. 단지 피그마 상에서 화면을 제작하는 것만으로 자신의 역할이 끝난다고 생각해 관리하는 사이클을 만들어 놓지 않으면 쉽게 디자인 부채를 쌓이고 고객은 디자이너의 의도와 다른 제품을 만날 확률이 높다. 뿐만 아니라 놓치고 있다보면 결국 히스토리 관리도 힘들어지니... 그전에 디자인 부채가 잘 쌓이지 않도록 해결하고 완성도 높은 제품을 만들어내자!
