업무 흐름 랩: Figma Make로 디자인 직접 배포

업무 흐름 랩에 오신 것을 환영합니다. 여기에서는 Figma 제품과 툴을 사용한 샘플 업무 흐름을 소개합니다.

기존에는 "사소한 문제를 발견했어요"에서 "배포되었어요"까지의 과정이 티켓을 통해 이루어졌습니다. 디자이너가 티켓을 생성하면 백로그에 추가되고, 엔지니어링 팀이 이미 집중하고 있는 다른 작업들에 묻히게 됩니다. 세밀한 수정이 필요한 경우, 이러한 대기열에서 좋은 의도가 묻히게 됩니다. 우선순위를 정하기에는 너무 세밀하고, 그렇다고 포기하기에는 너무 중요하기 때문에 결국 처리되지 못하고 오래 남게 됩니다.

두 번째 문제점도 있습니다. 디자이너가 서면으로 된 설명을 전달할 때 미묘한 뉘앙스는 전달되지 못합니다. "간격을 조금 좁혀주세요" 또는 "스크린 리더가 이 부분을 잘못 읽어줍니다"와 같은 사소한 지적은 스크린샷을 주고받고 설명을 요청하는 과정으로 이어지고, 엔지니어는 디자이너가 직접 결정할 수 있었던 사항들을 해석하는 역할을 하게 됩니다. 하지만 이러한 업무 흐름을 개선할 수 있는 다른 방법은 없을까요?

문제 사례

가상의 박물관인 미래를 상상하는 박물관(MOSF)을 예로 들어보겠습니다. 이 박물관은 문화가 미래를 어떻게 상상하는지 탐구하는 공간입니다. MOSF는 웹사이트의 접근성을 개선하는 동시에 아키텍처를 완전히 새롭게 설계하고 있습니다. 여러 가지 우선순위가 충돌하는 상황에서 프로젝트 리소스 관리는 상당한 과제입니다. 디자이너는 접근성 문제를 해결하고 싶어 하는 반면, 엔지니어는 마찬가지로 중요한 아키텍처의 새로운 설계에 집중해야 합니다. 두 가지 목표를 모두 달성하기 위해 PM은 다른 방식을 제안합니다. 엔지니어는 핵심적인 작업을 담당하고, 디자이너는 Figma Make를 사용하여 프로덕션 코드 기반의 세부적인 수정 작업을 처음부터 끝까지 책임지는 것입니다. 마지막 20%가 바로 기술적으로 작동하는 웹사이트와 진정으로 접근성 있는 웹사이트를 구분하는 요소이므로, 팀은 이 계획에 동의합니다. 디자이너가 어떻게 기존 방식을 뒤집고 캔버스에서 시작하여 검토를 거쳐 병합된 풀 요청까지, 단 하나의 티켓도 생성하지 않고 작업을 진행하는지 살펴보세요.

캔버스에서 피드백 수집

디자이너는 어떤 변경 사항을 적용하기 전에 현재 사용자 경험을 철저히 테스트하고 싶어합니다. 디자이너는 Figma Design에서 에이전트를 사용하여 여행을 계획하는 첫 방문자, 재방문 회원, 스크린 리더를 사용하는 사용자 등 일련의 가상 페르소나를 생성하고, 각 페르소나가 사이트를 탐색하도록 하여 피드백을 수집합니다.

피드백은 구체적이고 대부분 사소한 것입니다. 전시 페이지의 혼동스러운 레이블, 눈에 잘 띄지 않는 클릭 유도 버튼, 한눈에 알아보기 어려운 날짜 선택기, 검색 결과가 없을 때 빈 화면만 나타나는 검색 기능 등이 그 예입니다. 하지만 이러한 사소한 변경 사항으로 웹사이트를 더 쉽게 사용할 수 있습니다.

디자이너는 피드백을 반영한 후, 디자인 변경 사항을 팀에 다시 전달하여 검토를 받습니다. 디자이너, 엔지니어, PM이 함께 방문 페이지의 명확한 레이블, 더 눈에 잘 띄는 클릭 유도 버튼, 더 사용자 친화적인 날짜 선택기를 하나씩 살펴봅니다. 이들은 이러한 변경 사항이 모든 사용자가 어떤 방식으로 웹을 경험하든 쉽게 탐색하고 즐길 수 있는 사이트를 만든다는 공동의 목표에 부합한다는 데 동의합니다.

백로그를 생략하고 코드에 대해 직접 작업

합의된 변경 사항은 작고 명확히 이해되었기 때문에 티켓을 생성하고 기다리는 대신 디자이너는 엔지니어에게 코드베이스 액세스 권한을 요청합니다. 전체 코드를 다시 작성하는 것이 아니라, 이러한 구체적인 수정 사항을 직접 처리하기 위해서입니다.

엔지니어가 액세스 권한을 부여하면 디자이너는 프로젝트의 GitHub 리포지토리를 Make에 연결합니다. 이제 Figma에서 프로덕션 코드베이스가 활성화되어 있으므로 디자이너는 현재 사이트에서 새 브랜치를 생성하고 목록에서 가장 간단해 보이는 수정 작업부터 시작합니다. 바로 Figma 에이전트 페르소나가 알아보기 힘들어 했던 전시 페이지의 날짜 선택기입니다.

정적 모형에서는 5분이면 완료되는 변경 작업입니다. 하지만 Make는 코드에 대해 작업하면서 캔버스에서는 드러나지 않는 사실을 보여줍니다. 날짜 선택기는 일회성 요소가 아니라는 것입니다. 날짜 선택기는 이벤트 캘린더와 회원 가입 흐름에 사용되는 공유 컴포넌트입니다. 단순한 수정처럼 보였던 것이 사실은 세 곳에서 동시에 이루어져야 하는 변경 사항입니다.

티켓 기반 업무 흐름을 사용했다면 전시 페이지의 날짜 선택기만 수정하고 이벤트 캘린더와 회원 가입 흐름에서는 이전 버전을 그대로 두었을 수도 있습니다. 이러한 비일관성은 나중에야 알아차릴 수도 있고, 아예 알아차리지 못할 수도 있습니다. 디자이너가 코드를 직접 수정하고 있기 때문에 공유되는 의존성이 바로 눈에 보이고, 적절한 위치에서 한 번에 수정할 수 있습니다.

수정이 완료되면 디자이너는 나머지 작업인 더 명확한 레이블, 더 눈에 잘 띄는 클릭 유도 버튼, 더 사용자 친화적인 빈 화면 등을 진행합니다. 각각은 사소해 보이지만, 이러한 작업들이 모여 단순히 작동하는 사이트를 세심하게 디자인된 사이트로 탈바꿈시킵니다. 이는 보통 백로그에 쌓여서 나오지 못하는 마지막 20%를 완성하는 작업입니다.

전체 팀과 함께 검토

변경 사항이 적용되면 디자이너는 최종 검토를 위해 팀에 작업물을 보냅니다. 이 단계에서 접근성 목표가 구체화됩니다. 눈에 보이는 수정 사항은 이미 적용되었습니다. 이제 팀은 각 수정 사항이 보조 기술에 어떻게 작동하게 되는지 해당 위치에 주석을 추가 합니다. 공유 날짜 선택기가 읽기 쉬울 뿐만 아니라 소리 내어 읽을 수 있도록 알려주는 aria-label, 화면에 표시되는 내용과 일치하는 스크린 리더 레이블, 클릭 유도 버튼을 건너뛰지 않고 도달하는 포커스 순서, 검색 결과가 없는 경우에도 무음으로 응답하지 않도록 스크린 리더가 알려줄 수 있는 메시지가 포함된 빈 상태 등에 대한 주석이 있습니다.

PM은 모든 사항이 접근성 목표에 부합하는지 확인하고, 엔지니어는 코드에서 처리해야 할 사항에 대해 의견을 제시하며, 디자이너는 최종 수정을 진행합니다.

PR 푸시

마지막 주석이 해결되면 디자이너가 Make에서 바로 코드베이스로 풀 요청을 푸시합니다. 엔지니어는 업데이트된 디자인 의도, 팀의 의견, 동일한 변경 사항에 모두 관련된 접근성 주석이 적용되어 있는 코드를 검토하고 승인한 후 브랜치를 병합합니다. 백로그에서 한 분기 동안 쌓여 있었을 수정 사항들이 하루 만에 배포됩니다.

이러한 작업 방식은 간단하지만 장기적인 효과를 가져오는 변화입니다. 티켓이 종결되고 사라지면 그 안에 있던 결정 사항들도 함께 사라집니다. 하지만 병합된 변경 사항에는 댓글, 접근성 주석, 날짜 선택기를 공유하기로 한 이유 등의 정보들이 그대로 남아 있습니다. 6개월 후 누군가 날짜 선택기를 다시 살펴보더라도, 그 과정에 대한 모든 내용이 팀의 공유 기록에 그대로 남아 있습니다.

프로덕션까지의 경로: 새로운 방식의 핸드오프

기존의 핸드오프 모델은 디자이너와 엔지니어를 조립 라인의 두 작업대처럼 대합니다. 이 모델은 규모가 크고 적절히 정의된 기능에는 효과적입니다. 하지만 세밀한 마무리, 접근성 개선, 제품 경험 전반을 아우르는 완성도 높은 작업에는 디자이너가 직접 코드 작업을 하는 새로운 방식의 핸드오프가 필요합니다.

이러한 작업 방식은 디자이너에게 엔지니어가 되라고 하거나 엔지니어에게 디자이너가 되라고 요구하는 것이 아닙니다. 각자가 가장 중요한 부분에서 판단력을 발휘할 수 있도록 합니다. 엔지니어는 아키텍처 개편에 집중하고, 디자이너는 세부적인 사항들을 처음부터 끝까지 책임지며, PM은 프로젝트 전체가 목표를 향해 나아가도록 관리합니다. 브랜치는 모든 구성원의 기여 내용(눈에 띄는 디자인, 서면 피드백, 스크린 리더가 읽을 레이블 등)을 캔버스에서 병합된 PR까지 전달합니다.

이 업무 흐름 덕분에 마지막 20% 작업이 사라지지 않고 배포될 수 있었습니다.

Make 프로젝트를 GitHub에 직접 푸시하는 방법에 대한 자세한 내용은 도움말 센터에서 확인하거나, 코드로 디자인 및 Figma Design 에이전트 활용에 대한 최신 Config 강연을 시청하세요.