주니어 서비스 기획자의 사이드
프로젝트 여정 기록(3)
기획 과정과 MVP 기능 합의
1편: https://brunch.co.kr/@jiseol/1
2편: https://brunch.co.kr/@jiseol/2
아이템이 정해졌으니 곧바로 기획 과정에 착수해야만 했다.
이미 이전 아이템에 많은 시간을 사용해버린 탓에 급하게 이루어진 것 같은 점이 아직까지도 아쉽긴 하지만, 그래도 우리가 생각한 아이디어의 가치와 적절한 기능을 도출하기 위해 부족한 시간에도 최선의 아웃풋을 내고자 노력했다.
정말입니다 믿어주세요사용자 스터디
사용자 스터디를 하기 전에 먼저 가설을 세워보았다.
직장인들의 회의는 대부분 효율적으로 이루어지지 않고 있다.
우리의 서비스 아이디어가 '직장인들이 효율적으로 회의를 할 수 있도록 돕는 웹 서비스'이므로 직장인들이 평소에 비효율적인 회의를 경험하고 있고, 이에 대한 페인 포인트가 있어야지 우리 서비스가 가치가 있을 것이라 판단하였다.
그래서 이를 증명하기 위해 주변 직장인 지인 2명을 대상으로 간단한 질문을 던지고 답변에서 인사이트를 얻고자 하였다. (주어진 시간이 많지 않아 정말 간단하게 진행하였다..ㅠㅠ)
한 명은 IT회사에 다니는 기획자, 다른 한 명은 이커머스 온라인 MD로 다른 성격의 직무를 가진 (예비) 사용자들이었다.
[사용자 인터뷰에서 했던 질문 리스트]
회사에서 회의 시간은 어떤 방식으로 fix 하시나요?
회의 준비는 어떤 식으로 진행되나요?
보통 회의 진행 방식이 어떻게 되나요?
회의를 하면서 가장 불편한 점은 무엇인가요?
회의 내용은 어떤 식으로 기록되나요?
회의록 작성 주체는 누구인가요?
인터뷰 대상자들의 평소 회사에서의 회의 행태와 그 속에서 문제점을 파악하기 위해서인지 자연스럽게 '미팅 전(회의 준비 단계) - 미팅 중 - 미팅 후' 흐름에 따라 질문하게 되었다.
답변을 수집하고 나니 가장 큰 페인 포인트들은 대부분 미팅 진행 중에 나타나는 것으로 보였다.
각 인터뷰 대상자들의 몇 가지 페인 포인트만 간단하게 공유하자면 이랬다.
사용자 인터뷰를 통해 나온 대표적인 페인 포인트들대상자들이 '지체되는 시간'으로 인해 연속적으로 문제가 발생하는 점을 이야기하는 점을 발견하였고, 상대적으로 들인 시간에 비해 만족스럽지 않은 결과를 경험했다는 점에 있어서 우리의 가설이 어느 정도 부합한다고 보여졌다.
수집된 답변들은 다음에 진행할 Key message와 기능을 도출하는 아이데이션 단계에서도 활용하였다.
아이데이션 보드 작성
사용자 스터디를 진행한 이후에는 '우리 서비스의 Key message 도출을 위한' 브레인스토밍을 진행하였다.
이 key message는 고객의 공감 포인트를 살 수 있는 문장 형태로 추출하고자 하였다. 우리가 서비스를 만들어가는 과정에서 계속해서 유념할 수 있고, 서비스가 출시되었을 때도 활용할 수 있는 대표 문구를 뽑아내는 것이 목적이었다.
이 브레인스토밍 역시 코시국으로 인해 화상회의로 이루어졌기 때문에 PM님과 나는 구글밋을 하면서 FigJam 툴을 활용하여 진행하였다. 본격적인 브레인스토밍 전에 이 아이데이션 미팅 목적과 미팅 목표를 명확하게 하는 것도 잊지 않았다.
미팅 목적(이 미팅의 목적은 무엇일까?)
- 고객에게 어필할 key message를 잡고 싶음
그 목적을 달성하기 위해 무엇을 해야 하나?
- User Journey Map에서의 각종 사용자 행동, 문제를 정리해본다
(여기서 고객 keyword로 공감 포인트를 찾는다!)
미팅 목표
- User에게 전달할 value 포인트, 키워드를 찾는다.
그리고 '미팅 전 - 미팅 중 - 미팅 후' 단계에 따라 '행동', '사용자의 공통점', '사용자의 생각&말', '채널', '기회' 이렇게 5가지의 카테고리를 구분하여 아이데이션을 진행하였다.
*5가지 카테고리: 행동(사용자가 무엇을 하는지), 사용자의 공통점(행동을 수행할 때 발생하는 문제, 어려운 점, 안 좋은 경험), 사용자의 생각&말(행동을 수행할 때 떠오르는 생각&얘기한 말), 채널(Touch point. 행동을 수행할 때 어떤 채널/미디어를 사용하는지), 기회(해결을 하기 위한 아이디어)
Figjam으로 진행한 아이데이션이전 사용자 스터디 답변과 추가로 데스크 리서치 등을 통해 얻은 정보들을 각 카테고리와 과정에 맞게 포스트잇에 작성하여 배치해보았다. 배치를 하다 보니 추가적으로 연속성이 있는 발생할 수 있는 태스크들도 작성하여 서로 이어 보기도 하고, 인사이트나 질문 사항이 생겼을 경우 다른 색상의 메모지를 붙이는 방식으로 아이디어를 발산하고 수렴하는 과정을 거쳤다.
이렇게 사용자들이 미팅을 하면서 수반되는 행동과 생각들을 통해 Key message를 도출하였고, 인사이트는 추후 우리 서비스의 주요 기능으로 활용하게 되었다.
서비스 Key message
"하루 종일 회의하느라 내 업무 할 시간이 없어요."
"회의했는데 결론이 왜 없죠?"
"분명 이 회의 지난번에도 한 것 같은데.."
"누가 회의를 맺고 끊어줬으면 좋겠다."
User에게 전달할 value
- 시간 비용을 Save 해준다.
- 시간 대비 퀄리티 있는 회의를 도와준다.
User Story에 따른 기능, 아이디어 정리
아이데이션을 기반으로 우리 웹서비스의 페이지 구성을 지금까지 가져온 '미팅 전-미팅 중-미팅 후' 흐름대로 페이지를 구성하기로 하였고, 각 흐름에 따라 기획 과정에서 생각해야 할 point를 짚고 넘어가야 했다.
미팅 전에는 주최자가 효율적인 미팅 진행을 위해 미리 생각해보게 하자.
(미리 고민하고 진행하는 미팅은 퀄리티가 다를 것이며,
그 다름을 느끼게 해주는 것을 미팅 전 화면에서 제공할 point로 삼자)
미팅 진행 중일 경우, 효율적인 미팅 전개를 위한 에지를 고민하자.
미팅이 종료되었을 때, 미팅이 효율적으로 진행되었는지 사용자 스스로 인지하고, 회의의 퀄리티를 체크할 수 있는 지표를 제공하자.
이에 따라 필요한 페이지를 구성하고, 각 페이지에서 발생할 User story에 따른 기능과 아이디어를 노션에 정리하는 작업을 하였다.
이후 전체 회의에서 개발자들과 디자이너들과 작성된 기능들에 대해 논의하고, MVP에서 구현할 체크박스 열을 만들어 협의된 기능들을 따로 체크할 수 있도록 하였다. 그렇게 Fix 된 기능을 가지고 본격적으로 실제 서비스 화면을 구성하는 과정으로 넘어갈 수 있었다.
*스스로 아쉬웠던 점:
우선 시간이 부족하여 사용자 스터디를 퀵하게 진행할 수밖에 없었던 점,
우리 모두 직장인이다 보니 스스로를 타깃 사용자 범주에 넣어 생각한 점 (<인스파이어드>에서는 제품을 만드는 이들이 스스로를 타깃 사용자의 범주에 넣어서는 안 된다고 했다..ㅠㅠ),
이미 어느 정도 우리가 서비스를 통해 전달할 가치가 사용자의 페인 포인트를 해결하는데 부합하다고 확신을 가져버린 점(사용자 스터디 답변이 어느 정도 부합한 건 맞지만) 등
나는 에이전시에서 근무하면서 실제 프로덕트를 출시하고 테스트하는 사이클을 경험해보지 못해 책으로나 다른 동종업계 지인들에게 간접적으로 들어왔지만, 사이드 프로젝트가 아닌 실제 사업 프로덕트였다면 좀 더 냉정하고 제삼자의 시선으로 객관적으로 세세하게 검증했어야 하지 않을까 싶었다..
어쨌든
투 비 컨티뉴...
