Figma로 정리하는 UXUI 협업 프로세스

이제 UXUI 업무를 하는 분들에게 Figma는 많이 익숙해지기도 했고, 

 

또 그만큼 잘 사용하는 것도 같습니다. 

 

이전 콘텐츠에서는 Figma로 시작하는 UI 디자인 실무라는 주제로 Figma를 잘 사용하기 위한 4가지 주요 개념을 정리해 보았는데, 

 

Figma로 시작하는 UI 디자인 실무

 

이번에는 디자인 관점이 아닌

 

실제 프로젝트를 구성하고, 다른 팀들과 협업하는 관점에서 Figma를 어떻게 활용하면 좋은지를 살펴보겠습니다.

 

 

 

사실 여러 서비스 구축/운영 프로젝트에 참여해보면,

 

그 규모나 상황이 각각 다르기 때문에 협업을 하는 과정이나 산출물의 구성에도 조금씩 차이가 있지만

 

공통적으로 기획/디자인 산출물을 정리하고 관리하는 과정에서 많은 소요(또는 불편함)이 있는 것 같습니다.

 

 

 

그러나 한 발짝 물러서서 Figma가 어떻게 구성되어 있는지를 살펴보면,

 

생각보다 효율적으로 기획/디자인 산출물을 정리할 수 있는 것도 사실입니다.

 

 

 

 

Figma 계층 구조

Figma(그리고 대부분의 UI 디자인 툴)은 

 

Team/Project/File/Page 

 

로 이루어진 계층 구조를 가지고 있습니다.

 

이러한 계층 구조는 실제 업무 환경 및 웹/앱 개발 구조를 반영하고 있다고 할 수 있습니다.

 

그렇기 때문에 기본적으로 이러한 구조에 맞춰 UI 디자인 툴을 활용하는 것이 바람직합니다.

 

 

Step 1. 팀(Team)

Figma > 팀

가장 먼저 팀(Team)은 쉽게 '회사' 또는 '서비스'라고 생각하면 쉽습니다. 팀의 오너가 PO(Product Owner)가 되며, 실제 현업에서 여러 회사가 함께 컨소시엄을 구성해 협업하거나 같은 회사 내에서 TF팀을 구성하여 프로젝트를 진행하는 경우 별개의 팀을 생성하기도 합니다.

 

위 예시 이미지에서 호학당은 'UXUI'라는 팀을 생성하여 여러 프로젝트의 기획/디자인을 진행하고 있습니다. 

 

 

Step 2. 프로젝트(Project)

Figma > 팀 > 프로젝트

 

팀이 세팅되었다면, 팀에서 진행하는 프로젝트가 말 그대로 프로젝트(Project)입니다. 프로젝트의 책임자는 PM(Project Manager)이며, 프로젝트의 규모나 상황에 따라 상이하게 구성됩니다.

 

예를 들어 음식 배달 서비스를 진행한다고 할 경우 '사용자 서비스', '식당 서비스', '배달기사 서비스'처럼 사용자 유형별로 프로젝트를 구성하기도 하고, 백오피스 서비스를 만드는 경우 'PC 웹', '모바일 웹앱'처럼 디바이스별로 프로젝트를 구성하기도 합니다.

 

또한, 일반적으로는 서비스의 주버전이 바뀔 때, 새로운 프로젝트가 생성됩니다. 자체 서비스를 운영중이라고 한다면, '서비스명 v1', '서비스명 v2', '서비스명 v3'처럼 주버전을 기준으로 프로젝트가 관리됩니다.

 

앱 서비스는 일반적으로 Semantic Versioning이라 불리는 세 가지 숫자로 구성된 표기법으로 버전이 관리됩니다(예: v3.1.2).

각 버전의 숫자와 의미는 다음과 같습니다.

1. 주버전(Major): 리브랜딩, 주요 기능 추가/변경 등 기존에서 호환되지 않는 큰 변화가 있을 때 업데이트(예: 1.x.x → 2.0.0)
2. 부버전(Minor): 스타일 업데이트, 일부 기능 추가/확장 등 기존에서 확장된 변화가 있을 때 업데이트(예: 1.2.x → 1.3.0)
3. 패치 (Patch): 기존 요소 업데이트/수정, 작은 성능 개선 등 하위 호환성을 유지하는 변화가 있을 때 업데이트(예: 1.2.3 → 1.2.4)

 

이번 예시에서 호학당의 경우 'UXUI'라는 팀 내에서 호학당 자체 브랜드 웹을 만드는 프로젝트를 진행한다고 가정하고, 'BrandWeb'이라는 프로젝트를 만들었습니다.

 

 

Step 3. 파일(Files)

Figma > 팀 > 프로젝트 > 파일

 

프로젝트 안에서는 여러 파일을 생성하고 관리할 수 있는데, 파일(Files)은 개발 시 정리되는 폴더 또는 파일이라고 생각하면 쉽습니다. 프로젝트 상황이나 규모에 따라 프로젝트가 상이하게 구성된 것처럼 프로젝트 내 파일도 그에 맞춰 구성되게 됩니다.

 

예를 들어, 음식 배달 서비스에서 프로젝트가 ‘사용자 서비스’, ‘식당 서비스’, ‘배달기사 서비스’로 구성되었다면, 파일은 ‘사용자 서비스/공통 라이브러리’, ‘사용자 서비스/웹 디자인 시안’, ‘사용자 서비스/앱 디자인 시안’처럼 구성됩니다.

 

다른 경우 백오피스 서비스에서 프로젝트가 ‘PC 웹’, ‘모바일 웹앱’으로 구성되었다면, 파일은 ‘모바일 웹앱/메인’, ‘모바일 웹앱/메신저’ 처럼 구성되기도 합니다.

 

일반적으로는 서비스의 부버전(Minor)이 바뀔 때, 새로운 파일을 생성(복제)한다고 생각하면 쉽습니다. 자체 서비스에서 ‘서비스명 v1’ 프로젝트 안에는 ‘사용자 앱 v1.1’, ‘관리자 웹 v1.1’처럼 구분하여 부버전을 기준으로 파일이 관리됩니다.

 

Figma 무료 플랜을 사용하는 팀에서는 프로젝트, 파일, 그리고 페이지의 개수에 제한이 있습니다. 무료 플랜에 대한 이런 제한은 다른 UI 디자인 툴에서도 비슷하므로 실제 프로젝트를 진행할 때에는 규모에 맞는 유료 플랜을 사용하는 것을 권장합니다.

 

이번 예시에서 호학당은 ‘brandWeb’이라는 프로젝트 안에 ‘hohakdang.com’이라는 파일을 생성했습니다.

 

 

Step 4. 페이지(Pages)

Figma > 팀 > 프로젝트 > 파일 > 페이지

 

프로젝트가 시작되고 UX기획/디자인 업무가 시작되면, 페이지(Pages)를 기준으로 협업이 진행된다고 생각하면 쉽습니다. 대다수 실무 현장에서 프로젝트나 파일은 체계적으로 관리되는 것에 비해 페이지는 그렇지 않은 경우가 많습니다. 따라서 페이지를 체계적으로 관리하는 것이 가장 핵심이라고 할 수 있으며, 페이지가 잘 관리되어야 기획/디자인/개발팀의 소통도 한결 수월해지게 됩니다.

 

일반적으로 페이지를 관리할 때에는 실제 앱서비스 페이지 또는 메뉴를 생각하면 쉽습니다. 예를 들어 ‘사용자 서비스/앱 디자인 시안’ 파일 안에서는 [홈, 식당 상세, 메뉴 상세, 장바구니, 마이페이지] 등으로 페이지를 구성할 수 있습니다.

 

또한, 서비스의 가장 낮은 버전 업데이트인 패치의 경우 별도의 페이지를 만들거나 하지않고, 페이지 내에서 바로 수정을 진행하되 Figma에서 제공하는 Version History(아래 내용 참고)를 활용하여 관리하는 것이 좋습니다.

 

파일 또는 페이지를 관리할 때에는 Component라는 개념을 빼놓을 수 없는데, Component를 어떻게 조직하고 활용하느냐에 따라 UXUI 기획 및 디자인 작업의 효율이 크게 달라지게 됩니다. Component 관리에 대한 내용은 다양한 디자인 방법론이 있으며, 프로젝트에 가장 알맞은 것을 선택하는 것이 중요합니다.

이와는 별개로 파일 구성 측면에서도 Component를 별도의 프로젝트로 구성할 수도 있고, 파일로 구성할 수도 있고, 페이지로 구성할 수도 있습니다. 이에 대해서는 프로젝트 규모에 따라 각 구성 방식에 대한 장단이 있기 때문에 명확한 정답이 있지는 않지만, 형상관리 측면에서는 별도의 파일로 구성하여 팀 라이브러리로 활용하는 것을 권장합니다.

 

이번 예시에서 호학당은 ‘BrandWeb/hohakdang.com’ 내에 [home, about, contact]으로 페이지를 구성했습니다.

 

Figma > 팀 > 프로젝트 > 파일 > 페이지 > 레이어

 

페이지 구성이 완료되었다면, 이제부터 기획팀과 디자인팀이 함께 맡은 업무를 중심으로 페이지 내에서 협업을 진행하면 됩니다. 이때 하나의 페이지 안에 기획 와이어프레임과 디자인 시안이 함께 있을 수도 있고, 디자인 시안의 경우 모바일, 태블릿, PC 크기의 시안이 모두 있을 수도 있습니다. 이에 대한 기준은 결과물을 보고 참고하여 개발해야 할 개발팀과 함께 협의하여 정하는 것이 중요합니다.

 

또한, 원활한 협업을 위해서는 레이어를 잘 정리하는 것도 정말 중요한데, 이를 위해서는 프레임(Frame)과 오토 레이아웃(AutoLayout)에 대한 개념을 이해하고 있어야 합니다. 

 

일반적으로 하나의 페이지 안에서는 하나의 메뉴 또는 기능에 대해 정리하되 그와 관련된 다양한 케이스(권한이나 인터랙션에 따른 UI 변경 사항 등)를 구체적으로 보여주는 것이 중요합니다.

 

 

 

버전 관리 방법

위 내용에서 팀 > 프로젝트 > 파일 > 페이지 구성에 대한 개념과 어떻게 관리하는 것이 효율적인지를 살펴보았다면, 이번에는 버전 관리에 대해서 간략하게 살펴보겠습니다. 실무적 관점에서 버전 관리를 이해하려면 Git의 개념에 익숙해져야 하는데,

 

구체적인 내용은 『인간다운 깃』이라는 책을 읽어보는 것을 추천하고, 지금은 아주 간략하게만 설명하고 넘어가겠습니다.

 

사실 Git이란 개념은 일반적으로 기획자 또는 디자이너에게 익숙하지 않지만 아주 오래된 개념입니다.

 

예를 들면, 학창시절 조별 과제 피피티를 ‘과제1_완료’로 저장했다가 오탈자를 발견하고는 ‘과제1_최종완료’로 수정했지만 중간에 빼먹은 내용이 있어 추가하고난 뒤 ‘과제1_진짜최종’으로 저장하고.. 이렇게 몇번 지나고 나면 ‘과제1_dddddd’과 같은 파일들이 넘쳐나 무엇이 무엇인지를 알기 힘들게됩니다. 최종 파일이 무엇인지 말고도 중간에 이전으로 돌아가려고 한다면 그것도 참 어려운 문제입니다.

 

이를 해결하기 위해 하나의 파일에서 내용이 추가/변경/삭제 등 변화가 생긴다면 그 변화된 사항(history)을 저장하여 언제든 돌아갈 수 있도록 하는 기술이 Git이라고 생각하면 쉽습니다. 즉, 내용이 파일이 변경될 때마다 새롭게 저장할 필요 없이 하나의 파일 속에 변경 이력이 다 담을 수 있는 것입니다.

 

Figma 상단 메뉴바 > File > Show Version History 에서 가능한 버전 관리

 

Figma에서는 서비스 자체적으로 간단한 Git 기능을 제공하고 있습니다. 파일을 켜고 상단 메뉴바에서 File > Show Version History를 클릭하면, 자동 저장되고 있는 이력 확인이 가능하며, 사용자가 별도로 이력을 저장한 경우 해당 이력을 중점적으로 확인할 수 있습니다.

 

일반적으로 Version History는 서비스 구축 단계에서는 기획/디자인 완료, 컨펌, 보안 등 상황에서 저장하고, 서비스 운영 단계에서는 규모에 따라 마이너 또는 패치 시 저장하게 됩니다. Version History를 저장할 때에는 적절하게 코멘트를 적어 놓는 것이 추후 관리에 도움이 됩니다.

 

 

 

개발팀과의 협업

기획팀 및 디자인팀에서는 Figma를 통해 업무를 진행하고 면밀하게 협업하게 되지만, 퍼블리싱팀이나 개발팀(프론트엔드 기준)에서는 실제 디자인된 결과를 보고 UI를 개발해야 합니다. 이를 위해서는 해당 UI의 위치, 크기 등 다양한 스타일 및 제한 조건을 확인해야 합니다(물론 디자인팀에서 이에 맞춰 제대로 UI 디자인 작업을 진행해야겠지만).

Figma Dev Mode

 

Figma에서는 개발자가 이러한 정보들을 쉽게 확인할 수 있도록 Dev Mode를 지원하고 있습니다. 디자인팀에서는 완성된 프레임 마다 ‘Mark as ready for dev’를 설정하여 개발팀과 개발 진행 가능여부를 소통할 수 있고, 개발팀에서는 파일 내 화면 모드를 Dev Mode로 전환하여 UI 개발에 필요한 정보를 쉽게 확인할 수 있습니다.

 

 

 

이처럼 Figma의 기본적인 계층 구조와 실무에서 버전 관리 및 개발팀과의 소통 시 활용할 수 있는 부가 기능을 이해하고 활용한다면, UXUI 업무를 분명히 더 효율적으로 할 수 있을 것입니다!