가설 세우기(1)
Root cause가설, Solution가설
사용자 문제를 해결할 때 우리는 두 과정에서 가설을 세울 수 있습니다.
사용자가 겪는 어려움의 핵심 원인에 대한 가설
솔루션에 대한 가설
이 두 과정에서 각각 어떻게 접근하면 가설을 좀 더 잘 세울 수 있을까요?
우선, 가설이란 무엇인지부터 살펴보겠습니다.
1. 가설(Hypothesis)의 정의
Hypothesis (출처: Oxford press)
1) A hypothesis, in a scientific context, is a testable statement about the relationship between two or more variables or a proposed explanation for some observed phenomenon.
2) A supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.
1)번 정의: 두 개 이상의 변수가 어떤 관계를 가지고 있는지 검증할 수 있는 설명이라는 의미로, 사회/과학 문제 해결 시에 해당하는 가설입니다.
(예: 코로나 바이러스는 호흡기로 감염될 것이다)
2)번 정의: 한정된 근거에 기반하여 제안하는 설명이라는 의미로 추가 조사를 위한 시작점이 됩니다, 비즈니스 문제 해결 시에 해당하는 가설입니다.
(예: 상반기 분기 매출이 감소한 이유는 지난해 원자재 비용이 상승했기 때문이다)
사용자 문제를 해결할 때 가설은 1), 2) 개념을 다음과 같이 구분하여 생각하는 것이 좋습니다.
사람들이 겪는 어려움과 원인에 대한 가설을 세울 때는 2)번 개념: 추가 조사를 위한 시작점
솔루션에 대한 가설을 세울 때는 1)번 개념: 솔루션-문제 간의 관계 검증
2. Root cause 가설
추가 조사를 위한 시작점
제품/서비스를 경험하며 사용자가 겪고 있는 문제 원인에 대한 가설을 세운다는 것은, 원인에 대한 임시적인 답을 예상해 보는 개념입니다. A/B테스트 등을 진행하기 위해 구체적인 변수를 정하고 실험을 설계하는 것과는 다릅니다. 엄밀히 말하면 '가설'이라기보다는 가정, 추측, educated guess 정도로 표현하는 것이 맞겠으나 비즈니스 문제 해결 시에도 '가설'로 통용하므로 가설이라고 불러도 무방하다고 생각됩니다.
사용자가 겪고 있는 문제 원인에 대한 가설을 세우는 것은 어려울 뿐 아니라 매우 막막합니다. 왜냐하면 '우리 제품/서비스를 사용자는 어떻게 행동할 것이다'에 대한 보편적인 이론이나 패턴이 없기 때문입니다. 그렇다고 사용자 행동을 망라해서 보다 보면 시간과 비용이 너무 많이 소비됩니다.
따라서 우선 '추가 조사를 위한 시작점'을 잘 찾아보는 것이 필요합니다.
가설 시작점 찾기: User behavior tree를 그려보기
비즈니스 문제를 분석할 때, 비즈니스 구조 상 발생가능한 이슈를 MECE 하게 구조화하는 작업을 진행합니다. 이를 차용하여 우리 제품/서비스를 경험하며 발생가능한 user behavior를 구조화합니다. 특정 문제가 발생하기 전에, 관련 구성원들이 정기적으로 모여 새롭게 발견한 user behavior를 업데이트하면서, 우리 회사만의 user behavior tree를 만들어보세요.
(User behavior tree는 가설세우기(2) 글에 설명을 적었습니다)
가설 확정하기: 사용자 이야기를 들어보고 행동을 관찰하기
User behavior tree에서 우리가 deep dive 할 시작점을 찾으면 이제 사용자의 이야기를 듣고 행동을 관찰하며 root cause를 확정합니다. 검증이 아닌 확정이라고 표현한 이유는, 궁극적으로 우리가 검증해야 할 것은 솔루션에 대한 가설이기 때문입니다.
3. 솔루션 가설
솔루션-문제 간의 상관관계 검증
Root cause를 발견했으면 솔루션 아이디어를 내고 가설로 만들어 검증합니다.
아이디어 내기: Ideation을 위한 질문을 만들기, 아이디어 내기, 아이디어 평가하기
이 단계는 일반적인 ideation 단계와 동일하게 진행합니다. Ideation 단계에서 가장 먼저 해야 할 것은 "일단 모여서 아이디어를 내보자"가 아니라, "Ideation을 할 질문(How might we questions)을 만들어보자"입니다. 일단 아이디어를 낼 때에는 최대한 많이 내본 후, 내부 의사결정 기준에 따라 아이디어를 평가합니다.
아이디어를 가설화 하기: 구체적으로, 변인 통제할 수 있도록, 테스트할 수 있도록
아이디어를 검증하기 위해서 구체적인 가설문(statement), 즉, 두 개 이상의 변수가 어떤 관계를 가지고 있는지 검증할 수 있는 설명을 만듭니다.
[가설 예] 장바구니에 넣어둔 상품과 관련된 쿠폰 알람을 주면, 장바구니 상품 구매 전환율이 증가할 것이다.
검증하고 싶은 관계: 쿠폰 알람과 장바구니 상품 구매 전환율 간 양의 상관관계가 있는지 없는지
변인 통제: 쿠폰 알람 이외 다른 변화는 통제함
솔루션 가설 검증하기: 프로덕트 개발 단계와 팀이 보유한 리소스에 따라 다양하게 만들어 검증 가능
솔루션 가설은 prototype을 다양한 방법으로 만들어 검증할 수 있습니다. 프로덕트 개발 단계와 우리 팀이 보유한 기획/디자인/개발 리소스에 따라 최적의 방법을 선택하면 됩니다.
기획 초기 단계에는 종이에 그린 스케치를 보여주는 것도 좋고, 디자이너가 사용자와 함께 co-creation workshop을 진행하며 그 자리에서 피드백을 바로 반영하면서 솔루션을 만들어갈 수도 있습니다. 디자인이 어느 정도 구체화된 단계에서는 사용자가 working prototype을 사용하게 하며 피드백을 받을 수 있습니다. 이처럼 소수 유저에게 정성 테스트를 진행하는 경우, 유저 행동의 원인까지 파악할 수 있는 장점이 있지만 모수가 적기 때문에 가설 채택 여부는 팀의 판단으로 결정해야 하는 어려움이 있습니다.
개선할 요소가 적거나, 개발하여 실제 프로덕트에 반영할 리소스가 있는 경우 A/B test를 진행하면 실제 유저 행위를 정량적으로 정확히 파악할 수 있기 때문에 가설 검증이 쉽습니다. 다만 사용자가 그렇게 행동한 원인은 알기 어렵다는 한계가 있습니다.
위 내용을 지난 번 글의 문제정의 단계에 적용하여 정리해 보면 다음과 같습니다.
Root cause 가설: 망라한 접근
추가 조사를 위한 시작점을 찾는다. (User behavior tree)
팀 내에서 가설을 정한다.
사용자 이야기를 듣고 가설을 확정합니다.
Solution 가설: 변수 간 관계를 검증하는 접근
Root cause를 없앨 수 있는 아이디어를 낸다.
아이디어를 가설화하고 구현한다.
사용자에게 사용하게 하고 가설을 확정한다.
Solution 가설을 검증해 본 결과 가설이 기각될 경우, 다른 해결안을 테스트해 보거나 Root cause를 다시 살펴봅니다. 해당 가설로 사용자 문제가 해결되지 않았다면 이를 반복합니다. 그래도 사용자 문제가 해결되지 않았다면 더 앞으로 가서 우리가 사용자 어려움 자체를 잘못 파악한 것은 아닌지 검토합니다.
가설이 기각된 것은 잘못한 것이 아닙니다. 가설을 기각해 가면서 사용자의 문제를 해결해 가는 과정 자체가 이미 잘하고 있는 것입니다.
