🧭 구조를 그렸다면, 이제는 '흐름'
지난 글에서는
“왜 이 서비스를 기획하게 되었는지, 어떤 구조로 MVP를 정의했는지”에 대해 이야기했어요.
서비스의 목적과 방향, 그리고 구조와 기능까지 —
‘무엇을 만들 것인가’는 어느 정도 명확해졌죠.
하지만 구조를 그렸다고 해서
곧바로 실 서비스로 이어지는 건 아니에요.
그다음 단계는, 바로 사용자 여정을 실제로 구현하는 과정이었습니다.
이번 글에서는
- 사용자가 어떤 흐름으로 우리 서비스를 경험하게 만들었는지
- 각 화면이 어떤 목적을 가지고 설계되었는지
- 그 흐름이 어떻게 화면 설계서로 구체화되었는지
기획자의 시선으로, UX 설계를 어떤 고민과 기준 속에서 풀어나갔는지
그 실제 과정을 하나씩 소개해보려고 합니다 :)
🧭 한 줄기 흐름을 만들기 위해 고민한 수많은 질문들
기획을 구체화하는 첫 단계에서
제가 가장 먼저 한 일은 ‘각 화면을 어떻게 구성할까’를 고민하는 게 아니었습니다.
그보다 먼저 생각한 건,
사용자가 어떤 흐름으로 우리 서비스를 경험하게 될지를 그리는 일.
즉, 전체 유저 플로우를 설계하는 일이었죠.
사실 이 작업은 지난 글에서 이야기했던
‘서비스 구조를 그리는 작업’의 연장선이자,
그 구조를 사용자 여정이라는 관점에서 한층 더 구체화하는 단계였습니다.
💡 플로우를 그릴 때, 제일 먼저 던졌던 질문들
유저 플로우는 단순히
‘홈 → 서브 → 결과’ 같은 선을 긋는 작업이 아니에요.
저는 이 흐름을 설계하면서, 이런 질문들을 스스로에게 끊임없이 던졌습니다
- 사용자는 어떤 계기로 우리 서비스에 유입될까?
- 유입 직후, 어떤 ‘기대’를 가지고 이 서비스를 시작할까?
- 나는 어떤 목표 행동(예: 회원가입, 결제 등)까지 유도하고 싶은가?
- 그 기대와 목표 사이에는 어떤 마찰이 생길 수 있을까?
- 만약 이탈한다면, 언제/왜/어떻게 이탈할까?
- 그리고… 이탈하더라도, 그 경험이 우리 서비스에 이익이 되도록 만들 수는 없을까?
이 질문들은 결국
전체 플로우를 설계할 때의 기준점이 되어줬고,
기능보다 먼저 ‘사용자의 심리적 동선’을 그리는 데 집중하게 만들어줬습니다.
🔄 우리는 이런 흐름으로 설계했습니다
이번 서비스는 콘서트 현장이라는 매우 특수한 오프라인 환경을 배경으로 했기 때문에,
기존의 웹/앱처럼 단선적인 흐름이 아닌,
현장의 맥락과 팬덤의 감정선에 맞춘 흐름이 필요했습니다.
그래서 유저가 실제로 겪게 될 상황과 목적을 따라
아래와 같은 플로우를 그렸습니다
- 콘서트장 대기 중 → QR 코드 스캔 → 웹으로 즉시 유입
- 설치/회원가입 없이 → 바로 미니 게임 플레이
- 게임 완료 → 랜덤 디지털 포토카드 보상
- 보상 확인 → 소셜 로그인 기반 회원가입 유도
- 마이페이지에서 보상 확인 → 유료 보상 안내
단순한 기능 연결이 아니라,
‘기대 → 몰입 → 보상 → 전환’이라는 감정 흐름에 신경썼어요.
🌀 한 줄기 흐름을 만들기까지, 수많은 고민들
물론 위의 플로우가 처음부터 한번에 이렇게 매끄럽게 정리된 건 아니에요.
수많은 시뮬레이션과 갈래에서 끊임없이 판단하고 조정한 결과였죠.
아래는 실제로 저희가 고민하며 나눴던 주요 갈등 지점들입니다
- 유입 유도는 어떻게 할까?
→ QR 코드에 ‘보상’이라는 동기를 명확히 심자
→ 앱 설치 없이 웹으로 접근 가능하게 하자 - 온보딩 없이도 게임이 가능할까?
→ 콘서트라는 환경상 설명은 최소화
→ 게임 구조 자체를 직관적으로 설계 - 위치 인증은 언제 받아야 할까?
→ 이용 동의와 함께, 보상 직전 타이밍에 한 번에 처리하자
→ UX 마찰을 최소화하는 위치 설정 시점 탐색 - 회원가입은 언제 시켜야 자연스럽게 느껴질까?
→ ‘보상 확인’이라는 동기 부여 지점을 트리거로 활용
→ 로그인은 소셜 로그인으로 간단하게 설계 - 유료 전환은 어떤 흐름으로 설계할까?
→ 랜덤 디지털 보상 → 원하는 실물 보상으로 연결
→ 팬덤의 ‘소장 욕구’를 인센티브로 활용 - 이탈 가능성은 어떻게 다룰까?
→ 이탈 전 한번 더 시도 기회를 줄 수 있을까?
→ 단, 피로감 없이, 정서적으로 매끄럽게 마무리되도록 구성
등등
이처럼 하나의 플로우가 만들어지기까지
다 나열하기 힘들 정도로 정말 많은 질문과 선택들이 있었습니다.
그리고 이런 흐름은 단순히 ‘기획서의 순서’가 아니라,
기획자가 어떻게 사용자 여정을 상상하고,
그 안에서 의도된 전환을 설계했는지를 보여주는 대표적인 결과물이었죠.
🧭 흐름을 그려야 화면이 보인다
전체 유저 플로우를 잡은 뒤, 그다음으로 진행한 작업은
각 화면이 사용자 여정 안에서 어떤 ‘역할’을 맡고 있는지를 정의하는 일이었습니다.
저는 이 과정을 단순히 기능을 나열하거나 배치하는 것이 아닌,
“이 화면은 어떤 맥락 속에서 어떤 행동을 유도해야 하는가”를 명확히 설정하는 단계라고 생각했어요.
그래서 본격적인 화면설계서 작성을 시작하기 전,
각 화면의 성격과 위치, 그리고 기대하는 사용자 행동을 정리해
전체 흐름의 큰 틀을 먼저 만들어 두었습니다.
🧩 핵심 화면은 이렇게 구성되었습니다
(물론 이후 공유하겠지만, 아래 3가지 화면 외 하나의 화면이 더 추가됐어요. 기획은 언제나 수정과 반복의 연속이니까요 ㅎㅎ)
🏠 홈 화면
- 유저가 서비스를 처음 마주하는 첫 진입점
- ‘나만 쓰는 게 아니구나’ 라는 신뢰감을 주는 사회적 증거 요소 구성
- 협업사(엔터테인먼트사)를 위한 브랜드 영역(광고 등) 고려
🎮 게임 플레이 화면
- 서비스의 핵심 경험이 이뤄지는 메인 액션 공간
- 보상 구조는 한눈에 이해되도록 직관적으로 설계
- UX는 최소 설명, 최대 몰입을 목표로
- 무료 vs 유료 흐름 분기를 자연스럽게 연결
📂 마이페이지 화면
- 보상 정리, 소장 감정 자극 → 리텐션의 출발점
- 유료 전환을 유도하거나 기타 부가 기능을 안내하는 곳
- 유저가 다시 방문할 이유를 설계하는 공간
🎯 게임 플레이, 가장 깊게 고민한 화면
그중에서도 가장 많은 고민을 쏟아부은 화면은 ‘게임 플레이’였습니다.
이 화면은 유저에게
- 최초의 서비스 경험을 제공하고
- 회원가입 전환을 유도하며
- 유료 결제의 출발점이 되기 때문이에요.
이곳에서 유저를 어떻게 움직이게 할 것인가가
곧, 서비스 전환 퍼널의 성패를 가르는 핵심이었죠.
✅ 플레이 화면 설계를 위한 핵심 요소
| 구분 | 고민 요소 |
| 게임 형태 | 아티스트 초상 보호 (퍼즐류 금지), 직관적인 조작, 짧은 집중도 |
| 보상 구조 | 보상을 언제, 어떤 조건으로 제공할 것인가 |
| 확률 & 천장 | 팬덤의 반감을 피하면서도 공정하다고 느낄 수 있는 확률과 최대 획득 제한(천장) 설정 |
| 유료 흐름 설계 | 실물 보상은 어떻게 노출하고, 결제는 어느 타이밍에 발생시킬 것인가 |
이 네 가지를 중심으로 전체 로직을 설계했고,
이 과정은 유저 플로우 작업 중에서도 가장 오랜 시간(약 1주)을 들였던 단계였습니다.
하지만 결과적으로 이 구조는
후반부 화면설계 작업에서 큰 기준점이 되어줬고,
정말 효율적인 설계로 이어졌습니다.
💬 유저 플로우 정리는 결국 ‘시간을 절약하는 길’
실무에서는 종종,
리소스가 부족하거나 일정이 빠듯하다는 이유로
유저 플로우 없이 곧바로 화면 설계서 작업에 들어가는 경우가 많습니다.
저 역시 예전에는 그렇게 진행한 경험이 있었고요.
하지만 이번 프로젝트에서는,
초기에 충분한 시간을 들여 전체 플로우와 각 화면의 목적을 선명히 정의해둔 덕분에
이후 작업에서 길을 헤매지 않고 빠르게 집중할 수 있었습니다.
기획을 하다 보면 디자이너, 개발자, 사업부, 데이터팀 등
여러 이해관계자와 함께 수없이 수정하고 조정하는 과정을 거치게 되는데,
이때 가장 흔히 발생하는 리스크 중 하나는
초기의 의도나 방향성이 점점 흐려지는 것이에요.
(이전 프로젝트들을 진행하며 특히 크게 느꼈던 부분이기도 합니다 ㅎㅎ)
하지만 플로우를 명확히 정리해두면
그 구조가 일종의 기준점이 되어
팀원 간 커뮤니케이션과 의사결정이 훨씬 수월해지더라고요.
뿐만 아니라,
놓치기 쉬운 케이스나 예외 흐름도
플로우 단계에서 미리 시뮬레이션하고 검토할 수 있었기 때문에
이후 QA나 수정 작업에서 생길 수 있는 리스크도 확실히 줄일 수 있었습니다.
결국, 유저 플로우를 정리하는 일은 시간을 쓰는 일이 아니라,
오히려 시간을 ‘미리 절약하는’ 전략적인 일이라는 걸 다시금 실감했습니다.
📐 화면설계서, ‘정리’가 아닌 ‘공유의 도구’로 쓰기 위해
기획의 큰 흐름과 화면별 목적이 정리되었다면,
이제 그 내용을 디자이너와 개발자—
즉, 실제 프로덕트를 만드는 메이커들에게 명확하게 전달할 차례입니다.
그때 필요한 것이 바로 화면설계서죠.
하지만 저는 이 문서를 단순한 ‘디자인 가이드’로 보지 않았어요.
기획자의 의도를 구체화하고, 팀 전체가 같은 방향을 바라보며 작업할 수 있게 하는 기준점이 되어야 한다고 생각했습니다.
1️⃣ 화면설계서의 목적은 ‘기획을 연결하는 것’
화면설계서는 단순히 화면 구성을 나열하는 문서가 아닙니다.
UX 흐름, 트리거, 상태 변화 등 기획자가 의도한 맥락을 실체화하고,
각 담당자가 공통된 이해를 바탕으로 작업할 수 있도록 돕는 실행 기준서에 가깝죠.
특히 우리처럼 TF 형태의 소규모 팀에서는
👉 커뮤니케이션 오류를 줄이고, 같은 일을 두 번 하지 않기 위한 장치로서의 역할이 정말 중요했습니다.
(이건 정말 뼈저리게 느꼈어요...ㅎㅎ)
다들 아시겠지만 실무에서는 이런 질문들이 정말 자주 오갑니다
“이 버튼은 눌렀을 때 어디로 가나요?”
“로그인 안 해도 이 기능 쓸 수 있나요?”
“이 모달은 어떤 조건에서 닫히죠?”
이처럼 반복되는 질문과 수정 요청을 줄이고,
팀이 보다 생산적인 논의에 집중할 수 있도록 하기 위해서라도
초반에 명확하게 정리된 화면설계서는 필수라고 생각했어요.
2️⃣ 이 문서는 누구를 위한 걸까?
화면설계서를 작성할 때 저는 항상
“이 문서를 누가 보게 될까?”를 가장 먼저 떠올립니다.
대상에 따라 포함해야 할 정보의 깊이나 표현 방식이 달라지기 때문이죠.
- 디자이너에게는
→ 유저 흐름과 트리거, 행동 유도 의도를 설명해주는 설계 기준서 - 개발자에게는
→ 버튼 조건, 상태 변화, 예외 케이스 등을 확인할 수 있는 기능 명세서 - 기타 내부 공유자(사업/마케팅팀 등)에게는
→ 전체 흐름과 유저 전환 구조를 요약해 보여주는 기획 요약서
그래서 저는 이 문서를 기획자만을 위한 문서가 아니라,
모든 포지션이 함께 보는 공통 문서로 정의하고 작업에 들어갔습니다
3️⃣ 툴은 왜 Figma였을까?
이번 프로젝트에서는 화면설계서를 Figma로 작성했어요.
그 선택에는 분명한 이유가 있었습니다.
- 협업과 피드백이 잦은 TF 프로젝트 특성상,
→ 실시간 코멘트, 변경 히스토리 관리가 가능한 피그마는 작업 투명성과 속도 면에서 최적이었어요. - 기획-디자인-개발 경계가 유연해지는 작업 환경에서도,
→ 하나의 화면 안에서 기획 주석, 플로우 설명, UI 요소를 함께 다룰 수 있어 맥락 공유가 훨씬 수월했습니다. - 텍스트 문서보다 직관적인 커뮤니케이션이 가능했고,
→ 주석 기반 전달이 가능해 생산성과 가독성 모두를 챙길 수 있었죠.
4️⃣ 규칙이 있어야, 반복 작업에서 자유로워집니다
이번 프로젝트는 저 포함 두 명의 기획자가 함께 화면설계서를 작업했어요.
그래서 작성 방식의 통일성이 매우 중요했습니다.
본격적인 작업에 들어가기 전,
전 우선 작성 규칙과 양식부터 정리하기로 했습니다.
사실 누군가에겐 "일이 하나 더 늘었다"고 느껴질 수도 있죠.
그래서 장기적으로 팀 전체의 효율성과 명확한 커뮤니케이션을 위한 기반이라는 생각으로
동료 기획자 분께 기획 컴포넌트 작업 예시를 보여드리며 방향성을 설명드렸고,
감사하게도 흔쾌히 동의해주셨어요.
게다가 의견도 적극적으로 주셔서 정말 든든했습니다! 🙌
📌 우리가 정한 주요 작성 원칙은 다음과 같았어요
- 반복 사용 가능한 구성 요소는 컴포넌트화
- 유도하고자 하는 주요 플로우는 파란색, 예외/이탈 플로우는 빨간색으로 시각적 구분
- 화면별로 타이틀, 상태 조건, 트리거, 결과 등 필수 항목은 공통 포맷으로 정리
이 작업들은 단순히 보기에 깔끔하다는 걸 넘어서,
작업 효율을 높이고, 협업 커뮤니케이션을 줄이는 데 실질적인 효과가 있었어요.
(아마... 개발자 출신의 기획자라는 게 이런 컴포넌트화에서 티가 났을지도 모르겠습니다 😄)
그 결과, 두 명이 작업했음에도 일관성 있는 문서가 자연스럽게 만들어졌고,
초기에는 다소 혼재돼 있던 한/영 표기나 정보 나열 방식들도
지금은 화면 단위로 깔끔하게 정리해 나가는 중입니다.
앞으로 우리 프로젝트의 확장성을 고려했을때도 필요한 과정이라고 생각이 들었어요.
✍️ 정리하며 – 화면설계서는 팀의 ‘공통 언어’입니다
이번 글에서는
유저 플로우를 기반으로 화면의 목적을 정리하고,
그 흐름을 화면설계서로 구체화하는 과정을 공유해봤어요.
결국 화면설계서는 단순한 문서가 아니라,
기획자의 의도를 팀 전체와 공유하고 연결하는 도구라고 생각해요.
특히 작은 팀일수록
명확한 흐름과 기준이 있어야
작업 속도와 완성도를 모두 지킬 수 있다는 걸 다시 한 번 느꼈습니다.
🔜 다음 글 예고 – 설계된 화면, 이제 실제로 움직이게 만드는 일
다음 글에서는
이렇게 정리된 화면설계서를 바탕으로
어떻게 디자이너, 개발자와 협업했는지 등 실제 구현 흐름으로 넘어갔는지 이야기해보려 해요.
‘기획자에게 필요한 감각’을 중심으로 풀어볼게요 :)
'서비스 기획' 카테고리의 다른 글
| 🗣️ 찝찝함을 설계해서 사용자의 행동 바꾸기: 자이가르닉 효과, UX (0) | 2026.01.31 |
|---|---|
| PM으로 일하며 느낀, 꼭 필요한 역량 5가지 (3) | 2025.05.26 |
| 🧩 PM으로 일하며 실제로 도움이 되었던 우선순위 정하기 기법들 (1) | 2025.05.23 |
| 💡기획자가 수많은 변경 요청에 대처하는 방법 (1) | 2025.05.02 |
| 📝 기획자는 어떻게 시작할까 – 새로운 프로덕트를 만드는 기획의 흐름 (5) | 2025.04.17 |