이전 글
글을 읽기 앞서
이 글은 피그마 자체의 활용보다는 핸드오프 방식과 프로토타입 툴을 통한 커뮤니케이션에 초점을 맞췄습니다. 또 저는 현재 목적조직의 프로덕트 디자이너로 일하고 있고 빠른 업데이트 주기를 가지고 일하고 있어 이런 환경을 기준으로 작성했습니다.
디자이너가 속해있는 조직의 상황, 프로젝트의 볼륨이나 특징에 따라 툴을 활용하는 방식이 다를 수 있으니, 이 점을 감안하고 읽어주세요.
핸드오프는 최대한 가볍게
화면의 변화에 따라 가이드도 최신화가 필요합니다.
피그마를 포함한 모든 문서와 파일은 최신화가 중요한데요. 일주일에도 몇 번씩 바뀌는 빠른 이터레이션을 가진 제품이라면, 최신화를 위해 디자인 핸드오프를 간결하게 구성하는 것이 좋습니다. 화면이 바뀔 때마다 제품 요구 사항은 당연히 변할 수 밖에 없으므로, 피그마 화면에는 제품 동작 방식이나 정책을 거의 써놓지 않는 편입니다. (애초에 피그마는 ‘문서’에 특화된 툴이 아니기도 하고요.) 이렇게되면 디자이너는 오직 화면의 변경 사항만 건드리기 때문에 시안의 수정이 빠르게 이뤄질 수 있고, 후에 화면과 주석의 갭으로 인한 커뮤니케이션 미스도 줄일 수 있습니다.
그럼 개발자와는 어떻게 소통할까요? 먼저 피그마에서 시안 작업 후, 화면을 캡쳐해 노션으로 PRD를 작성합니다. 이번 스펙에는 A라는 모양의 화면이었지만 다음 스펙에는 B라는 모양의 화면이 될 수도 있으니 링크를 임베드하지 않고 캡쳐해 히스토리를 남기는 방법입니다. 또 노션은 블럭마다 코멘트를 남길 수도 있고 디자이너가 아닌 사람도 편집이 가능하니 누구나 제품 요구 사항을 수정할 수 있습니다. 개발자는 PRD를 통해 해당 스펙을 전체적으로 이해하고, 피그마를 참고해 UI를 개발하는 식입니다.
작업 공간 분리하기
보통은 디자인 시스템까지는 아니더라도 마스터 컴포넌트를 관리하는 컴포넌트 파일 따로, 해당 컴포넌트의 인스턴스를 가지고 작업하는 프로덕트 파일을 따로 관리하실텐데요. 저는 조금 더 자유롭고 다양한 시도를 하기 위해 실험실 파일을 하나 더 두는 편입니다. 실험실은 말그대로 실패도 해보고 컴포넌트도 다 깨보고 레이어 정리도 안하는, 의사결정만을 위한 곳이기 때문에 충분히 더럽게(?) 사용합니다.
충분한 의사결정이 되었다면 채택된 시안들을 프로덕트 파일로 옮깁니다. 여기서 새롭게 생기거나 기존 컴포넌트의 수정이 필요하다면 디자인 시스템팀과 논의해 디자인 시스템에 반영하거나, 프로덕트 파일에서 로컬 컴포넌트를 만듭니다. 프로덕트 파일에서는 속도가 중요한 게 아닌 명확한 핸드오프가 중요하기 때문에 여러가지 UI 상황을 고려해 컴포넌트를 구성합니다.이렇게 작업 공간을 분리하면 디자이너의 심리적 부담감도 줄어들고, 최종 시안에 대한 혼란도 줄어들 수 있습니다.
페이지 구성
1. 실험실 파일
그럼 파일 안에서 페이지 구성은 어떻게 하면 좋을까요?
가장 먼저 커버를 구성합니다. 피그마는 아트보드 템플릿으로 1920*960 사이즈의 Plugin / file cover 커버를 제공합니다. 커버에는 프로젝트 또는 제품의 제목, 담당 디자이너, 프로젝트 스테이터스, 관련 링크 등을 삽입할 수 있습니다. 커버 구성 후, 아트보드 우클릭 → Set as thumbnail을 설정해 파일 바깥에서도 아름답게 볼 수 있도록 설정해둡시다. 여러 파일 중에 내가 원하는 파일을 썸네일만 보고도 파악할 수 있습니다.
실험실의 페이지에는 큰 단위의 프로젝트 명을 적습니다. 각 페이지 안에는 프로젝트 내에 고려해야할 것들을 종류별로(또는 리뷰의 회차별로) 나눠 라벨을 달아 놉니다. 저는 라벨의 구분을 행으로 하는데요. autoflow같은 플러그인으로 플로우를 구성할 때 보통 가로 방향으로 개진하기 때문에 구획을 나눌 때는 세로 방향의 구분을 짓는 편입니다. 따라서 라벨 A와 관련된 내용을 전달할 때 라벨 A 자체의 프레임 링크를 공유한다면, 어느 구획을 봐야할 지 분명해지는 것이죠. (프레임들을 큰 프레임으로 감싸 공유하는 방법도 있지만, 이럴 경우 내부 화면들의 아트보드명을 보기 어려워지므로 이 방법은 지양합니다.)
작업하는 동안 디자이너는 여러가지 고민, 시안에 덧붙여야할 설명(여기서 말하는 설명은 PRD와는 다릅니다.), 이해관계자에게 받는 다양한 피드백이 생기기 마련인데요. 이런 내용들을 시안 옆에 구분해 붙여 놓으면 이후에 맥락을 이해하는데 큰 도움이 됩니다. 당장 몇 주만 지나도 “우리가 왜 이런 선택을 했더라?” 하는 질문들이 생기기 마련이니까요. (내용이 길어질 경우 노션으로 리뷰 문서를 따로 정리하고 링크를 달기도 합니다.)
실험실에서 몇 번의 리뷰를 거쳐 프로덕트 파일에 옮겨질 최종 안이 나옵니다. 이럴 경우 프로덕트 버전에 옮겨질 버전은 따로 표시해놓습니다. 다양한 실험이 있었고 → 그의 맥락은 이랬고 → 그래서 뭘로 결정했다까지 이어져야 맥락의 완성이니까요. 또 최종안이 정해진다면 작업했던 컴포넌트들은 히스토리 보존을 위해 디태치해주는 것이 좋습니다. (아트보드를 선택한 후 Detach all nested instances 메뉴를 이용하면 간편합니다.)
2. 프로덕트 파일
실험을 마친 우리는 프로덕트 파일로 넘어 왔습니다. 이 파일에서도 실험실과 마찬가지로 파일의 내용을 구분할 수 있는 커버를 구성합니다.
커버 아래 두 번째 페이지에는 로컬 컴포넌트를 구성합니다. 이 로컬 컴포넌트는 같은 파일에만 쓰이고, 디자인 시스템에서는 다루지 않을 요소들을 모았습니다. 컴포넌트가 아니더라도 개발에 필요한 에셋도 이 페이지에 구성합니다. 개발자는 UI 개발에 필요한 반복적이고 추출이 필요한 요소들을 이 페이지에서 확인할 수 있습니다.
만약 A/B 테스트가 진행될 경우 모든 화면을 n벌씩 만들 수 없기 때문에 페이지를 따로 만들어 테스트 중인 화면만 구분해 놓습니다. 테스트가 끝나고 위너인 화면이 정해진다면 그 때 파일에 있는 해당 화면 모두를 위너 버전으로 적용합니다.
그 밑으로는 제품의 페이지(로그인/가입, 홈, 상세 페이지, 마이 페이지 등의 구분)를 나누어 화면을 배치합니다. 히스토리 흐름이 중요한 프로젝트라면 스프린트 단위(스프린트 1, 스프린트 2, …)로 페이지를 구성해 제품의 개선 여정을 쉽게 나눠볼 수 있는데요. 이럴 경우 페이지의 확장성이 떨어지며 피그마 용량의 한계가 있기 때문에 파편화가 따라올 수 있고, 이전 화면들을 보존하기 위해 디태치해야하는 번거로움도 따라올 수 있습니다. 각자의 프로젝트 상황에 맞는 페이지 구성 방식을 선택하시는 것이 좋습니다.
다크테마, OS, 해상도
빠른 작업을 원한다면 관리할 화면은 최대한 줄이는 것이 좋습니다. 다크테마, OS에 따른 컴포넌트 차이, 가변 영역 등 모두 시스템에서 정의가 잘 되어 있다면 n벌 이상씩 만들지 않아도 되는 화면입니다. 만들더라도 모든 화면에 대해 대응을 하기 보단 특별한 정의가 필요한 화면에만 대응을 한다면 여러 화면을 관리하지 않아도 됩니다.
케이스 고려하기
UI 화면은 정지된 화면이 아니라 유저의 행동에 따라, 또 내려 받는 데이터에 따라, 다양한 상황에 따라 역동적으로 변화하는 화면입니다. 따라서 디자인 단계에서도 이에 대한 대응이 필요한데요.
우선 유저 플로우는 해피패스 위주로 보여주되, 이외 엣지케이스도 챙깁니다. 이 때 유저 시나리오는 아트보드 이름으로 지정하는데요. 위에서 언급한 것처럼 주석을 따로 달면 관리할 코스트가 늘어나니, 아트보드 이름에 여러 시나리오 별로 직접 지정하는 것이 좋습니다.
특히 오버레이 형 컴포넌트(다이얼로그, 바텀시트, 스낵바 등)를 사용하는 화면이라면 아래 화면까지 그려주기보다는, 오버레이 위쪽 레이어만 가이드를 그리고 아트보드 설명으로 맥락만 연결시킬 때 관리 코스트를 훨씬 줄일 수 있습니다.
또 전체적인 플로우뿐만 아니라 같은 화면 내에서도 다양한 케이스들이 존재하는데요. 이럴 경우 해당 컴포넌트(또는 UI 부분)만 똑 떼내어 여러가지 케이스별 배리에이션을 정의합니다. 이런 UI 내 작은 배리에이션은 PRD에 적기 애매한 부분이 있으므로, 하나의 아트보드로 묶어 주석까지 작성해 놓습니다.
모두를 위한 피그마 가이드
자, 여기까지 디자이너 개인이 활용하기에 제법 좋은 핸드오프 환경을 구성해놓았습니다. 하지만 함께 일하는 이해관계자는 여전히 혼란스럽습니다. 왜 비슷한 파일이 두 개 있는건지, 현재 디자이너의 작업 상태는 어떤지, 그래서 나는 어떤 화면을 보고 개발을 해야하는지 헷갈립니다.
오박사… 다들 아시죠?
보다 원만한 협업을 위해 디자이너가 구성해 놓은 환경을 이해관계자에게 설명하도록 합시다. 저는 피그마 가이드를 노션으로 적어 놓았고, 이 링크를 커버에 READ ME로 두었습니다. (물론 설명이 필요 없는 직관적인 환경이 제일이지만요
) 몇 번 연습을 거치면 개발자든 PM이든 디자이너만큼 핸드오프에 대한 이해도가 높아지며 커뮤니케이션 코스트가 줄어듭니다.
) 몇 번 연습을 거치면 개발자든 PM이든 디자이너만큼 핸드오프에 대한 이해도가 높아지며 커뮤니케이션 코스트가 줄어듭니다.글을 마치며
느끼셨겠지만 여전히 피그마로 일하는 것은 꽤나 똑똑하지 못한 노가다성 작업이 많습니다. 그럼에도 불구하고 메이커의 작업 시간을 조금이라도 줄이고, 그 시간에 조금 더 많은 가치를 생산했으면 하는 바람으로 글을 적었습니다.
또 고백하자면 저도 귀찮아서 위에 기재한 방식들을 따르지 않을 때가 많은데요. (우리 팀 미안합니다…) 가장 중요한 건 메이커들간의 약속이 잘 작동해 커뮤니케이션 코스트를 줄이려는 노력과 시도인 것 같습니다. 여러분만의 노하우가 있다면 알려주세요. 계속해서 좋은 핸드오프 시스템을 위해 고민해보겠습니다.
참고한 자료
