안녕하세요, 성과관리 서비스를 만드는 레몬베이스에서 프로덕트 디자이너로 일하고 있는 Redi입니다. 레몬베이스의 제품팀은 목적 조직 체제인 스쿼드로 일하고 있고요, 제가 속한 <웨이브 스쿼드>에서는 시장에 새로운 제품을 선보이기 위한 준비 중에 있습니다.

저는 고객의 진짜 문제를 이해하고 해결하려면 고객을 직접 만나보고 이야기를 듣는 것이 중요하다고 생각하는데요. 이를 위해 레몬베이스라는 SaaS 기업에서 새로운 제품을 준비하는 제품팀이 유저 리서치를 어떻게 하였는지 글로 정리해보려고 합니다. 🙂

이 글은 아래 내용을 모두 담고 있지만, 글의 길이가 너무 길어져 1~2는 1편, 3~4는 2편으로 나누어 작성하였습니다.

1. 리서치 방법론의 종류
2. 목적별 리서치 방법의 차이
3. 리서치의 필요성에 대해 구성원을 설득하는 방법
4. 유저 리서치 과정에서 어려웠던 점과 배운 점

더불어 이 글은 이런 분들이 도움받으셨으면 하는 마음으로 작성했어요.

• B2B SaaS를 만드는 규모가 작은 팀에서는 정성적 데이터를 어떻게 다루는지 궁금한 분
• 조직 규모가 커졌는데도 데이터 중요성을 제대로 모르거나, 환경이 갖춰지지 않은 곳에서 일하고 있는 분
• 마지막으로 레몬베이스 팀에 관심이 있는 잠재 지원자입니다. (네, 이런 고민을 같이 할 디자이너를 찾고 있어요!)

저희 스쿼드가 주도한 이번 가치 검증 과정에서 가장 큰 도움과 영향을 준 사람은 레몬베이스의 디자인 챕터에서 함께 일하는 프로덕트 디자이너 Dayle이었습니다. Dayle은 팀에 합류하기 전에 UX 컨설턴시에서 유저 리서치 업무를 오래 해왔어요. 그래서 이런 전문성을 활용하여 어떤 방법들을 통해 고객을 만나야 하는지, 어떤 질문을 던져야 하는지 잘 알고 있었죠. 그런 Dayle로부터 유저 리서치에 대한 다양한 방법론과 실제 경험을 직접 들을 수 있었습니다. 그럼, 본격적으로 시작해보겠습니다! 

잘 알려졌듯이, 제품을 만들면서 검증해야 할 것들은 다음과 같습니다.

• 문제 정의: 사용자가 겪고있는 어려움, 즉 해결해야할 문제는 무엇인가
• 유용성(Utility): 사용자가 원하는 것을 제공하는가
• 사용성(Usability): 사용자가 쉽게 사용할 수 있는가

각각을 검증하기 위해 일반적으로 수행하는 일들, 그리고 People Development SaaS를 만드는 레몬베이스팀은 어떤 일들을 하고 있는지는 다음과 같아요.

대부분의 팀과 마찬가지로 레몬베이스 팀도 문제 정의 단계에서는 심층 인터뷰 (In-depth Interview)를 주로 하고 있습니다. 문제를 가진 것으로 예상되는 고객을 리쿠르팅하여 고객이 겪고 있는 상황을 선명하게 그릴 수 있을 때까지 다양한 것들을 질문해요.

People Development 분야에도 서로 다른 맥락을 가진 많은 사용자가 있기 때문에, 인터뷰 대상은 우리가 파악해야 할 문제에 따라 시시때때로 바뀌게 되는데요. 레몬베이스 제품을 가장 많이 사용하는 고객 세그먼트인 ‘인사담당자’분들만 해도 다양한 퍼소나가 있어요. 평가와 보상 업무를 맡고 계시는 분, 회사의 문화를 만들어 나가는 컬쳐 업무를 맡고 계시는 분 등 인사 분야에 따라 제품에 요구하는 내용도 천차만별이죠.

이러한 고객의 맥락을 선명하게 파악하기 위해 문제를 겪을 것으로 예상되는 고객을 적어도 9명 이상 인터뷰합니다. 어떤 어려움을 겪고 있을지에 대해 가설을 세우고 인터뷰를 시작하는데, 인터뷰를 통해 새로운 사실을 알게 되면 가설을 수정해요. 이런 식으로 가설을 수정해나가면서 인터뷰를 진행하다 보면 9명 정도를 만났을 때 어느 정도 문제가 선명해집니다.

이런 과정을 통해 알게 된 문제가 실제로 많은 고객이 겪고 있는 문제인지를 검증하기 위해, 서베이나 스모크 테스트를 시도할 때도 있습니다. 어떤 방법이든 문제의 선명도와 정확도를 높여줄 적합한 방법을 상황에 맞게 선택하고 있어요.

❓ 정량적인 데이터로부터 문제를 정의하지는 않나요? 

많은 조직들이 정량적 데이터 분석 위주로 제품의 pain point를 찾아내고 문제를 정의하고 있습니다. 하지만 레몬베이스팀은 다음과 같은 이유로 정성적인 데이터 분석의 비중을 높게 가져가고 있어요. 

1️⃣HR SaaS의 특성상 정량적인 데이터에 바이어스가 있을 수 있습니다. 

레몬베이스의 사용자들 중 퍼널 상에서 Task를 완수하지 못하는 사용자들은 없습니다. 리뷰/평가/목표 관리는 반드시 해야하는 업무이고, 한 사람도 빠짐없이 완수하게 하기 위해 인사팀에서 많은 공을 들이고 있어요. 

퍼널 상 특정 지점에서 이탈한다던가 task를 완수하지 못하는 패턴을 발견하기 어려우므로 그러한 분석을 통해 Pain Point를 찾기란 쉽지 않아요. 따라서 In-depth Interview, Usability Testing 등을 통해 정성적인 데이터를 수집한 후 Pain Point를 찾는 편입니다. 

물론 정량적 데이터 분석에 퍼널 분석과 같은 방법만 있는 것은 아니므로, 우리에게 적합한 정량적 데이터 분석 방법을 찾기 위해 노력하고 있어요. 특정 단계에 머무는 체류 시간이나 task 완수까지 설계된 User Path를 벗어나 얼마나 많이 헤매는지 관찰하는 등 사용자가 불편을 느끼는 지점을 데이터 상에서 밝혀내기 위한 방법을 모색하고 있습니다. 

2️⃣제품 구매자의 니즈가 뚜렷합니다. 

레몬베이스는 제품 사용자와 구매자가 다른 서비스입니다. 주로 고객사의 인사팀이나 경영진에서 구매를 결정하고, 고객사의 구성원들이 제품을 사용하게 되죠. (구매자가 사용자의 입장에서 제품을 쓰기도 하지만, 구매와 사용의 니즈가 서로 다르므로 일단 구분하여 적습니다). 

이때 구매자의 니즈는 비교적 뚜렷합니다. 원하는 요건이 충족되었는가를 기준으로 구매를 결정하며, 이 요건은 구매자로부터 직접 듣는 것이 가장 빠릅니다. 이러한 니즈는 세일즈 단계에서 VOC로 수집되며 제품에 반영되어요. 

물론 당장은 구매자의 니즈에 맞춰 제품을 팔 수 있더라도, 제품을 실제로 사용하는 사용자를 충족시키지 못하면 재구매로 이어지기 어렵기 때문에 사용자의 VOC 수집과 분석도 놓치지 않고 있습니다. 하지만 아직까지는 정량적 데이터로부터 이러한 맥락을 파악하는 것보다 정성적으로 파악하는 것이 ROI가 높으므로 정성적인 데이터 분석의 비중을 높게 가져가고 있어요.

문제가 정의되어 해결해야 할 문제가 명확해지면, 문제를 해결하는 방법이 적절한지도 검증해야 하는데요. 문제 정의 단계에서 유용성까지 같이 검증되기도 하지만, 여기서는 솔루션에 대한 검증으로 좁혀서 이야기해볼게요.

레몬베이스 팀에서는 유용성 검증을 위해, 고객에게 프로토타입을 보여주고 피드백을 받고 있습니다. 이때 신경 쓰는 것은 프로토타입 피드백 세션을 Usability Testing 하듯 진행하지 않는 것인데요. 이 시점에서는 프로토타입의 사용성이 얼마나 좋고 편한지 검증하려 하지 않습니다. 대신 팀에서 생각한 아이디어가 고객의 문제를 해결하는 데 얼마나 유용한지 검증하는 것에 집중하는 것이 중요해요.

더불어 프로토타입은 우리의 아이디어를 고객이 가장 이해하기 쉬운 형태로 정리한 것일 뿐 실제 솔루션은 얼마든지 달라질 수 있다는 자세로 임합니다. 고객이 프로토타입을 보고 ‘좋다’라는 의견을 주었다면 왜 좋은지, ‘어렵다’거나 ‘불편하다’는 의견을 주었다면 왜 그런지 그 이면의 니즈를 파악하려 해요. 프로토타입은 그 니즈를 더 잘 끌어내게 해주는 도구일 뿐, 솔루션 그 자체는 아니기에 프로토타입 자체에 집착하지 않으려 하는 거죠. 이렇게 프로토타입이 나타내는 아이디어의 본질과 그에 대한 고객의 반응, 그 이면의 니즈를 아는 것이 가장 중요합니다.

이 단계를 지나면서 아이디어는 좀 더 선명해지고, 해결해야 할 문제도 더 잘게 쪼개지며 사용자가 필요로 하는 것이 무엇인지에 대해서도 더 잘 이해할 수 있게 됩니다.

유용성 검증을 통해 아이디어가 선명해지면 이를 실제로 사용할 수 있는 형태의 제품으로 다듬습니다. 사용하는 데 불편함은 없는지, 우리가 놓치고 있는 케이스는 없는지, 예상되는 문제는 없는지 되도록 제품 릴리즈 전에 파악하려 노력합니다.

이 단계에서 특별할 것은 없습니다. 워킹 프로토타입을 제작해서 고객이 직접 사용해보게 한 후 행동을 관찰하기도 하고, 테스트 서버에서 바로 사용해보게 하기도 합니다. 일반적으로 행하는 Usability Testing과 다를 것 없이 진행하며 사용상 어려움이나 불편함은 없는지, 배포 전에 다듬어야 할 부분은 무엇인지 확인합니다.

위에서 이야기한 것과 같이 유저 리서치는 목적에 따른 다양한 방법론이 있는데요. 그렇기 때문에 각 스쿼드에서 일을 진행할 때 각 목적에 맞는 적합한 유저 리서치 방법을 다르게 선택하는 것이 중요합니다. 보통 스타트업에서 유저 리서치 목적의 예시는 대표적으로 아래 2가지예요.

1. 새로운 시장에서의 MVP를 출시할 때 적합한 문제 정의/유용성 검증
2. PMF를 찾은 후 본격적인 기능별 디테일한 사용성 검증

Dayle이 현재 소속되어 있는 <원골 스쿼드>는 ‘목표 제품’을 만드는 스쿼드인데요. 목표 제품은 이제 막 제품을 도입하려는 고객들, 도입해보려고 했는데 잘 랜딩되지 않는 고객들 등 다양한 상황이 많았다고 합니다. 이때의 문제는 ‘우리의 고객은 구체적으로 어떤 것이 문제인지를 모르는 경우가 많다’는 것입니다.

그래서 Dayle은 고객의 실제 경험(상황, 불편함, 어려움, 필요한 것 등)을 듣는 것이 중요하다고 판단했고, ‘문제 정의를 위한 고객 경험 인터뷰’를 진행했습니다. 인터뷰를 진행하다 보면 문제가 되는 실제 상황들을 구체적으로 잘 이야기해주는 고객들이 있는가 하면, 문제 자체를 몰라서 이야기하기가 어려운 분들도 있었다고 해요.

이와 같은 상황에서 고객 경험 인터뷰를 진행할 때 Dayle이 강조해서 알려준 내용이 있었습니다.

• 인터뷰의 목적을 다시 상기하는 것. 새로운 사실을 알아냈는가? 이 인터뷰를 끝나면 인터뷰이가 해당 상황에서 어떤 행동을 했는지 머릿속에 다 그려져야 한다. 인터뷰이의 상황이 연결되지 않은 상태로 인터뷰를 끝내면 안 된다.
  
  
• 고객은 자신이 뭘 원하는지, 미래에 어떻게 하면 될지 대부분 잘 모른다. 고객분들이 ‘이 기능이 필요해요.’ ‘이런 게 됐으면 좋겠어요. 이런 게 문제예요’라고 말해주신 내용 이면의 ‘실제 문제였던 상황’을 더 구체적으로 살피는 것이 중요하다.
  
  
• 그러니 고객에게 그걸 알아낼 만큼 우리가 많이 알고 있어야 한다. 
  
  
• 먼저 큰 맥락의 상황에 대해 물어보고 이후 ‘구체적인’ 질문을 통해 사용자의 이야기를 집요하게 끌어낸다.
  
  
• 사용자가 질문에 곧바로 답변할 수 있도록 명료한 질문을 작성한다.
  
  
• 최대한 대화하는 형식의 답변하기 쉬운 질문들로만 구성해야 한다.
  
  
• 우리가 먼저 더 많이 말하는 것보다 상대방이 훨씬 더 많이 이야기할 수 있도록 대화를 이끌어가야 한다. 먼저 개입하지 않고 답변을 천천히 기다릴 것.

• 인터뷰의 목적을 다시 상기하는 것. 새로운 사실을 알아냈는가? 이 인터뷰를 끝나면 인터뷰이가 해당 상황에서 어떤 행동을 했는지 머릿속에 다 그려져야 한다. 인터뷰이의 상황이 연결되지 않은 상태로 인터뷰를 끝내면 안 된다.
  
  
• 고객은 자신이 뭘 원하는지, 미래에 어떻게 하면 될지 대부분 잘 모른다. 고객분들이 ‘이 기능이 필요해요.’ ‘이런 게 됐으면 좋겠어요. 이런 게 문제예요’라고 말해주신 내용 이면의 ‘실제 문제였던 상황’을 더 구체적으로 살피는 것이 중요하다.
  
  
• 그러니 고객에게 그걸 알아낼 만큼 우리가 많이 알고 있어야 한다. 
  
  
• 먼저 큰 맥락의 상황에 대해 물어보고 이후 ‘구체적인’ 질문을 통해 사용자의 이야기를 집요하게 끌어낸다.
  
  
• 사용자가 질문에 곧바로 답변할 수 있도록 명료한 질문을 작성한다.
  
  
• 최대한 대화하는 형식의 답변하기 쉬운 질문들로만 구성해야 한다.
  
  
• 우리가 먼저 더 많이 말하는 것보다 상대방이 훨씬 더 많이 이야기할 수 있도록 대화를 이끌어가야 한다. 먼저 개입하지 않고 답변을 천천히 기다릴 것.

제가 속한 <웨이브 스쿼드>에서는 준비하고 있는 제품의 MVP 문제 정의 검증을 위해 인터뷰 리쿠르팅 및 어레인지부터 질문 세팅과 분석까지 스쿼드 구성원들이 주도하여 진행했습니다. 이 과정에서 Dayle에게 자문과 피드백을 구하며 많은 소통을 하였어요.

우선 리쿠르팅을 위해 인터뷰 대상자의 예상 프로필을 작성해보고 그 기준에 해당되는 기업들에게 Product Owner와 Product Designer가 직접 이메일을 보내며 컨택했는데요. 보통은 기업에 직접 컨택하는 것은 비즈니스팀에서 하는 것이 일반적인 경우인데, 제품팀에서 직접 컨택을 한 것이 수락률에도 긍정적인 영향을 미쳤다고 생각해요. 그렇게 인터뷰가 어레인지되면, 프로토타입을 통해 직접 제품을 시연하면서 피드백을 수렴했습니다. 이 과정에서 MVP의 방향성뿐만 아니라 MVP 이후의 로드맵에 대한 아이디어도 얻을 수 있었어요.

Dayle이 이전에 속하여 일했던 <리뷰 스쿼드>에서는 주로 ‘프로토타입을 활용한 사용성 검증’을 진행했습니다. 리뷰 스쿼드에서는 비교적 해결해야 할 문제가 명확한 단계, 즉 PMF를 어느 정도 찾은 상태였기 때문에 하나의 큰 기능이 출시될 때 사용성 위주의 검증이 필요했죠.

한편 디자인 솔루션도 가설이기 때문에 최적의 솔루션에 대한 의사결정을 할 때 스쿼드 구성원 간 의견 조율이 어려울 때가 있습니다. B2C 분야의 제품은 빠르게 기능을 선보인 후 고객 반응을 보고 빠르게 개선할 수 있지만, B2B는 B2C만큼 고객 모수가 많지 않기 때문에 바로 반응을 보기 어려운 상황이죠. 또한 매번 기능을 출시할 때마다 고객 인터뷰를 어레인지하기도 현실적으로 어렵습니다.

그때 Dayle이 새롭게 알아보고 제안한 방법론은 ‘UT(Usability Test) 툴인 Maze를 활용해 내부 구성원 대상으로 한 사용성 검증’이었어요. Maze는 대상자를 설정하고 UT를 발행하면 대상자들이 오퍼레이터 없이 스스로 UT에 참여할 수 있는 기능을 제공합니다. 덕분에 내부 구성원을 대상으로 하여 빠르게 여러 사용자 반응을 살필 수 있었어요.

Maze는 새로운 기능을 런칭하기 전에 내부 구성원 대상으로 사용자 반응을 살펴볼 수 있고, 가설을 빠르게 미리 검증할 수 있는 효과적인 방법이라고 생각합니다. 실제로 Maze 툴을 활용하여 고객 인터뷰에서 프로토타입을 직접 만들어 원골 조직 구조 변경 사용성을 검증하기도 했고, 웨이브 스쿼드에서 어드민 권한 세분화를 내놓기 전에 내부 구성원들을 대상으로 UT를 진행하기도 했습니다.

Maze 툴을 활용해 사용성을 검증했을 때 큰 효용이 있었다고 생각해요. 실제로 런칭하고 난 다음에 사용성에 대한 VOC도 거의 없었고, Hotjar를 통해 사용 패턴을 확인할 때도 UT를 진행했을 때의 사용 패턴 그대로 나오기도 했기 때문입니다. B2B 프로덕트 디자이너로서 내가 도출한 디자인 솔루션에 대한 확신도 생겼고요.

이어지는 2편에서는

스쿼드 구성원들이 모두 한 마음으로 리서치를 진행하도록 만들기 위해 그들을 어떻게 설득했는지부터, 유저 리서치 과정에서의 회고 및 결과를 얘기해보겠습니다 😃

🔗 B2B 프로덕트 디자이너가 고객을 만나는 법 2편 보러가기