사용자 리서치

무엇을 만들지는 결국 누군가 정해야 하는데, 정할 근거가 없으면 회의실에서 가장 확신에 찬 사람의 말이 근거 자리를 차지합니다. 근거처럼 들리는 문장도 대개 정해져 있습니다. 제 주변 사람들은 다 이렇게 쓰던데요, 저라면 이건 안 쓸 것 같은데요, 경쟁사도 이렇게 해 놨잖아요. 셋 다 틀린 말은 아니지만 몇 명을 보고 한 말인지, 그 몇 명이 우리 사용자와 같은 사람들인지가 빠져 있습니다.

페이지덱에서도 폴더 기능을 두고 그 자리가 한 번 있었습니다. 민서가 자기 주변 팀은 아무도 폴더를 안 쓴다고 했고, 지현은 자기가 만난 팀들은 들어오자마자 폴더부터 찾더라고 했습니다. 30분을 쓰고도 결론이 나지 않았습니다. 나중에 세어 보니 민서가 본 팀은 넷이었고 지현이 만난 팀은 다섯이었습니다. 둘 다 사실을 말했고, 둘 다 전체를 말할 수 있는 수가 아니었습니다. 이런 회의는 대개 직급이 높은 쪽 의견으로 끝나고, 두 달 뒤에 만든 기능이 안 쓰이면 그때 다시 같은 논쟁을 합니다.

사용자 리서치는 이 자리에 확인 가능한 근거를 들여놓는 일입니다. 바뀌는 것은 사용자를 만난다는 사실이 아니라 만난 과정을 남긴다는 점입니다. 무엇을 알고 싶었는지, 누구를 몇 명 만났는지, 어떻게 뽑았는지, 무엇을 물었는지, 그래서 몇 명에게서 같은 말이 나왔는지를 적어 둡니다. 그러면 반년 뒤에 다른 사람이 와서 그 결론을 의심할 때 다시 논쟁하는 대신 기록을 열어 볼 수 있습니다.

제품 축에서 이 용어는 만들기 전에 만들 값어치가 있는지 확인하는 갈래에 놓입니다. 그 확인 활동 전체를 제품 디스커버리라고 부르고, 사용자 리서치는 그 안에서 가장 자주 쓰는 수단입니다. 리서치에서 나온 것은 그대로 쌓아 두지 않고 정리해 씁니다. 고객이 제품을 고용해 끝내려는 일이 무엇인지로 수요를 보는 관점, 흩어진 사용자 집단을 한 사람처럼 구체화한 모델, 알게 되고 쓰고 떠나기까지를 한 줄로 그린 지도가 그 정리 도구들이고, 그 재료를 대는 쪽이 사용자 리서치입니다.

이 아래에는 용어 열 개가 있고 세 갈래로 나뉩니다. 무엇을 얻는 조사인지로 가른 성격, 그것을 어떻게 얻는지로 가른 방법, 이 일을 한 번이 아니라 계속 돌아가게 만드는 운영입니다. 하나를 고를 때 순서도 이 방향입니다. 성격을 먼저 정하고 방법을 고르고, 같은 일을 매달 하게 되면 그때 운영을 만듭니다.

성격은 답의 종류로 갈립니다. 둘입니다.

1. 정성 조사 — 왜 그렇게 행동하는지를 말과 관찰로 알아내는 조사입니다. 사람 수가 적어도 됩니다. 같은 조건의 사용자를 다섯에서 여덟 명쯤 만나면 대개 같은 말이 반복되기 시작하고, 그 지점부터는 새로 알게 되는 것이 빠르게 줄어듭니다. 대신 여기서 나온 것으로 비율을 말할 수는 없습니다.
2. 정량 조사 — 얼마나 그런지를 숫자로 재는 조사입니다. 비율을 말하려면 사람 수가 필요해서 보통 수백 명 단위로 모읍니다. 무엇이 얼마나 많은지는 알려 주지만 왜 그런지는 알려 주지 않습니다.

둘은 경쟁하는 선택지가 아니라 순서가 있는 짝입니다. 정성으로 무슨 일이 벌어지는지 알아내 가설을 만들고, 정량으로 그 일이 얼마나 자주 벌어지는지를 잽니다. 순서를 뒤집으면 설문 문항을 무엇으로 채울지부터 막힙니다.

방법은 어떻게 알아낼지로 갈립니다. 여섯입니다.

1. 고객 인터뷰 — 한 사람을 45분에서 한 시간쯤 만나 경험을 듣습니다. 묻는 방향이 정해져 있습니다. 다음에 이런 기능이 있으면 쓰겠느냐고 묻지 않고, 지난주에 그 일을 마지막으로 했을 때 어떻게 했는지를 묻습니다. 앞쪽은 상상에 대한 답이고 뒤쪽은 실제로 일어난 일에 대한 답입니다.
2. 설문 조사 — 같은 질문을 여러 사람에게 던져 분포를 봅니다. 문항을 잘못 쓰면 원하는 답이 나오게 만들 수 있어서, 유도하는 표현과 보기 순서를 먼저 점검합니다.
3. 사용성 테스트 — 실제 과업을 시켜 보며 어디서 막히는지를 봅니다. 의견을 묻지 않고 하게 둡니다. 다섯 명이면 크게 걸리는 문제는 대부분 드러납니다.
4. 다이어리 스터디 — 2주쯤 사용자가 스스로 기록을 남기게 합니다. 인터뷰에서는 기억나지 않아 빠지는 일상적인 사용이 여기서 잡힙니다.
5. 필드 리서치 — 쓰는 현장에 찾아가 맥락째 봅니다. 화면만 봤으면 몰랐을 것이 책상 위에 있습니다. 모니터에 붙은 메모지, 옆에 같이 띄워 놓은 표 계산 파일 같은 것입니다.
6. 데스크 리서치 — 이미 나와 있는 자료를 모아 정리합니다. 가장 싸고 빨라서 보통 맨 앞에 둡니다. 이미 답이 나와 있는 질문에 사람을 모으는 낭비를 여기서 걷어 냅니다.

운영은 이 일을 반복 가능하게 만드는 갈래입니다. 둘입니다.

1. 리서치 리크루팅 — 조건에 맞는 참여자를 모읍니다. 실무에서 가장 오래 걸리는 단계라 일정의 절반이 여기 들어갑니다. 조건을 문장으로 적고, 사례비를 정하고, 약속 시각에 나타나지 않는 사람을 감안해 필요한 인원보다 넉넉히 잡습니다.
2. 리서치 옵스 — 매번 처음부터 다시 하지 않도록 틀을 만들어 두는 일입니다. 동의서 양식, 참여자 명부, 녹화와 기록을 두는 자리, 같은 사람에게 너무 자주 연락하지 않게 막는 규칙이 여기 듭니다.

한 번 돌리는 절차는 여섯 단계입니다.

1. 알고 싶은 것을 질문 한 문장으로 적습니다. 사용자를 이해하자는 문장이 아니라, 폴더를 만들어 놓고 쓰지 않는 팀은 문서를 어떻게 찾는지처럼 답이 나올 수 있는 문장이어야 합니다.
2. 그 질문에 답할 방법을 고릅니다. 왜인지 모르면 정성, 얼마나인지 모르면 정량입니다.
3. 누구에게 물을지를 정하고 모읍니다. 최근 한 달 안에 문서를 열 개 이상 만든 5인 이상 팀의 관리자처럼 조건을 적어 두고 그 조건으로 뽑습니다.
4. 실행합니다. 물어볼 것을 미리 적어 가고, 진행하는 사람과 기록하는 사람을 나눕니다. 혼자 하면 다음 질문을 생각하느라 방금 들은 말을 놓칩니다.
5. 정리합니다. 발언을 주제별로 묶고 각 주제에 몇 명에게서 나왔는지를 적습니다. 여덟 명 중 여섯 명이라고 적힌 주제와 한 명이라고 적힌 주제는 다르게 다룹니다.
6. 결정으로 잇습니다. 무엇을 바꿀지, 무엇을 더 알아봐야 하는지, 무엇을 안 바꾸기로 했는지를 적습니다. 이 단계가 없으면 보고서만 남습니다.

어느 자리에 넣을지도 대체로 정해져 있습니다. 값이 가장 큰 때는 무엇을 만들지가 아직 갈리지 않은 때입니다. 방향이 둘로 나뉘어 어느 쪽인지 모를 때, 이미 낸 기능을 사람들이 왜 안 쓰는지 모를 때, 처음 들어온 사용자가 어디서 멈추는지 모를 때가 그렇습니다. 반대로 답이 이미 기록에 남아 있는 질문은 사람을 모을 일이 아닙니다. 가입 화면에서 몇 퍼센트가 빠져나가는지는 로그를 열면 나오고, 여기에 여덟 명을 불러 앉히면 2주를 쓰고도 같은 숫자를 못 얻습니다. 고칠 여지가 없는 것을 조사하는 것도 낭비입니다. 결제 모듈을 바꿀 수 없는 분기에 결제 화면 사용성 테스트를 돌리면 고칠 수 없는 문제 목록만 손에 남습니다. 때를 놓치는 것도 같은 낭비입니다. 결정이 끝난 뒤에 나온 결과는 입력이 아니라 보고서라서, 일정은 팀이 골라야 하는 날짜에서 거꾸로 잡습니다. 그때까지 답이 안 나올 질문이면 나올 만큼 좁힙니다. 인터뷰 여덟 건을 세 건으로 줄이거나, 2주짜리 기록 조사 대신 과업 하나를 다섯 명에게 보여 주는 식입니다.

한계도 함께 알아 둡니다. 사람은 자기 행동을 정확히 기억하지 못하고, 앞에 앉은 사람 기분에 맞춰 답을 조금씩 바꿉니다. 특히 앞으로 어떻게 하겠느냐는 질문의 답은 거의 맞지 않습니다. 쓰겠다고 답한 열 명 중 실제로 쓰는 사람이 둘인 일이 흔합니다. 그래서 묻는 대상을 미래가 아니라 최근에 실제로 한 일로 잡고, 말과 행동이 어긋날 수 있는 자리에서는 관찰로 확인합니다. 다섯 명에게서 나온 말을 비율로 옮기지 않는다는 선도 여기서 함께 지킵니다.

"그건 인터뷰 다섯 명에서 나온 얘기예요. 비율로 말하려면 설문을 따로 돌려야 합니다."

정성 조사 결과를 전체의 비율처럼 쓰려는 것을 막는 말입니다.

"이번엔 의견을 묻지 말고 그냥 해 보시게 두죠. 어디서 멈추는지만 봅시다."

사용성 테스트의 방식을 정하는 말입니다.

"리크루팅에 2주 걸립니다. 다음 주 회의에 결과를 올리는 건 어렵습니다."

참여자를 모으는 시간 때문에 일정을 다시 잡자는 뜻입니다.

앞의 폴더 논쟁은 페이지덱에서 이렇게 끝났습니다. 지현이 2주짜리 다이어리 스터디를 걸고, 그동안 문서를 스무 개 넘게 만든 팀 여덟 곳에 사용성 테스트를 붙였습니다. 민서는 진행하지 않고 옆에서 보기만 했습니다. 참여자가 말로 설명한 것과 손이 실제로 움직인 자리가 다를 때 그 차이를 잡아 두는 것이 관찰자의 몫이기 때문입니다.

결과는 양쪽 다 아니었습니다. 여덟 팀 중 일곱 팀이 폴더를 만들었고, 그중 여섯 팀이 만든 지 한 주 안에 쓰기를 멈췄습니다. 문서를 찾을 때는 폴더를 열지 않고 검색창에 제목 일부를 치거나 최근 문서 목록을 훑고 있었습니다. 폴더가 필요 없다는 뜻도, 폴더를 더 잘 만들어야 한다는 뜻도 아니었습니다. 찾는 일과 정리하는 일이 서로 다른 순간에 일어난다는 뜻이었습니다. 그래서 그 분기에 손댄 것은 폴더가 아니라 최근 문서 목록이었습니다.

가장 흔한 오해는 사용자에게 무엇을 만들지 물어보는 일이라고 여기는 것입니다. 사용자를 만난다고 하니 요청을 받아 오는 자리처럼 들리고, 실제로 인터뷰에서 기능 이름이 직접 나오기도 합니다. 그런데 사용자는 자기 문제에 대해서는 누구보다 잘 알지만 그 문제를 무엇으로 풀지는 잘 모릅니다. 더 빠른 말을 달라는 요청에 자동차로 답하는 일이 리서치가 아니라 제품 팀의 몫이라는 뜻입니다. 요청 목록을 그대로 받아 구현하면 기능은 늘어나는데 쓰는 사람은 늘지 않는 제품이 됩니다. 물어야 할 것은 무엇을 원하느냐가 아니라 어제 그 일을 어떻게 했고 어디서 막혔느냐입니다. 해법은 그 답을 재료로 팀이 만듭니다.

두 번째는 시간과 돈이 많이 드는 큰 행사라고 여기는 것입니다. 참여자를 모으고 사례비를 주고 보고서를 쓰는 그림이 먼저 떠오르니 일정이 빠듯하면 가장 먼저 빠집니다. 규모가 큰 조사는 실제로 몇 주가 걸리지만 모든 리서치가 그렇지는 않습니다. 이미 쓰고 있는 고객 다섯 명에게 화면을 보여 주고 과업 하나를 시켜 보는 데는 반나절이면 됩니다. 계산해야 할 것은 리서치에 드는 시간이 아니라 건너뛰었을 때 치르는 값입니다. 두 달 걸려 만든 기능을 아무도 쓰지 않아 걷어 내는 일과, 만들기 전에 반나절을 쓰는 일 중 어느 쪽이 싼지는 대개 분명합니다.