Figma는 디자인 파일 그 이상입니다.

이 글은 제 경험 기반으로 작성되었으며, 정답이 아닙니다.막 졸업해서 스타트업에서 처음 PM/PO, 디자이너를 맡으신 분들에게 도움이 되는 내용입니다.

여러 회사를 다니면서 지켜 본 결과 생각보다 Figma를 잘 관리하지 못하는 경우들이 있더라구요. 이번 글에서는 Figma를 관리해야 하는 이유와 방법에 대해 설명하고자 합니다.

Figma를 관리해야 하는 이유

과거 Figma가 없었을 때 (PPT로 wireframe을 그리고, Photoshop으로 디자인 하던 시절..)에는 기획할 때 storyboard 라는 개념이 기획의 시작이었습니다. 제품을 구현하기 위해서는 기획자들이 PPT로 된 기획안이라는 것을 작성했어야 했고, 기획안이라는 문서 안에는 IA, 서비스 흐름도, 화면 상세 등이 담겨있어야 했었습니다. 그리고 그 문서를 storyboard라고 불렀습니다. storyboard가 완성되면 디자이너와 개발자들이 실제 작업에 들어갔습니다. 정말 예전 일이네요... 그래서 storyboard를 잘 만드는 사람이 기획을 잘 하는 사람으로 인식되었습니다.

Storyboard : 개발 및 디자인을 하기 위한 가장 기초적이면서 필수적인 문서들의 총합, 일반적으로 표지, 개정이력, IA, 서비스 흐름도, 화면 상세 등이 포함되어 있는 문서

그 후 앱 서비스가 활성화되고, 빠르게 시장을 내보내는 것이 기업 생존의 핵심 전략이 되면서 Sketch를 많이 사용하게 되었고, Figma가 등장한 이후 거의 모든 회사가 Figma를 통해 화면 디자인을 하게 되었습니다. 특히 전통적인 기능조직 구조에서 사일로, 챕터 등의 목적조직 구조가 도입되면서 자연스레 storyboard의 중요성도 낮아지기 시작했습니다. 시간이 없기 때문이죠. 그러다보니 Figma 관리가 무척이나 중요해졌습니다.

물론 Figma를 잘 관리한다고 해서 기획을 잘 하는 것은 보장되어 있진 않지만 최소한 개발자, 기획자, 디자이너 사이의 커뮤니케이션 비용를 줄여 효율적으로 일할 수 있습니다. 예를 들어봅시다. IR 자료를 만든다고 해봅시다. 우리 최신 화면을 찾아서 넣어야 한다고 할 때 Figma 디자인이 최신이 아니라면 어떻게 될까요? PO가 새로 입사했다고 해봅시다. 해당 페이지의 정책을 확인하고자 할 때 어디를 봐야할까요? 빠른 릴리즈, 문서의 최소화로 인해 Figma는 하나의 디자인 시안 그 이상으로 생각해야 합니다. 다시 말해, Figma는 이제 디자인 시안이 아닌 기획안(구, Storyboard)으로 생각하고 만들 때부터 잘 만들어야 하고, 항상 최신의 상태를 유지해야 하며, 소통의 도구로 생각해야 합니다.

Figma를 효율적으로 사용하는 방법

1. 디자인 파일은 각 화면 단위 분리하여 구성하고 반드시 thumbnail을 설정합니다. thumbnail에는 진행상태를 반드시 추가합니다.

앱 혹은 웹 서비스의 기능이 늘어날수록 새로운 페이지도 많이 늘어납니다. 파일명에 직관적으로 작성해 두어도 파일명만으로는 어떤 디자인 파일인지 알기 어렵습니다. 그렇기 때문에 파일명 외에도 thumbnail을 설정해놓는 것이 좋습니다. 추가적으로 현재 진행하고 있는 상태인지, 완료된 것인지도 추가해놓으면 관리에 더욱 좋습니다.

몇몇 회사에서는 하나의 화면을 프로젝트 별로 하고 하나의 디자인 파일을 버전으로 관리하는 경우도 있는데 개인적으로는 관리 포인트가 늘어나 비추합니다.

2. 각 화면 단위로 하나의 디자인 파일을 만들었다면, 페이지는 Cover, IA, Wireframe, User Scenario, Change logs, ... 순으로 생성하여 Storyboard 형식으로 만들어 관리합니다.

여타 회사의 경험을 비추어보았을 때 페이지 구성을 잘하냐 못하냐에 따라 커뮤니케이션 비용이 엄청 차이납니다. 개인적으로 가장 효율적으로 일할 수 있었던 구성이 Cover, IA, Wireframe/Idea, Design, User Scenario, Change Logs, Component/Source 구성이었습니다. 보통 Wireframe/Idea 페이지에서 초안들을 디자이너 분들과 같이 이야기 나누며 만들고 최종 파일을 Design 페이지에 반영하는 방식으로 일했는데 굉장히 빠르게 진행할 수 있었습니다. Design 페이지의 경우 {기능명_버전} 혹은 {추가된 화면명_버전}으로 페이지 이름을 설정해서 관리했는데 버전 히스토리를 보기에 매우 편리했습니다. Change Logs 같은 경우 Figma 내에 version 관리가 가능해서 이 기능으로 대체해도 무방할 것 같습니다.

3. 화면 상세 설명은 디자인 화면 바로 옆에 작성하고, 정책, 개발, 디자인, 효과 등에 대해 바로 구분이 갈 수 있도록 표시해줍니다.

Figma Design 파일의 경우 모든 사람들이 본다는 가정 하에 작성되어야 합니다. CEO가 IR 자료를 만들기 위해 볼 수도 있으며, 개발자가 개발을 위해 볼 수도 있으며, QA가 검증을 위해서 볼 수 있습니다. 이렇게 많은 독자가 있기 때문에 최대한 디자인 화면 바로 옆에 화면 설명을 작성하고 해당 내용이 개발 정책에 가까운 것인지, 사용자에게 전달될 효과인 것인지 등을 구분해 작성해야 합니다. 저는 개인적으로 각 카테고리를 나누고 아이콘 형식으로 표시하는 것이 제일 좋았습니다.

화면 상세 설명의 경우 기본적으로 어미를 줄인 형태(ex. 없음, 불가능, 가능 등)가 아닌 최대한 경어체로 작성하는 것이 좋습니다.