PEC 1주차에서는 하나의 프러덕트를 만들 때 가장 먼저 "WHY"를 정의하는 과정에 집중했다. 즉, 무엇을 만들 것인가보다 왜 만들 것인가를 고민하며, 사용자 인터뷰를 통해 문제를 깊이 이해하고 페르소나를 완성하는 단계였다. 하지만 문제를 정의했다고 해서 곧바로 해결책이 보이는 것은 아니었다. 진짜 중요한 것은 이 문제를 어떻게 해결할 것인가(HOW)에 대한 고민이었다.
다시 한번 골든 서클(Golden Circle)을 떠올려보면,
- WHY(왜?): 1주차에서 문제 정의와 사용자 페르소나 분석을 통해 명확히 했다.
- HOW(어떻게?): 2~3주차에서는 이 문제를 해결하는 방법을 찾는 과정이다.
- WHAT(무엇을?): 이후 단계에서는 실제 프로덕트를 만들어가는 과정이 진행될 것이다.
이번 글에서는 2~3주차 동안 문제를 해결하기 위해 어떻게 접근하고 구체화했는지 다뤄보려고 한다.
사용자 인터뷰에서 얻은 데이터를 정리하고 의미 있는 정보로 정제한 후, 이를 기반으로 서비스의 흐름(Service Flow)을 설계했다.
이 과정에서 중요한 것은 단순히 기능을 추가하는 것이 아니라, 사용자가 어떤 방식으로 서비스를 경험하게 될지를 명확하게 정의하는 것이었다. 즉, 단순한 아이디어를 실제 서비스로 구체화하는 과정이 어떻게 이루어졌는지를 살펴보려 한다.
데이터(Data)란? 그리고 정보(Information)이란?
먼저, 데이터(Data)와 정보(Information)의 차이를 짚어볼 필요가 있다.
데이터(Data)란 가공되지 않은 사실이나 값을 의미한다. 예를 들어, 사용자 인터뷰에서 "이 기능이 필요해요"라는 응답을 여러 번 들었다고 하자. 이 자체는 단순한 데이터일 뿐이다.
그러나 이러한 응답이 반복적으로 나타난다면, 우리는 단순한 데이터가 아니라 "이 기능이 사용자들에게 정말 필요하다"는 정보를 도출할 수 있다. 정보(Information)란 바로 이러한 과정, 즉 데이터를 분석하고 정리하여 의미를 부여한 것을 의미한다.
즉, 데이터는 단순한 사실의 나열이지만, 이를 어떻게 가공하고 해석하느냐에 따라 정보가 되고, 결국 서비스 기획의 방향을 결정하는 중요한 요소가 된다.
처음에는 "왜 갑자기 데이터와 정보를 이야기하는 걸까?"라는 의문이 들었지만, 2~3주차 세션을 진행하며, 이 과정이 결국 더 나은 서비스 설계를 위한 필수적인 단계임을 깨닫게 되었다.
이 과정을 거쳐야만 사용자가 정말 원하는 것이 무엇인지 파악할 수 있고, 불필요한 기능을 걸러내며, 효과적인 서비스 흐름을 만들 수 있다. 단순히 데이터를 쌓는 것이 아니라, 데이터 속에서 의미를 찾고, 이를 서비스 설계에 반영하는 과정이 중요했다.
Information Flow (추상화)
2주차에서 중요한 개념은 Information Flow였다. 위에서 계속 이야기했지만, 이는 수집한 데이터를 단순히 나열하는 것이 아니라, 이를 분석하여 의미 있는 정보로 변환하는 과정이다.
사용자 인터뷰에서 특정 기능이 많이 언급되었다고 해서 곧바로 추가해야 하는 것은 아니다. 단순히 빈도만을 기준으로 기능을 결정하는 방식은 서비스의 복잡성을 증가시키고, 핵심 사용자 경험을 흐릴 수 있다. 따라서, 느낌이나 직관에 의존하기보다는, 체계적인 분석과 구조화 과정을 통해 데이터가 실제로 의미하는 바를 파악하는 것이 중요하다.
이를 위해 2주차에서는 Service Flow, Information Mind Map, User Workflow를 작성하는 작업을 진행했다. 이러한 과정은 단순한 피드백의 모음이 아니라, 사용자의 문제를 해결하기 위한 정보의 흐름을 정의하고, 이를 바탕으로 서비스의 방향성을 구체화하는 과정이었다.
이 과정에서 중요한 개념이 추상화(Abstraction)였다. Information Flow를 만드는 것은 마치 그림을 그릴 때 스케치를 하는 과정과 같다.
초보자는 그림을 그릴 때 세부적인 부분부터 그리려 하지만, 완성도 높은 그림을 그리려면 먼저 전체적인 구도를 잡고 큰 형태를 그린 후, 점차 디테일을 더해 나가야 한다. 마찬가지로, 서비스 기획에서도 처음부터 모든 기능을 세부적으로 정의하는 것이 아니라, 추상화를 통해 핵심적인 흐름을 먼저 잡고 점차 구체화해 나가는 과정이 필요하다.
즉, Information Flow는 서비스의 스케치 단계와 같고, 추상화를 통해 불필요한 요소를 덜어내고 핵심적인 흐름을 먼저 설계하는 것이 중요하다. 이후, 이를 바탕으로 점차 세부적인 기능과 사용자의 행동을 구체화하며 서비스의 형태를 완성해 나가는 것이 중요하다.
2주차 세션을 참고하여 Service Flow, Information Mind Map, User Workflow를 쉽게 정리하면 다음과 같다.
- Service Flow: 사용자가 서비스를 이용하면서 문제를 해결하는 과정을 정리한 것이다. 어떤 기능이 언제, 어떻게 연결되는지를 정리해서 서비스의 흐름을 한눈에 볼 수 있도록 만든다.
- Information Mind Map: 사용자 경험과 데이터를 정리하고, 관련된 요소들을 연결하여 시각적으로 정리한 것이다. 이를 통해 서비스에서 중요한 정보가 무엇인지 쉽게 파악할 수 있다.
- User Workflow: 사용자가 서비스를 실제로 사용할 때 어떤 과정을 거치는지를 단계별로 정리한 것이다. 이를 통해 사용자가 서비스를 어떻게 탐색하고 이용하는지를 이해하고, 더 편리한 경험을 제공할 수 있도록 설계한다.
각자 Service Flow, Information Mind Map, User Workflow를 작성하였다. 아래는 내가 정리한 서비스 플로우, 정보 마인드맵, 그리고 사용자 워크플로우이다.
1. Service Flow
1주차에 작성한 페르소나를 기반으로, 서비스의 핵심 기능을 큰 흐름으로 나누고, 각 기능의 상세한 플로우를 정의하는 방식으로 접근했다.
프로폴리오(서비스명)를 기준으로 주요 기능을 먼저 정의한 후, 각 기능의 흐름을 정리하였다.
주요 기능은 다음과 같다.
- 프로필 작성: 사용자가 자신의 정보를 입력하고 프로필을 생성하는 과정
- 프로필 목록: 여러 프로필을 확인하고, 검색 및 필터링할 수 있는 기능
- 프로필 공유: 생성된 프로필을 링크 혹은 다른 방법을 통해 공유하는 기능
- 프로필 보관: 사용자가 프로필을 관리하고, 보관 또는 수정할 수 있는 기능
이러한 기능을 중심으로 사용자의 행동이 어떻게 흐르는지(Service Flow)를 구조화하여 작성하였다.
2. Information Mind Map
Information Mind Map은 서비스에서 필요한 데이터를 정리하고, 백엔드와 프론트엔드 에서 필요한 데이터들을 구조화하는 과정이다. 내가 작성한 Mind Map은 User(사용자), Profile(프로필), Share(공유), Save(보관) 등 주요 기능과 연관된 데이터를 한눈에 파악할 수 있도록 구성했다.
📌 주요 구성 요소
- 사용자(User) 정보
- ID 관리: 네이버, 카카오, 구글 로그인 및 패스워드 기반 로그인 지원
- 기본 필드: 이름, 닉네임, 이메일, 성별, 생년월일 등 (선택적 입력)
- 커스텀 필드 지원: 확장성을 고려한 데이터 구조
- 프로필(Profile) 관리
- 자동/수동 프로필 작성
- 테마 설정: 테마 색상, 타입 선택 가능
- 다중 프로필 지원 (
add profile,is_main필드)
- 프로필 공유(Share)
- 이미지 변환, URL, QR 코드 공유 지원
- 프로필 보관(Save)
- 보관된 프로필 리스트 관리 (
profile_idx)
- 보관된 프로필 리스트 관리 (
3. User Workflow 작성 과정
User Workflow는 사용자가 서비스를 이용하는 전체적인 흐름을 정리한 것으로, 사용자가 수행하는 주요 활동(User Activities), 세부 작업(User Tasks), 그리고 실제 실행되는 스토리(User Stories)를 구조적으로 정리하였다.
내가 작성한 User Workflow는 프로필 작성, 프로필 공유, 보관의 세 가지 핵심 기능을 중심으로 구성되며, 사용자의 행동이 어떻게 연결되는지를 시각적으로 표현하였다.
개인 작업에서 팀 작업으로: Information Flow 통합 과정
개별적으로 작성한 Service Flow, Information Mind Map, User Workflow가 끝이 아니라, 이제는 각각의 Information Flow를 하나로 합치는 과정이 필요하다.
이때 단순히 모든 기능을 합치는 것이 아니라, 정의한 기능들이 실제로 사용자가 필요로 하는 것인지 다시한번 검증하는 과정을 거쳐야 한다. 이를 위해, 우리는 다시 한 번 사용자 인터뷰를 진행하여 기존에 정의한 기능들을 검토하고, 불필요한 기능을 걸러내고 정말 필요한 기능만을 남기는 과정을 거쳤다.
- 프로필 생성
- 사용자가 자신의 정보를 입력하여 프로필을 생성할 수 있는 기능
- 프로필 목록
- 사용자가 생성한 프로필들을 한눈에 보고, 관리할 수 있는 기능
- 테마 관리
- 사용자가 프로필의 테마를 직접 생성하고, 색상 및 스타일을 커스터마이징할 수 있는 기능
3주차: 서비스 구체화
3주차에는 2주차에서 정의한 정보 흐름을 바탕으로, 실제 서비스 구조를 설계하고 사용자 경험을 구체화하는 과정이 진행되었다. 이 과정의 목표는 보다 직관적인 UX를 구성하고, 기능 간의 연계를 명확하게 정리하는 것이었다. 이를 위해, 다음과 같은 세 가지 과정을 거쳤다.
이를 위해 다음과 같은 세 가지 과정을 통해 서비스를 구체화하였다.
- 서비스 프로세스: 사용자가 서비스를 이용하는 흐름을 정리하고, 각 기능이 어떤 순서로 연결되는지 설계하는 과정
- 메뉴 구성: 사용자가 필요한 정보를 빠르게 찾을 수 있도록 메뉴를 정리하고, 더 편리하게 이용할 수 있도록 구성하는 과정
- 사이트맵 구성: 서비스의 각 페이지와 기능이 어떻게 연결되는지 정리하여, 사용자가 쉽게 이해하고 탐색할 수 있도록 만드는 과정
그렇게 다음과 같은 과정을 진행했다.
1. 서비스 프로세스(Service Process) 설계
서비스 프로세스를 설계하면서, 사용자가 원하는 목표를 효과적으로 달성할 수 있도록 주요 기능을 정리하였다. 이를 위해 프로필 작성, 프로필 목록, 프로필 공유, 테마 목록 네 가지 기능을 정의하고, 사용자가 각 기능을 어떻게 이용할 수 있는지 설계했다.
이 과정에서 중요한 점은, 각 기능이 다른 기능에 의존하지 않고 독립적으로 존재해야 한다는 것이다. 기능들이 서로 연결되면, 사용자는 특정 기능을 이용하기 위해 불필요한 단계를 거쳐야 할 수도 있다. 이를 방지하기 위해 각 기능이 독립적으로 작동할 수 있도록 설계하여, 사용자가 원하는 작업을 직관적으로 수행할 수 있도록 구성했다.
2. 메뉴 구성 (Navigation Design)
이 과정은 우리 서비스에서 어떤 네비게이션(메뉴)이 필요한지 정리하는 작업이다. 사용자가 서비스를 이용할 때 어떤 경로로 이동하며, 각 기능에 쉽게 접근할 수 있도록 구성하는 것이 중요했다.
메뉴를 정리하면서 로그인 후 화면이 프로필 목록과 테마 목록으로 나뉘는 것이 적절하다고 판단했다.
- 프로필 목록(메인 화면) → 사용자가 생성한 프로필을 확인하는 공간
- 프로필을 선택하면 상세 페이지로 이동
- 상세 페이지에서 프로필 수정, 공유, 복사, 삭제 등의 기능을 수행 가능
- 테마 목록 → 프로필의 테마를 관리하는 공간
- 테마 미리 보기 기능 제공
- 새로운 테마를 추가하거나 삭제할 수 있음
이러한 구조를 통해, 사용자가 필요한 기능을 직관적으로 찾을 수 있도록 메뉴를 구성했다.
3. 사이트맵 (Sitemap) 구성
사이트맵은 서비스 내에서 사용자가 어떤 경로를 따라 이동하는지를 시각적으로 표현한 것이다. 이를 통해 각 페이지가 어떻게 연결되는지 정리하고, 사용자 경험을 고려한 최적의 탐색 경로를 설계할 수 있다.
처음 사이트맵을 구성할 때 실수했던 부분은 기능을 중심으로 구성했다는 점이다. 기능 위주로 정리하다 보니, 이전에 작성했던 서비스 플로우와 차별성이 없어지는 문제가 발생했다. 이때, 멘토님이 사이트맵은 기능이 아니라, 실제 Router로 등록될 모든 페이지를 정의해야 한다고 조언해 주셨다.
이를 반영하여 단순히 기능 간의 흐름을 정리하는 것이 아니라, 서비스에서 사용될 모든 페이지를 구조적으로 정리하는 것을 목표로 했다. 즉, 기능 흐름이 아니라, 실제 라우터(Router)에 등록될 페이지를 기준으로 구성해야 한다.
마무리
2~3주차를 지나면서, 단순히 문제를 정의하는 것을 넘어, 이 문제를 실제로 어떻게 해결할 것인가?에 대한 고민이 깊어졌다.
처음에는 사용자 인터뷰에서 나온 피드백을 모으고 기능을 정리하는 과정이 전부라고 생각했다. 하지만 진행하면서 단순히 기능을 추가하는 것이 아니라, 사용자가 서비스를 어떻게 경험할지를 중심으로 설계하는 것이 더 중요하다는 것을 깨달았다.
특히, 서비스 프로세스, 메뉴 구성, 사이트맵을 만들면서 "기능을 나열하는 것"과 "사용자의 흐름을 고려하는 것"은 전혀 다르다는 점을 실감했다. 처음에는 기능 중심으로 정리하다 보니 기존 서비스 플로우와 차별성이 없었고, 이걸 어떻게 정리해야 할지 막막했다. 그런데 멘토님이 "사이트맵은 기능이 아니라, 실제 Router에 등록될 모든 페이지를 기준으로 구성해야 한다"라고 말씀해 주셨고, 이걸 반영하면서 서비스 구조가 훨씬 명확해졌다.
또 한 가지, 이 과정을 거치면서 서비스의 구조를 문서화하는 게 얼마나 중요한지도 새삼 깨달았다. 그냥 기능을 만들면서 "이건 이렇게 하면 되겠지?" 하는 것과, 실제로 서비스의 흐름을 시각적으로 정리하는 것은 전혀 달랐다. 이 작업을 먼저 했더라면, 개발할 때 훨씬 수월했을 것 같다. 그리고 팀원들 간의 협업이나, 나중에 새로운 사람이 합류했을 때도 이걸 보면 빠르게 서비스 구조를 이해할 수 있을 거란 생각이 들었다.
이제 다음 단계는 실제 구현 단계로 넘어간다. 구체화한 내용을 바탕으로 바로 코드를 작성하는 것이 아니라, FSD(Folder Structure Design) 아키텍처를 기반으로 폴더와 파일 구조를 먼저 설계하는 과정을 진행할 예정이다. 이를 통해 코드 작성 전에 서비스의 전체적인 설계를 정리하고, 기능 간의 명확한 역할 분리를 할 수 있도록 준비하는 과정을 다룰 예정이다!
