가설 세우기(2): User Behavior Tree
가설 시작점 찾기
30대 남성이 좋아하는 상품을 만들고 입점시켰는데,
30대 남성 구매전환율이 왜 떨어지는 거죠?
이런 질문을 받았을 때 우리 머릿속에는 많은 이유가 한번에 떠오릅니다.
'30대 남성이 그 상품을 좋아하지 않았던건가?'
'상품에 눈에 뜨이지 않았던 건가?'
'가격이 경쟁사보다 비쌌나?'
사용자 문제와 Root cause를 파악하는 일은 막막한 것이 당연합니다. 그렇다고 문제가 발생했을 때 모든 경우를 망라하여 조사할 수 없으니 우리 사업과 유저가 만나는 접점에서 일어날 수 있는 모든 User behavior를 미리 만들어두면 좋습니다. 그런 후, 문제가 포착되었을 때 사용자 입장에서 문제를 파악하는 시작점을 찾는데 활용합니다.
(아래 글을 읽으시기 전에 가설세우기(1) 글을 먼저 읽어보시면 좋아요!)
비즈니스 문제를 해결할 때 Issue tree를 만드는 것을 차용하여 'User behavior tree'를 만든다고 명명해 보겠습니다. User behavior tree는 다음 4가지 개념을 적절히 조합하여 만듭니다.
Business Value Chain
User Jourey Map
MECE
Issue Tree
Business Value Chain
(내용 참고, 그림 출처: What is a value chain analysis? 3 Steps, Harvard Business School Online, 2020.12)
UXer는 product와 밀접하게 일하는 사람이지만, 사용자의 문제는 프로덕트 안에서만 발생하지 않습니다. 따라서 사용자 문제를 해결하는 UXer는 우리 사업이 유저와 만나는 모든 접점을 개략적으로 머릿속에 넣고 있는 것이 필요합니다. 이를 가장 쉽게 파악하기 위해서 Business value chain 개념을 알고 있으면 좋습니다.
Business value chain이란, 기업이 가치를 창출하기 위해 하는 일련의 활동과 프로세스를 정리한 것으로 1980년대 하버드 비즈니스 스쿨 Michael E. Porter 교수님이 만든 아래 그림이 대표적입니다. 사업이 가치를 만들어내는 과정이 사슬처럼 연계되어 있기 때문에 Business value chain이라고 불렀다고 합니다. 아래 그림은 제조-판매 중심 전통 기업 예를 나타낸 것으로, 오늘날 테크 플랫폼 회사 Business value chain은 모습이 다를 수 있습니다.
비즈니스 입장에서 Business value chain 분석을 하는 이유는 1) 비용 절감 2) 상품 경쟁력을 강화할 수 있는 요소를 찾는 것인데요, UXer 입장에서는 3) 사용자 문제가 발생하는 곳을 찾는 도구로 사용해 보겠습니다.
1) 비용 절감: 각 요소를 분석하여 비용을 절감할 수 있는 기회를 파악함
2) 상품 경쟁력 강화: 각 요소를 분석하여 상품 경쟁 우위를 구축할 수 있는 기회를 파악함
3) 사용자 문제 해결: 비즈니스-사용자 접점에서 사용자 문제가 발생할 수 있는 요소를 낱낱이 파악함
Business value chain 구성 요소 중 A, B, C, D가 사용자 접점과 연관이 있습니다. 이 회사를 <30-40대 대상 의류를 제조하고 온라인에서 판매하는 회사>라고 가정해 보면 A, B, C, D 활동은 다음과 같습니다. 사용자 문제는 A, B, C, D와 연관된 모든 상세 활동에서 발생할 수 있습니다.
(참고로, 1980년대 prouduct의 의미는 디지털 프로덕트가 아닌, 만질 수 있는 상품입니다.)
A: Technological development (의류 디자인, 의류 개발, 온라인 커머스 앱 디자인, 앱 개발)
B: Outbound logistics (판매, 의류 포장, 배송)
C: Marketing & Sales (의류 가격, 쿠폰, 온오프라인 광고)
D: After-sales services (의류 품질, 고객센터 응대, 구매 후기)
User Journey Map
(내용 참고, 그림 출처: Journey Mapping 101, Nielsen Normap Group, 2018. 12)
User Journey Map은 사용자가 목적을 달성하기 위해 하는 모든 행위를 시간 순서대로 나열해 보는 것입니다. 사용자의 행위와 감정을 날것으로 관찰하며 문제가 발생하는 곳, 즉 우리가 문제를 해결하여 가치를 만들어낼 기회를 찾기 위한 용도입니다.
MECE (Mutually Exclusive and Collectively Exhaustive)
(참고: MECE principle, wikipedia, 2023.4 접속)
문제 가설을 세우기 위해 'MECE(미씨)하다'라는 개념을 알고 있으면 좋습니다. MECE 하다는 것은 <항목들이 서로 겹치지 않고, 각 항목이 모이면 온전히 전체를 이룬다>는 의미입니다. 예를 들어 대한민국 사람을 나이로 분류하면 MECE 하게 분류한 것입니다. 하지만 대한민국 사람을 직업으로 분류하면 MECE 하게 분류한 것이 아닙니다. 왜냐하면 직업이 여러 개 인 사람도 있고(항목이 서로 겹침) 직업이 없는 사람(온전히 전체를 이루지 못 함)도 있기 때문입니다.
문제 가설을 세울 때 사람들의 행위를 MECE 하게 찾아 들어가보려고 시도해보면, 발생 가능한 사용자 문제를 잘 파악할 수 있습니다.
Issue Tree
Issue tree는 logic tree, hypothesis tree라고 불리기도 하는데, issue tree를 그려본다는 것은 발생 가능한 이슈들을 단계/깊이 별로 적어보는 기법입니다. 나뭇가지 혹은 뿌리가 뻗어나가는 모습처럼 생겼다고 해서 tree라고 명명한 것입니다.
Issue tree를 이해하기 위해서 바바라 민토의 논리의 기술 책을 읽어보면 큰 도움이 됩니다.
위 4가지 개념을 참고하여 User Behavior Tree를 그려봅시다.
User Behavior Tree
구성 설명
1번 영역: 우리 회사 Business Value Chain 중 사용자 접점에 있는 활동을 적습니다.
2번 영역: 우리 제품/서비스를 경험하는 사용자 행위를 발생 순서대로 적습니다. 발생 순서의 시작은 사용자 욕구 존재여부이고, 발생 순서의 끝은 사용자가 하기를 바라는 우리의 goal 입니다. 해당 산업의 보편적인 사용자 행위가 아니라, 우리 제품/서비스를 경험하는 사용자 행위를 적는 것이 중요니다. 주요 활동 위주로 적되, 최대한 MECE 하게 적습니다.
초안 만들기, 주기적으로 업데이트하기
Owner를 정합니다. PO, Product Designer, User Researcher 등 사용자 데이터를 많이 보고 사용자와 대면하는 일이 많은 분이 담당하면 좋습니다.
Businss Value Chain 에서 사용자 접점에 있는 주요 팀의 의견을 수렴하거나 함께 모여 2시간 정도 워크숍을 진행하여 합의된 초안을 빠르게 완성합니다.
주기적으로 업데이트하면서 우리가 예상 못 한 사용자의 주요 행위가 있다면 이를 반영합니다.
User Behavior Tree가 도움이 되는 점
Root cause 가설 시작점을 찾을 때 활용합니다.
사용자가 목적을 달성하지 못하게 막는 장벽이 어디인지, 프로덕트(앱)를 넘어 전사 관점에서 볼 수 있습니다.
문제 해결을 가장 잘할 수 있는 구성원이 문제 해결 과정에 참여합니다.
활용 예
목표: 30대 남성이 좋아하는 상품을 만들고 입점시켰는데, 30대 남성 구매전환율이 떨어지는 원인에 대한 가설 찾기
1. 내부 자료 보기
주요 지표, 프로덕트 퍼널 데이터, 외부 환경 자료, 내부 담당자 인사이트 등 우리가 이미 가진 자료를 살펴보고 Root cause 가설 시작점을 찾습니다. 만일 내부 자료로 알기 어려울 경우 타깃 사용자를 대상으로 정량 설문 조사를 하는 것도 좋습니다.
2. Root cause 가설 시작점과 담당자 결정
만일, '30대 남성은 우리가 만든 상품을 사고 싶은데 우리 앱에서 파는 줄 몰랐다'가 Root cause가설 시작점으로 판단되면, 마케팅 담당자가 문제 해결 과정에 참여합니다.
만일, '30대 남성이 앱에서 상품을 찾긴 했는데 결제하지 않았다'가 Root cause 가설 시작점으로 판단되면, 프로덕트(앱) 담당자, 결제 및 가격 정책 관련 담당자가 문제 해결 과정에 참여합니다.
3. Root cause 확인을 위한 추가 조사 진행
사용자는 상품을 파는 줄 왜 몰랐는지에 대해 내부 마케팅 캠페인을 검토하고 추가 사용자 조사를 진행합니다. 앱에서 상품을 찾았는데 왜 결제까지 이어지지 않았는지 그 사이에 발생 가능한 사용자 행위를 상세화하고(아래 그림 예시), funnel data를 보거나 유저의 실제 사용 행위를 관찰하면서 deep dive 하여 문제 원인을 밝혀냅니다.
물론 모든 문제를 이렇게 접근하지 않아도 됩니다. Scope이 작거나 원인이 매우 명확한 경우는 이렇게 전사 관점에서 문제를 보지 않아도 문제를 잘 해결할 수 있습니다.
우리가 해결해야 할 문제가 전사적으로 중요한 문제일 때, 문제 scope이 클 때, 프로덕트(앱)를 넘어 전사 유관 부서가 얽혀있는 문제라고 직관적으로 생각이 들 때, 어떻게 접근해야 할지 막막할 때... 이 방법을 사용하면 효율적으로 가설 시작점을 찾을 수 있습니다.
