문제 정의

자료에서 문제로

1장의 더블 다이아몬드에서 첫 다이아몬드의 왼쪽 절반은 넓히는 일, 곧 2장의 사용자 조사였다. 오른쪽 절반은 좁히는 일이다. 많이 들은 것을 버리고, 겹치는 것을 합치고, 끝에 "우리가 풀 문제는 이것"이라는 문장 하나를 남긴다. 이 좁히는 일을 문제 정의(Problem definition)라고 한다. 조사로 모은 사실을, 팀 전체가 같은 방향으로 움직일 수 있는 짧은 진술로 바꾸는 일이다.

좁히는 일은 한 번에 되지 않는다. 날것의 기록에서 바로 결론으로 뛰면, 팀이 원래 믿던 것을 자료에서 골라 확인하는 데 그치기 쉽다. 그래서 단계를 나눈다. 아래 그림의 사다리를 한 칸씩 오른다.

사다리의 핵심은 통찰(Insight)이다. 통찰은 "손님들이 헛걸음을 한다"처럼 본 것을 다시 말하는 것이 아니라, "재고를 알 길이 없어서 가 보고서야 안다"처럼 왜 그런지에 대한 해석이다. 해석이라서 틀릴 수 있다. 그래서 통찰에는 근거가 된 기록이 따라붙어야 하고, 나중에 사용성 테스트(8장)나 지표(9장)로 다시 확인할 대상이 된다.

친화도 묶기

기록을 묶는 가장 오래된 도구는 벽과 포스트잇이다. 관찰 하나를 노트 한 장에 적고, 벽에 붙인 뒤 비슷한 것끼리 가까이 옮긴다. 다 옮기고 나면 생긴 무리에 이름을 붙인다. 이렇게 만든 그림을 친화도 다이어그램(Affinity diagram)이라고 한다. 서로 "친한" 기록끼리 모았다는 뜻이다. 1960년대 일본의 문화인류학자 가와키타 지로가 현장 조사 기록을 정리하려고 만든 방법이 바탕이라, 그의 이름 머리글자를 따 KJ법(KJ method)이라고도 부른다.

친화도 묶기에는 지킬 규칙이 몇 가지 있다.

• 한 장에 하나. "앱이 귀찮고 재고도 모른다"는 두 장으로 나눈다. 그래야 각각 다른 무리로 갈 수 있다.
• 아래에서 위로. "기능", "디자인", "가격" 같은 칸을 먼저 그려 놓고 노트를 나누어 넣지 않는다. 미리 만든 칸은 팀이 이미 아는 것만 다시 보여 준다. 무리는 노트를 옮기다 보면 생기는 것이다.
• 이름은 사용자의 말로. 무리의 이름을 "재고"처럼 명사 하나로 붙이면 정보가 사라진다. "가 보기 전에는 있는지 알 수 없다"처럼 문장으로 붙인다.
• 누가 말했는지 남긴다. 노트 귀퉁이에 참가자 번호를 적는다. 무리의 크기를 셀 때 필요하다.

아래 벽에는 서윤의 노트 140장 가운데 26장이 흩어져 있다(가상 자료). 노란 노트는 손님(C1~C8), 파란 노트는 주인(O1~O4)의 말이다. 노트를 끌어 비슷한 것끼리 붙여 본다. 가까이 붙은 노트는 점선 상자로 한 묶음이 되고, 상자 위에 노트 수와 말한 사람 수가 나온다.

벽 위에서 본 것처럼 노트의 수는 말의 양이지 사람의 수가 아니다. 말이 많은 참가자 한 명이 한 무리를 크게 만들 수 있고, 조용한 참가자 여럿이 같은 일을 짧게 말한 무리는 작아 보인다. 그래서 무리마다 "노트 몇 장, 사람 몇 명"을 함께 적는다. 열두 명을 만난 조사에서 무리 하나가 여섯 명에게서 나왔다면 그것은 "절반"이 아니라 "만난 사람 가운데 여섯 명"이다. 비율은 표본을 넘어 일반화할 수 없다(2장의 표본 고르기).

페르소나: 상상한 사람과 자료에 묶인 사람

묶음이 생기면 "이 문제를 겪는 사람은 누구인가"를 묻게 된다. 그 답을 한 사람의 모습으로 그린 것이 페르소나(Persona)다. 이름, 사진, 짧은 이야기를 붙인 가상의 사용자로, 팀이 "사용자"라는 흐린 말 대신 구체적인 사람을 떠올리며 결정하게 돕는다. 앨런 쿠퍼가 『The Inmates Are Running the Asylum』(1999)에서 소개해 널리 퍼졌다.

페르소나는 쓰임만큼 함정도 많다. 가장 흔한 함정은 자료 없이 상상으로 만드는 것이다. 회의실에서 "우리 사용자는 책을 좋아하는 30대 직장인, 앱을 잘 쓰고 SNS로 책 소식을 본다"라고 적으면 그럴듯한 사람이 생기지만, 그 사람은 팀이 원래 생각하던 사용자를 옮겨 적은 것이다. 프루이트와 그루딘(Pruitt & Grudin, 2003)은 마이크로소프트에서 페르소나를 쓴 경험을 정리하면서, 페르소나가 자료와 연결되지 않으면 팀이 믿지 않거나 잘못 쓰기 쉽다는 점을 짚었다.

두 번째 함정은 인구 통계로 나누는 것이다. 나이, 성별, 직업은 적기 쉽지만, 사람이 서비스를 어떻게 쓸지는 대개 행동이 가른다. 쿠퍼와 동료들은 『About Face』에서 인터뷰 참가자를 행동 변수(Behavioral variable)의 축 위에 놓고, 여러 축에서 함께 몰려 있는 사람들을 한 유형으로 묶는 방법을 권한다. 행동 변수는 "찾는 책이 얼마나 정해져 있는가", "가기 전에 얼마나 확인하는가"처럼 사람마다 정도가 다른 행동이나 태도다.

아래에 서윤이 만난 손님 여덟 명(가상)이 있다. 가로축과 세로축에 놓을 변수를 고른다. 그림은 여덟 명을 두 무리로 가장 잘 나누는 방법을 찾아 색으로 표시하고, 두 무리가 얼마나 또렷이 갈리는지 숫자로 보여 준다.

나이와 거리로는 사람들이 갈리지 않았다. 50대와 20대가 같은 방식으로 책을 찾고, 가까이 사는 사람과 멀리 사는 사람이 같은 일로 헛걸음을 했다. 반면 "찾는 책을 정해 두고 오는가"와 "가기 전에 확인하려 하는가"를 축으로 놓자 두 유형이 드러났다. 정해 둔 책을 찾으러 오는 손님(C1, C2, C4, C6, C7)과, 가서 둘러보며 고르는 손님(C3, C5, C8)이다. 이 두 유형은 같은 서비스에 다른 것을 바란다. 앞의 유형에게는 재고 확인이 전부고, 뒤의 유형에게는 서가를 둘러보는 시간 자체가 즐거움이다.

유형을 찾았으면 이제 그 유형의 페르소나에 무엇을 적을지 정한다. 아래 목록은 인터뷰에서 나온 특징 열두 가지와, 여덟 명 가운데 그 특징이 기록된 사람이다(채운 점). 줄을 눌러 페르소나에 넣거나 뺀다.

상상한 페르소나의 문제는 특징 하나하나가 그럴듯하다는 데 있다. "앱으로 추천받고 싶다"는 손님이 실제로 두 명 있었고, "30대 직장인"도 두 명 있었다. 그러나 그 특징들을 한 사람에게 모으자, 만난 여덟 명 가운데 그런 사람은 없었다. 페르소나는 특징의 목록이 아니라 함께 나타나는 행동의 묶음이어야 한다. 그래서 자료에 묶인 페르소나에는 특징마다 근거가 몇 명인지를 적어 두고, 근거가 없는 장식(취미, 좋아하는 커피)은 줄인다.

여정 지도: 문제는 하루의 어느 순간에 생기는가

유형을 찾았으면 그 사람의 하루 위에 문제를 놓는다. 사용자 여정 지도(User journey map)는 한 사람이 목표를 이루기까지 거치는 단계를 가로로 늘어놓고, 단계마다 무엇을 하는지, 무엇을 거쳐 서비스와 만나는지, 기분이 어떤지를 층으로 쌓은 그림이다. 사람이 서비스와 만나는 지점, 곧 전화, 지도 앱, 가게 문 앞 같은 것을 접점(Touchpoint)이라고 한다. 여정 지도는 "앱 안의 화면"만 보던 눈을 앱 밖으로 넓힌다. 서윤의 손님들이 겪는 문제의 대부분은 앱이 없는 순간, 버스 안이나 가게 서가 앞에서 생겼다.

아래 지도는 유형 A 손님의 여정이다. 감정 곡선의 점을 위아래로 끌고, 접점 칸을 눌러 바꿔 본다. 단계 아래의 숫자는 그 순간의 감정을 뒷받침하는 노트 수다.

여정 지도에서 볼 것은 곡선의 모양보다 가장 낮은 곳의 위치와 그곳의 접점이다. 유형 A 손님은 책을 떠올리는 순간에는 즐겁다. 기분이 떨어지는 곳은 재고를 확인하려는 단계다. 그 단계의 접점은 전화뿐인데, 영업시간 밖이거나 주인이 손님을 응대 중이면 닿지 않는다. 그리고 가게 서가 앞에서 책이 없다는 것을 알 때 곡선은 바닥에 닿는다. 서비스가 손댈 곳은 이 두 순간이다. 같은 방법으로 유형 B의 지도를 그리면 모양이 다르다. 가서 고르는 손님에게는 "가게에서" 단계가 가장 높은 곳이다. 서가를 둘러보고 주인과 이야기하는 순간은 이미 좋으니, 서비스가 그 순간을 대신하려 들면 오히려 망칠 수 있다.

해야 할 일(JTBD)

페르소나가 "누구"를 묻는다면, 해야 할 일(Jobs to be done, JTBD)은 "무엇을 이루려고"를 묻는다. 사람은 제품을 사는 것이 아니라 자기 삶의 어떤 진전을 위해 제품을 "고용"한다는 관점이다. 클레이턴 크리스텐슨이 혁신 연구에서 다듬어 『Competing Against Luck』(2016)에서 정리했다. 그가 강연과 책에서 자주 든 예가 아침 출근길에 밀크셰이크를 사는 사람들이다. 이들이 원한 것은 "맛있는 셰이크"가 아니라 "긴 운전길을 지루하지 않게, 점심까지 배고프지 않게" 버티는 일이었고, 셰이크의 경쟁자는 다른 셰이크가 아니라 바나나와 베이글이었다.

해야 할 일을 문장으로 적는 흔한 형식이 잡 스토리(Job story)다. "[상황]일 때, 나는 [동기]하고 싶다, 그래서 [기대하는 결과]." 페르소나 대신 상황을 앞에 두는 것이 특징이다. 같은 사람도 상황에 따라 다른 일을 하려 하기 때문이다. 아래에서 세 칸을 골라 문장을 만들고, 그 문장이 세 가지 점검을 통과하는지 본다.

잡 스토리의 힘은 해결책을 문장 밖으로 밀어내는 데 있다. "앱으로 예약하고 싶다"고 적으면 해결은 앱 하나로 정해지고, 앱을 깔기 싫어하는 다섯 명(앞의 시뮬레이터)은 처음부터 밖에 있다. "오늘 그 책을 손에 넣고 싶다"고 적으면 전화 한 통이 빨리 연결되는 것, 웹 페이지 하나로 재고를 보는 것, 가게가 대신 책을 빼 두는 것이 모두 후보가 된다. 결과 칸도 같다. "앱을 더 오래 쓴다"는 만드는 쪽의 지표이고(9장), 사용자가 원하는 결과가 아니다. 오히려 해야 할 일을 빨리 끝내 앱을 짧게 쓰게 하는 것이 좋은 서비스일 수 있다.

"어떻게 하면" 질문의 높이

문제 문장이 생기면 그것을 해결을 여는 질문으로 바꾼다. 흔히 쓰는 형식이 "어떻게 하면" 질문(How might we, HMW)이다. "어떻게"는 답이 있다고 믿게 하고, "하면"(might)은 답이 여럿일 수 있다고 열어 두고, 질문의 주어 "우리"는 팀이 함께 푼다는 뜻을 담는다. 1970년대 기업의 혁신 현장에서 쓰이기 시작해 디자인 회사들을 거쳐 널리 퍼졌다고 알려져 있다.

좋은 HMW 질문은 높이가 알맞다. 너무 높으면("어떻게 하면 동네 책방이 살아남을까?") 어디서 시작할지 모르고, 너무 낮으면("어떻게 하면 검색 버튼을 위에 둘까?") 이미 해결책 하나를 정해 버린다. 높이는 두 질문으로 조절한다. 질문에 "왜?"라고 물으면 한 칸 올라가고, "어떻게?"라고 물으면 한 칸 내려간다. 아래 사다리의 손잡이를 끌어 높이를 바꿔 본다.

알맞은 높이는 팀의 크기와 시간이 정한다. 서윤의 팀은 세 명이고 6월 말까지 석 달이 있다. "동네 책방이 살아남는 법"은 이 팀의 질문이 아니고, "검색 버튼의 위치"는 아직 물을 때가 아니다. 사다리 가운데쯤, 해결책은 열려 있지만 무엇을 해결할지는 분명한 칸이 출발점이다. 한 문제에서 HMW 질문을 여러 개 만들어 두는 것도 좋다. "어떻게 하면 주인이 재고 묻는 전화에 덜 끊기게 할까?"는 같은 묶음의 다른 쪽, 곧 주인의 자리에서 본 질문이다.

무엇부터 풀 것인가

묶음이 여럿이면 모두 풀 수는 없다. 우선순위를 매기는 가장 단순한 틀은 두 축이다. 그 문제를 겪는 사람이 얼마나 많은가(빈도(Frequency)), 겪을 때 얼마나 아픈가(영향(Impact)). 두 축 위에 문제를 놓으면 오른쪽 위는 먼저 풀 것, 왼쪽 아래는 미뤄도 될 것이 된다.

두 축의 값은 측정값이 아니라 판단이다. 빈도는 열두 명 가운데 몇 명이 말했는가로 세고, 영향은 그 일이 생겼을 때 사람이 무엇을 잃는가(시간, 돈, 다시 오지 않음)로 팀이 매긴다. 아래 그림의 점은 서윤의 팀이 매긴 첫 값이다(가상 자료). 점을 끌어 팀원마다 판단이 다를 때 순위가 어떻게 바뀌는지 본다.

이 틀에는 한계가 분명하다. 빈도는 만난 사람 가운데의 수라서, 표본이 한쪽으로 치우쳤다면 함께 치우친다. 영향은 매기는 사람의 처지에 따라 다르다. 주인에게 "재고 묻는 전화"는 하루를 끊는 큰일이지만, 손님에게는 작은 불편이다. 그래서 점의 위치를 두고 다투는 시간이 가장 값지다. 누가 왜 그 점을 위로 끌어올리려 하는지 말하는 동안, 팀은 서로의 가정을 알게 된다.

세 번째 축도 있다. 그 문제를 푸는 데 드는 비용이다. 개발자 지후는 "영향이 같으면 싼 것부터"를 원칙으로 둔다. 비용은 문제 정의가 끝난 뒤, 해결책 후보가 생기고 나서야 매길 수 있으므로 이 장에서는 이름만 적어 둔다. 비용을 너무 일찍 섞으면 싸게 풀 수 있는 문제만 "중요한 문제"로 보이기 쉽다.

서윤의 서비스 노트