디자이너의 JOBS-TO-BE-DONE 프레임워크
미국에서 열심히 살아가는 프로덕트 디자이너의 생존기 시리즈
인트로
최근에 팀에서 진행하는 꽤 큰 프로젝트가 있다. 사실 저번 half (*half는 반기, 6개월을 뜻함) 때부터 이어져 온 것이지만 그 당시엔 디자인 팀만이 북극성 (North Star Vision)을 바라보며 제품의 이상적인 그림을 그린 것에 불과했다. 하지만 이번 half 땐 그 비전이 XFN (Cross Functional) 파트너들 (i.e PM, Engineering) 에게 전달돼 팀과 제품의 한 방향 (direction)이 되어버렸다 (이 프로젝트를 리드한 나의 매니저의 매니저가 대단하고 참 많이 배웠다). 정확히 어떤 제품의 무슨 프로젝트라고 아직 말할 순 없지만 대충 설명하자면, 거대한 플랫폼 안에 듬성듬성 숨어있던 우리의 제품이 당당하게 글로벌한 네비게이션 중 하나의 자리로 들어갈 수 도 있는 아주 야망적인 프로젝트다. 따라서 팀원 거의 모두가 이번 half 그리고 다음 half 때까지 아마 이 프로젝트에 매진하게 될 것 같다.
이처럼 굉장히 많은 가능성이 있는 아이디어와 모든 걸 책임지는 플랫폼팀과의 적절한 이해관계 속에서 힘차게 프로젝트를 진행하게 됐지만 덩치가 커지면 커질수록, 생각보다 어려운 점들이 많이 존재하는 것 같다. 수많은 다른 팀들과의 커뮤니케이션도 그중 하나지만, 팀원들이 (특히 디자인 팀이) 레퍼런스 할 수 있는 하나의 대표적인 프로젝트 문서가 없는 것이었다. 딱히 어떤 특정 "문서 (document)"라는 것이 없다고 하기보단 명확한 problem statement, user stories 등이 잘 정리돼있지 않았다. 왜 이 프로젝트를 하는지에 대해서, 그리고 사용자들에 대한 리서치 등 여러 정보들은 진짜 폴더 안에 쌓이고 쌓였다. 게다가 저번 half부터 여기까지 오면서 수많은 문서와 디자인 관련 파일들을 만들어낸 우리지만, 폴더 안의 파일들은 늘어만 갔고 파일끼리 링크를 거는 방식을 통해 엮고 엮으려고 노력하기만 했다.
따라서 언젠가부터 우리는 암묵적으로 모두가 (심지어 새로운 팀원들도) 쉽게 이해하기 쉬운 하나의 문서를 만들려고 노력했다. 분명, 다른 팀에서 우리가 진행하고 있는 프로젝트에 대해 궁금해하면 간결하고 명확하게 설명하고 논쟁을 펼칠 수 있을수도 있다. 더 나아가, 우리에게 어떻게 보면 이미 진행하고 있는 프로젝트였지만, 지금까지 엔지니어들이 주도적으로 수많은 UI Experiment (작은 실험들을 통해 가설들을 증명하는 data-informed process) 들을 난무하고 있었고 어떻게 보면 end-to-end 경험이 어떤 그림일까에 대한 생각은 디자인팀이 스스로 생각해야만 답이 나올 것 같은 느낌이었다.
그중, 우리 눈에 들어온 것은 Jobs-to-be-done (JTBD) Framework란 것이었다.
JTBD가 뭐지? 공부해보자.
사실 아직까지도 JTBD에 대해 정확히 알지 못하며 어떻게 적용해야 하는지 100% 알지 못한다. 그저, 다른 팀에서 UX Researcher가 발표하고 팀원들끼리 얘기하고 인터넷에서 찾은 것 만으로 이해하려고 노력했다. 그리고 얼마 전 까지만 해도 팀원들끼리 JTBD에 대해 대화를 했을 땐 아무것도 몰랐기 때문에 자리에 돌아와 혼자 더 알아봐야겠다고 다짐했다. 그래서 유투브나 구글로 검색해 최대한 다양한 사람들이 올린 영상과 글들을 보며 감을 잡으려고 노력했고 배운 것을 토대로 어떻게 우리가 진행하는 프로젝트에 적용해 볼까도 많이 고민하고 연구해봤다. 더 나아가, 혼자 연습 삼아 내가 보고 듣고 배우고 느낀 점을 토대로 내가 생각한 방향의 JTBD를 작성해보고 팀원에게 공유하면 좋겠다고 생각했다.
Jobs-to-be-Done (JTBD)은 디자인을 좀 더 효율적으로 할 수 있게 만드는 하나의 프레임워크 (framework)이다. JTBD는 현재 사용자나 포텐셜 (potential) 사용자들의 동기 부여, 이유 그리고 상황에 좀 더 기반을 두며 "무엇" 보다는 "왜"라는 것에 더 주의 깊게 알아보는 것이라고 한다 ("Putting the Why Before the What"). 내 매니저의 말로는 결국 사용자들을 더 파헤치면 파헤칠수록 우리가 더 적합한 solution에 다가갈 수 있게 해주는 역할을 한다고 했다.
일단, 구글 검색을 통해 찾은 건, JTBD은 1990년도쯤에 비즈니스 스쿨에서 많이 인용되던 이론이며 Clayton Christensen이란 교수가 The Innovator’s Solution 이란 책에 2003년도에 더 설명하면서 더 널리 퍼뜨려졌다고 한다. 그 후, 비즈니스를 공부한 사람들 뿐만 아니라 Product Designer들과 같은 디지털 제품에서 일하는 사용자에 기반을 둔 프로페셔널들이 사용하기 시작했다고 한다.
밀크 쉐이크 판매를 늘리는 법 (Improving Milkshake Sales)
기억을 더듬어 보니, 나랑 같이 일하는 Content Strategist가 JTBD과 관련하여 예전에 공유해준 영상이 하나 있는 것을 알게 됐다. 그땐 JTBD이 뭔지도 어떻게 활용할지도 모르는 상태였지만, 지금은 팀이 JTBD을 좀 더 적극적으로 활용하고 싶어 하는 것이 보였고 유투브 검색을 하는 도중 익숙한 썸네일이 있어서 클릭하고 보고 있자니 기억이 났다.
이 영상은, Clayton Christensen 교수와 그 팀이 맥도날드의 밀크쉐이크 판매량을 어떻게 하면 늘릴 수 있을까에 대한 연구를 의뢰받은 것에 대해 설명을 하기 시작한다. 처음에 맥도널드에서는 고객들을 상대로 스스로가 생각하는 이상적인 밀크쉐이크에 대해 물어보기 시작했다. 예를 들어, 묵직하고 두꺼운 밀크쉐이크가 가벼운 것보다 나은지, 초코 맛이나 과일 맛이 더 좋을지 같은 것 말이다. 그리고 피드백들을 토대로 새로운 밀크쉐이크들을 만들었지만 판매량은 느는 모습을 보이지 않았다고 한다.
따라서 Clayton과 그의 팀은 맥도날드에 들락날락하는 고객들을 조금 더 유심히 지켜보기로 결정했다. 고객들이 "왜" 밀크쉐이크를 사고 싶어 하고 어떤 음식과 같이 먹는지, 누구랑 있는지 등 여러 가지 정보를 수집하게 된다. 놀라운 것은, 밀크셰이크를 산 대부분의 고객들이 아침 8:30분 경에 샀다는 것이다. 그리고 인터뷰를 통해 알아낸 것은, 그 고객들이 긴 시간을 운전해 회사로 출근하는 경우였다고 한다. 출근 시간이 길고 지루하다 보니, 배가 고프기도 하면서 지저분할 여지가 없고 한 손은 그대로 자유인 밀크쉐이크가 적절하다는 것을 알게 된다.
맥도날드는 그 후, 더 든든하고 심지어 과일 몇 조각까지 들어있는 밀크쉐이크를 만들려고 노력하면서도 무엇보다 더 긴 시간 동안 밀크쉐이크가 맛있을 수 있는 방법을 더 연구해서 개발하는데 노력했다. 그리고 그 결과는 판매량과 매출액 증가로 이어졌다. 그렇다면, 밀크쉐이크의 정확한 job은 뭐였을까? 바로, 고객들의 출근길을 더 즐겁거나 혹은 덜 심심하게 만들어준 데에 기여한 것이다.
이처럼, "어떤(what)" 맛있는, 더 창의적인 밀크쉐이크를 만들어낼까 라고 고민하는 것보다, 도대체 "왜(why)" 사람들이 밀크쉐이크를 사는 것일까에 더 중점을 둔 결과는 매우 성공적이었다고 한다. JTBD 프레임워크에 나와있듯이 "왜 고객은 우리의 제품을 hire 하는가"에 대해 잘 생각해보고 때론 "왜 다른 비슷한 제품들 말고 우리의 제품을 사용할까"라는 질문도 우리만의 제품에 대한 강점을 더 잘 이해할 수 있는 방법이라고도 한다.
JTBD Framework의 중요한 요소들
수많은 Job들 중, 제일 높은 레벨의 Job들을 찾아낸다
그 Job들을 해결할 수 있는 더 작은 Job들을 찾아서 정리한다
현재 사용자들이 어떻게 문제를 해결하는지 연구한다
User Research나 Data Analysis를 통해 사용자들의 동기 부여, 이유 등을 탐색한다
Job Stories들을 만들어서 그들의 상황 (situation), 동기 부여 (motivation) 그리고 원하는 결과 (outcome)를 알아낸다
정리한 Job Stories에 대한 솔루션들을 만들어낸다 (feature or UI change)
Job Stories
인터넷을 뒤져보면, 상당히 다양한 JTBD에 대한 해석과 방법을 공부해 볼 수 있다. 그중에 내가 공감 갔던 방법은 Job Stories라고 이렇게 [When __] [I want to __] [So I can __]을 사용자의 입장에서 써보는 것이었다. 분명, 사용자들과 제품에 대한 이해가 곁들여져야만이 유익한 문장들이 완성될 테지만, 개인적으로 제품의 사용자 Journey Map의 중요 터치 포인트마다 어느 정도 써 내려가다 보니 생각보다 많은 도움이 됐다.
내가 작성한 몇 가지는 이렇다.
"When I'm filling out the settings for my test, I want to know where I should pay close attention to (i.e recommendation, error, warning) so I can be confident about my setup"
"광고에 대한 테스트를 위해 세팅 값들을 넣을 때 (situation), 나는 사용자로써 화면이나 인터페이스를 통틀어 어디에 더 자세히 집중해야 하는지 알고싶다 (motivation). 그 이유는, 내가 정한 세팅 값들에 대해 좀 더 자신감을 가지고 광고를 진행할 수 있기 때문이다 (expected outcome)"
“When I see that my campaign is not performing well, I want to know if there are any recommendations for me so I can actively try out different ways to improve my performance”
"나의 광고 캠페인의 퍼포먼스가 좋지 않아 보일 땐 (situation), 나는 제품이 추천하는 방향이나 기능이 있는지 알고싶다 (motivation). 그 이유는, 그런 권고의 메세지를 이해하고 적극 수용함에 따라 광고 켐페인의 퍼포먼스가 더 좋아지는지 보고싶기 때문이다 (expected outcome)"
"When I look at the result for my test, I want to be able to clearly understand what my next step is or what the suggestion from Facebook is so I can take those learnings and share with my team members"
"테스트에 대한 결과를 볼 때 (situation), 나는 제품이 추천하는 다음 단계가 무엇인지 명확히 알고싶다(motivation). 그 이유는, 테스트를 통해 배운 것을 토대로 다른 사람들과 의논해서 전략을 수립해야하기 때문이다 (expected outcome)"
JTBD를 통해 얻은 것
상황에 따라 그리고 목적에 따라 팀원끼리 새로 고안해 내고 사용하는 방법은 매우 다양한 것 같다. 이것은 우리가 디자인 스프린트 또는 디자인 크리틱을 하는 것과 비슷하며 회사마다, 팀마다 그리고 개개인마다 선호하는 방향이 다른 것 같다. JTBD 또한, 그 저 흩어진 퍼즐 조각들을 다시 한번 모이게 만들어주는 하나의 프레임워크에 불과하지만 이번에 적용해 보려고 노력하고 배운 것은, 어쨌든 제일 중요한 것은 팀원 개개인의 참여 (participation)이며 각자 가지고 있는 지식의 능동적인 공유인 것 같다.
하나 확실한 것은, JTBD는 우리가 사용자를 더 이해하려고 노력하게 해 주며 수많은 Job들을 체계적으로 정리할 수 있게 도와준다는 것이다. 궁극적으로 "왜" 사용자들의 우리의 제품을 사용할 것이며 만약 사용하게 된다면 어떤 예상 결과를 바라는지 등을 상기시켜준다. 그래서 팀원들이 합을 모아 하나의 문서로 어느 정도 만들어 놓으면 디자이너 입장에선 Design Principle처럼, 우리가 해야 할 것들이 명확해짐과 동시에, 언제든지 다시 돌아올 수 있게 해 준다. 더 나아가, UX Researcher 또는 Data Scientist 들도 JTBD를 통해 어느 정도 우리 제품의 end-to-end 경험의 success/failure를 감지할 수 있게 된다.
“Knowing more and more about customers — is taking firms in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance — what the customer hopes to accomplish. This is what we’ve come to call the job to be done.
When we buy a product, we essentially “hire” it to help us do a job. If it does the job well, the next time we’re confronted with the same job, we tend to hire that product again. And if it does a crummy job, we “fire” it and look for an alternative.”
"그들이 진정으로 이해해야 할 것은 고객이 주어진 상황에서 달성하고자 하는 진전, 즉 고객이 달성하고자 하는 것이다. 이것이 우리가 해야 할 일 (jobs to be done)이라고 부르는 것이다. 우리가 제품을 살 때, 우리는 본질적으로 우리가 일을 하는 것을 돕기 위해 어떠한 것을 "고용" 또는 "이용"한다. 잘 되면 다음에 같은 일을 하게 되면 그 제품을 다시 고용하는 경향이 있다. 그리고 만약 그것이 형편없는 일을 한다면, 우리는 그것을 "해고"하고 다른 대안을 찾는다.
- Clayton Christensen
