Personas & Jobs-to-Be-Done
고객 목표를 이해하기 가장 좋은 방법을 찾기
Building A Customer Persona
페르소나의 목적은 제품이나 서비스를 이용하는 사용자들을 이해하기 위해 사용되는데 어떤 특정한 상황과 환경 속에서 그들을 어떻게 행동할 것인가에 대한 예측을 실제 사용자 자료를 바탕으로 개성을 부여하여 만들어진다.
우리 제품은 2년이라는 시간 동안 Persona를 만들지 않았다. 실질적인 유저 데이터가 없었기 때문에. 그러나 우리도 이제 회사의 제품을 이용하는 유저들의 질적 자료(qualitative data)와 양적 자료(quantitative data) 데이터가 어느 정도 모인 시점이기 때문에 모두의 동의하에 페르소나를 만들기로 했다. 개발팀 내부에서 어떤 특정하고 지속해서 다양한 대상 사용자 그룹을 이해하고 그들과 공감하며 그들의 요구 사항, 경험, 행동, 목표 등을 이해하는 데에 좋은 방법이기 때문이다.
페르소나 그룹을 정하고 있는 과정각 퍼소나 그룹의 목적은 무엇이며 목표는 어떤 것인지, 또 개인적 사항, 직업적 사항, 기술적 사항을 정하였다. 실제 사용자 유저 그룹을 정하고 난 뒤 각 그룹에서 가지고 있는 문제점을 무엇이고 이것을 어떻게 해결해줄지에 대해서 생각을 하고 어떠한 solution이 그들에게 적합한지 회의를 하였다. 그러나 사실 퍼소나를 다 만들었다고 하여도 어떻게 이 여러 사용자 그룹의 니즈를 다 들어줄 수 있을지에 대해서 고민이 들었다. 그 후 추가적인 시간을 들여 유저 시나리오, 저니 맵, empathy map을 만드는 것은 스타트업에서 사실상 실천하기 어려워 보였다.
새로운 접근법
우리는 퍼소나를 만들어 놓고 무엇이 현재 사용자들에게 적합하고 어떠한 디자인 솔루션이 적합할 것 같은지에 대해서 조금 더 효율적으로 프레임워크를 좁혀나가고 싶었다. 그 이유는 좋은 제품을 만들기 위해서 너무나도 많은 것들이 있는데 어떤 것이 현재 가장 중요하고 그것이 우리 제품이 성장할 수 있는 게 도움을 주는지에 대해서 생각했다.
제품의 새로운 기능을 설계하기 위해 우리 제품의 사용자 연구를 수행할 수 있는 효과적인 방법을 찾고 싶었다. 그 이유는 우리가 사용자와 기능에 관련되어서 테스팅하고 니즈를 파악하려고 할 때 그 니즈가 너무나도 다양하다. 그리고 사실 특정 그룹의 사용자들이 원하는 기능을 구현해도 사실 그들에게는 턱없이 부족한 기능일 수도 있다. 많은 시간과 자원을 투자하여 만들고 나도 실제로 사용자들이 그 기능을 잘 사용하지 않을 때도 있다. Lean 하게 테스팅을 한다고 하여도 테스팅할 때의 반응과 실제 시장에 내놓았을 때의 반응은 또 다르기 때문이다.
우리는 B2C를 한다고 했을 때에 고객의 소리를 듣고 의견을 제품과 서비스에 적극 반영하려고 한다. 물론 이것이 틀린 부분은 없는 말인 것 같다. 그러나 한 명의 고객을 만족시키기 위해 시간과 노력을 쓰는 바람에, 더 많은 고객들을 의 문제점을 해결해주는데 시간이 부족해진다.
더 큰 고객들의 니즈를 해결해주기 위해 새로운 기능을 추가할 때 어떻게 해야지 효과적으로 해결해줄 수 있는지에 대해서 생각하고 있던 도중 닐슨 노만 그룹의 Jobs-to-be-done(JTBD) 프레임 워크라는 글을 읽었다.
고객중심 가치 - 고객은 제품을 고용한다. (JTBD)
JTBD(Jobs-to-Be-Done)는 가상 또는 실제 사용자가 제품을 사용하여 달성하고자 하는 목표를 초점을 맞춘다. 모든 고객들은 각자의 "해결해야 할 일"이 있다. 그래서 이 접근 방식은 사용자가 달성하고자 하는 작업에서 설계 프로세스의 출발점을 설정한다. 고객이 어떤 작업을 통해 제품을 "고용" 할 것인지 묻는다. JTBD 접근 방식은 "우리 사용자들이 진정으로 원하는 것이 무엇인가?"라는 질문으로 시작된다.
User persona와 달리, JTBD에는 프로세스가 구현되어 있지 않다. JTBD을 배울 때 발생할 수 있는 실수에 대해 Alan Klement 는 JTBD가 정해진 프레임워크나 방법이 아니라고 강조했다. "JTBD는 사람들이 제품을 사용하는 방법에 대한 연구가 아니라 그 이유에 대한 연구이다."라고 말했다.
User persona은 정보 자체가 예를 들어 포트폴리오에 넣을 수 있는 프로세스의 결과물이다. JTBD는 제품 및 제품에 대해 다르게 생각하는 데 도움이 되는 이론적인 접근 방식이다.
JTBD의 전형적인 예로는 드릴을 들 수 있다. James라는 30대 중반 남성이 나가서 드릴을 산다. 그는 어떤 것을 성취하기 위해 "고용"하는 것은 무엇일까?
아마도 단순히 드릴 콜렉터/전문가가 아닌 이상 그냥 드릴을 가지고 싶은 것은 아닐 것이다. James가 정말로 원하는 것은 무엇인가?
James는 벽, 테이블 또는 다른 표면의 특정 부분에 특정한 크기의 구멍이 있기를 원한다. 이것이 James의 Jobs to be done이다. 그는 이미 뚫린 구멍을 지불하고자 한다.
대부분의 기업은 기존 제품을 개선하려고 노력함으로써 더 나은 드릴을 만들기 위해 혁신하는 대신 구멍을 만드는 더 나은 방법을 모색함으로써 혁신 프로세스가 크게 개선된다. 제품에 대한 연구를 중단하고 대신 사람들이 하고자 하는 일을 연구하는 것이다. 제품이나 고객, 분석 단위가 아닌 일을 만드는 것을 통해 기업은 예측 가능한 성장을 달성할 수 있다.
Personas vs Jobs-To-Be-Done: 사용 시기와 차이점은 무엇일까?
User persona와 JTBD 둘 다 사용자 중심 설계에서 사용되는 접근 방식이다. 무엇이 가장 효과적인지에 대한 논란이 있다.
그러나 논란이 되어야 할 이유는 없다. 지금 나에게 가장 적합한 것을 사용하면 된다. 이 두 가지 접근 방식이 실제로 어떻게 보이는지 더 잘 이해하기 위해 각각 가상 시나리오를 대입해보았다.
현재 우리는 식단관리 앱을 설계하는 초기 단계에 있다. 지금 초기 또는 중간 프로토타입을 만들어 놓았을 수도 있지만 아직 갈 길이 멀다, 지금 당장은 프로젝트에 참여하는 모든 사람은 최종 결과에 큰 영향을 미칠 수 있다. 컨셉이 있고 그를 실현해줄 팀원들이 있으며, 사용자가 누구인지 충분히 연구하였다.
User Persona로 접근하기.
유저의 니즈를 충족하기 위해서 다양한 우선순위와 관점을 가진 사람들이 이 프로젝트를 같이 진행할 것이다. 팀원들은 비전이 하나로 통합되고 동일하게 생산적인 방향으로 나아가기 위한 노력도 필요할 것이다.
Persona는 이 비전을 하나로 묶을 수 있는 좋은 방법이다. 사용자의 실제 니즈와 목표를 페르소나로 구축함으로써 설계 결정을 내리기 전에 평가하는 데 사용할 수 있는 일련의 잣대를 만들 수 있다.
식사계획 앱을 사용할 가능성이 있는 사람들의 종류에 대한 정보를 수집한 뒤 왜 앱이 필요한지, 부가적인 요소는 어떤 것들이 있는지, 언제 앱을 사용할 것 같은지, 식사 계획에 얼마나 많은 정보를 기록하기를 원하는지 등등 다양한 이유를 찾을 것이다.
여기서 가정과 편견을 넘어 구체성의 역설을 수용하는 것이 좋다. 매우 좁은 청중의 요구에 맞게 설계하면 보다 광범위한 니즈를 충족시킬 수 있다.
페르소나를 통해서 사용자들이 무엇을 생각하고 느끼는지, 그리고 그들의 식단관리 앱에서 무엇을 성취하고 싶은지를 팀원들과 정보를 공유한다. 그 정보를 통해 추가하기로 결정한 기능들에 영향을 미칠 수 있는 구체적인 상황별 세부 정보를 제공한다. 이를 통해 사용자에게 필요할 때 필요한 정보를 적절한 속도로 제공할 수 있다. 또한 이 과정에서 발생하는 문제점들을 밝히고 UI 요소에 영향을 미칠 수 있다.
좋은 점
- 사용자 중심을 유지한다.
- 모든 것을 직시하고 프로세스를 인간화한다.
- 이상적으로 실제 사용자 요구 및 컨텐스트를 나타낸다.
- 공감대를 형성하고 이해 관계자들을 이해한다
- 설계 프로세스 전반에 걸쳐 유용하다. (예: 앱을 미세 조정할 때 문제점을 드러내는 데 도움이 될 수 있다)
좋지 않은 점
- 완전히 관련성이 없는 인구통계학적, 감정적 세부 사항으로 산만해질 수 있다. 식단 관리 앱을 사용하는 사람이 28살이나 42살이라도 상관이 없는가? 그들이 남성, 여성 또는 그사이의 어떤 성 정체성인가? 그들이 서울이나 뉴욕에 산다고? 그들이 결혼했는지, 약 혹했는지 아니면 독신인지? 이런 세부적 사항이 깊어진다.
- 사용자에 대한(또는 팀의) 가정은 사용자가 직접 만든다는 사실에 의해 강화되는 일종의 반향실 효과를 만들 수 있다.
*반향실 효과: 에코 챔버(Echo Chamber)는 방송이나 녹음 시 잔향 감을 주기 위해 인공적으로 메아리를 만들어 내는 방을 의미합니다. 에코 챔버에서 소리를 내면 그 소리가 메아리가 되어 돌아오듯, 인터넷 공간에서 자신과 유사한 생각을 가진 사람들하고만 소통하면서 점차 편향된 사고를 갖는 현상을 에코 챔버 효과라고 합니다.
- 사용자가 적절히 또는 진정으로 포함하지 않을 경우 일부 사용자(능력, 성별 정체성, 문화적 경험 등)를 배제하는 설계 선택사항이 발생할 수 있다.
Jobs-to-Be-Done으로 접근하기
JTBD방식으로 접근하려면 식단관리 앱을 만들기로 결정하기 전으로 간다. 이 작업은 돕고자 하는 사용자부터 시작된다. 현장 학습과 인터뷰를 하거나 그 외에 타깃 사용자가 어떤 것이 필요한지 자료를 수집한다.
이렇게 하면서, 많은 사람들이 그들의 식습관이나 식료품 구입에 얼마나 많은 돈을 쓰는지에 대해 좌절감을 표현한다는 것을 깨닫기 시작한다."어떻게 하면 사람들이 건강에 더 좋은 방법으로 음식을 먹도록 도울 수 있을까요"라는 질문을 던진다. 그리고 식단관리 앱의 아이디어에 도달하게 될 것이다.
식사 계획 앱 아이디어를 가지고 있다가 빠졌을 수도 있다. 전형적인 JTBD 질문을 통해 제대로 진행되었는지 확인할 수 있다: 사용자들이 진정으로 원하는 것은 무엇인가?
그들은 아마도 그들의 휴대폰에 다른 앱만 있는 것을 원하지 않을 것이다. 그들은 이 특정한 기능을 가진 것을 원한다. 하지만 왜 그럴까? 그들은 식료품 목록을 만들기를 원할까? 그럴지도 모른다. 하지만 왜? 그들은 새로운 요리 업을 시도하길 원하나? 도대체 왜 그럴까?
궁극적으로, 그들은 심지어 식단관리 앱도 원하지 않는다. 그들이 진정으로 원하는 것은 식사 계획을 더 잘 세우는 것이며, 이것조차도 특정 사용자(즉, 건강해지기 위해서, 돈을 절약하기 위해서 등)에 의존하는 근본적인 동기를 가지고 있다. 이것을 알면서, 우리는 한 발 물러서서 식단관리 앱이 어떻게 더 나은 식사 계획을 만들 수 있는지 궁금해 할 수 있다.
좋은 점
- 사용자가 누구인지, 어디에 살고 있는지, 삶을 누구와 함께 하고 싶은지, 무엇을 하고 싶은지에 대한 편견이나 반향실 효과를 줄여준다.
- 사용자가 앱으로 목표를 달성할 수 있도록 보장한다.
- 사용자가 원하는 것에 대해 본질적으로 배타적인 가정을 하지 않는 한, 보다 포괄적인 솔루션을 생성할 수 있다.
좋지 않은 점
- 명시적으로 인간성을 부여한 요소(특히 시작적 요소)를 제거한다.
- 여전히 가정하기 쉽다.
- 제품 수명 전반에 걸쳐 덜 유용하다. 단점을 드러내거나 더 작은 특종과 상호작용을 결정하는 데 가장 유용한 접근 방식이 아니기 때문이다.
Persona & JTBD을 혼합하여 접근하기
두 가지는 분명히 다른 접근 방식이다. JTBD가 최종 사용자에 대한 공감의 상실을 초래할 수 있다고 하는
디자이너와 JTBD를 선호하는 디자이너들은 실제 사용자가 정말로 달성하고자 하는 바를 놓치는 아티팩트로 볼 수 있다. 그러나 이 두 가지 접근 방식은 공통적인 목표를 가지고 있다. 즉, 사용자가 실제로 해야 할 일을 할 수 있도록 도와주는 제품을 만드는 것이다. 각 접근 방식의 장단점을 살펴보면 기본적인 호환성이 명확하다.
JTBD는 최종 목표를 명확히 하는데 유용하다. 유저 페르소나는 공감을 형성하고 사용자가 최종 목표를 달성하는 과정에서 주어진 과제를 완수할 때 직면 하는 고충을 발견하는 데 유용하다.
프로세스를 시작할 때 사용자의 요구사항을 살펴보고 사용자가 진정으로 원하는 것이 무엇인지 고려해야 한다. 사용자가 제품을 "고용"하는 데 관심 있는 일에 대해 알아보자. 그 필수적인 "일"이 무엇인지 알아보고 그것은 기능보다는 욕망 수준의 무언가가 될 것이다.
예를 들어, 많은 인터뷰를 하고 나서 수집한 정보를 바탕으로 많은 사람들이 더 건강한 식사를 하고 더 적은 음식을 먹고 싶어 한다는 것을 알아냈다고 하자. 그리고 "어떻게 하면 사람들이 더 건강하고 음식을 덜 소비하도록 도울 수 있을까?"라는 질문을 던지고 나서 그 "일"이 이루어질 수 있는 많은 방법들을 브레인스토밍 한다.
결국, 우리는 "아하! 목록 작성과 레시피 찾기가 통합된 식단관리 앱을 만들면 되는구나." 우리는 해야 할 일을 알고 있고 그 일을 해낼 수 있는 아이디어가 있다. 이제 우리는 완전히 기능적이고, 미적으로 탁월하며, 폭넓은 앱을 설계해야 한다.
유저 퍼소나를 등장시킨다. 일부 잠재 사용자가 사용할 수 없는 앱을 잘못 설계하지 않도록 하기 위하거나 어떤 가정도 설계에 포함시키면, 제품과 관련이 없는 모든 인구통계학적 정보를 없앨 것이다.
프로세스가 끝나면 JTBD로 돌아가 앱을 테스트하여 가능한 많은 사용자가 작업을 완료하는지 확인할 수 있다.
기억하자 JTBD는 최종 목표를 하는 데 유용하며, 페르소나는 공감대를 형성하고 사용자가 최종 목표에 도달하는 과정에서 주어진 과제를 완수할 때 직면하는 고충을 발견하는 데 유용하다.
결국, 양쪽 접근 방식의 양립 가능한 장점을 수용할 수 있다면, 우리가 설계하기로 선택한 제품, 제품의 품질과 가용성, 그리고 그러한 제품을 그들의 삶에서 작동시킬 수 있는 사용자의 범위에 깊고 역동적인 영향을 미칠 수 있다.
참고문헌
https://careerfoundry.com/en/blog/ux-design/personas-vs-jtbd/
https://uxdesign.cc/understanding-customer-needs-though-jobs-to-be-done-part1-5415555e230a
