UX 리서치 기법

조사라는 것이 "만든 화면을 보여 주고 어떠냐고 묻는 일" 이던 시절이 있었습니다. 시안을 띄워 놓고 옆자리 동료에게 괜찮은지 묻거나, 회의실에서 세 안 중 하나를 손들어 고르게 했습니다. 이런 질문에 사람은 대체로 좋다고 답합니다. 만든 사람이 앞에 앉아 있고, 답하는 쪽은 그 화면으로 실제로 무언가를 해 본 적이 없기 때문입니다.

그래서 출시 뒤마다 같은 장면이 되풀이됐습니다. 어느 팀이 팀원 초대 화면을 새로 그려 내보냈는데, 한 달 뒤 확인해 보니 초대를 시작한 사람 중 절반이 중간에 멈춰 있었습니다. 시안 회의에서는 아무도 그 자리를 지적하지 않았습니다. 회의에 앉은 사람들은 초대할 동료의 주소를 이미 알고 있었고, 실제 사용자는 주소를 몰라 주소록을 찾으러 나갔다가 돌아오지 않았습니다.

어긋난 지점은 물어본 것과 알고 싶은 것이 달랐다는 데 있습니다. 알고 싶은 것은 "이 사람이 초대를 끝까지 해내는가" 인데 물어본 것은 "이 화면이 마음에 드는가" 였습니다. 취향을 물으면 취향이 돌아옵니다. 행동을 알고 싶으면 행동을 시켜 보고 옆에서 지켜봐야 하고, 비율을 알고 싶으면 사람을 여럿 모아 세어야 합니다.

UX 리서치 기법은 묻는 방식을 목적별로 갈라 둔 도구 모음입니다. 무엇을 알고 싶은지가 정해지면 꺼낼 도구도 대체로 정해집니다. 디자인 프로세스에서 이 도구들이 나오는 자리는 둘입니다. 무엇이 문제인지 확인하는 첫 칸과, 만든 것을 사용자에게 시험해 보는 네 번째 칸입니다. 그중 화면을 주고 과업을 시켜 보는 사용성 테스트가 가장 널리 쓰여 리서치를 그 하나로 아는 사람도 많지만, 옆에는 열 가지가 넘는 도구가 각자 다른 질문을 맡고 있습니다.

UX 리서치 기법 아래 묶인 용어는 여섯 갈래입니다. 갈리는 기준은 도구의 생김새가 아니라 무엇을 알아내려고 꺼내느냐입니다. 사람이 해내는지 직접 보려는 것부터 점수로 바꿔 견주려는 것까지 있습니다.

여섯 갈래를 가로지르는 구분이 하나 더 있습니다. 정성 조사는 왜 그렇게 행동하는지를 말과 관찰로 잡아냅니다. 다섯 명이면 대체로 충분하고 결과는 문장으로 남습니다. 정량 조사는 얼마나 그런지를 숫자로 재는 쪽이라 수십에서 수백 명이 필요하고 결과는 비율과 점수로 남습니다. 앞의 넷은 정성, 뒤의 둘은 정량 쪽에 가깝습니다.

첫째, 사용성 테스트입니다. 만든 화면을 실제로 써 보게 하고 막히는 지점을 지켜봅니다.

1. 모더레이티드 테스트 — 진행자가 옆에 앉아 과업을 주고, 손이 멈춘 순간에 무엇을 찾고 있었는지 묻습니다. 이유까지 얻는 대신 한 명에 한 시간이 들고 일정을 맞춰야 합니다.
2. 언모더레이티드 테스트 — 참여자가 혼자 수행하고 화면 녹화와 말소리만 남습니다. 하루에 열 명도 돌릴 수 있지만 막힌 자리에서 되물을 수 없어 이유는 추측으로 남습니다.
3. 게릴라 테스트 — 카페나 사무실 로비에서 지나가는 사람을 붙잡아 5분 안에 끝냅니다. 대상이 실제 사용자가 아닐 확률이 높아 세밀한 판단에는 못 쓰고, 누가 봐도 막히는 큰 문제를 싸게 걸러 냅니다.

둘째, 전문가 평가입니다. 사용자를 모으지 않고 아는 사람이 먼저 훑는 방식이라 빠르고 쌉니다.

1. 휴리스틱 평가 — 서너 명이 정해진 원칙 목록에 비춰 화면을 훑고 어긋난 자리를 적습니다. 원칙은 보통 닐슨 휴리스틱 열 가지를 씁니다. 사용자 모집이 없어 이틀이면 끝나지만, 전문가가 찾은 문제와 실제 사용자가 막히는 자리가 늘 겹치지는 않습니다.
2. 인지적 워크스루 — 과업 하나를 정해 놓고 화면을 한 단계씩 넘기며 매 단계에서 같은 질문을 던집니다. 처음 온 사람이 다음에 무엇을 눌러야 할지 알까, 눌렀다는 것을 알아챌까입니다. 가입 직후처럼 아무것도 모르는 흐름을 점검할 때 값이 큽니다.

셋째, 구조 조사입니다. 화면을 그리기 전에 메뉴와 이름이 맞는지 확인하는 자리라 정보 구조를 짜는 단계와 붙어 다닙니다.

1. 카드 소팅 — 항목 이름을 적은 카드를 주고 사용자가 직접 묶게 합니다. 팀이 정한 분류와 사용자가 묶는 방식이 다르면 여기서 드러납니다.
2. 트리 테스트 — 화면 없이 메뉴 글자만 주고 회사 결제 카드를 바꾸려면 어디로 가겠는지를 묻습니다. 디자인이 정답을 귀띔해 주지 않는 상태에서 이름만으로 길을 찾는지 봅니다.
3. 퍼스트 클릭 테스트 — 화면 한 장을 보여 주고 첫 클릭 위치만 기록합니다. 첫 클릭이 맞은 사람과 틀린 사람 사이에 과업 성공률 차이가 크게 벌어진다는 관찰에 기대는 방법입니다.

넷째, 인상 조사입니다. 오래 써 본 뒤의 판단이 아니라 처음 몇 초에 무엇이 전달되는지를 봅니다.

1. 5초 테스트 — 화면을 5초만 보여 주고 덮은 다음 무엇이 기억에 남는지 묻습니다. 랜딩 페이지에서 무슨 서비스인지가 전달되는지 확인할 때 씁니다.
2. 선호도 테스트 — 시안 두세 개를 나란히 놓고 어느 쪽이 나은지 고르게 합니다. 이유를 함께 묻지 않으면 취향 투표로 끝나 다음에 고칠 것이 남지 않습니다.

다섯째, 행동 관찰입니다. 물어보지 않고 남은 흔적만 봅니다. 이미 쓰고 있는 사용자가 있어야 돌아갑니다.

1. 아이트래킹 — 장비로 시선이 머문 위치와 순서를 기록합니다. 장비값과 분석 시간이 커서 규모가 작은 회사에서 돌리는 일은 드뭅니다.
2. 세션 리플레이 — 실제 사용자의 화면 조작을 그대로 재생합니다. 마우스를 흔들거나 같은 버튼을 세 번 누르는 장면이 여러 사람에게서 반복되면 그 자리가 문제입니다.
3. 히트맵 — 클릭과 스크롤이 몰린 위치를 색으로 겹쳐 봅니다. 어디를 눌렀는지는 알려 주지만 왜 눌렀는지는 알려 주지 않아서, 대개 다음 조사의 출발점으로 씁니다.

여섯째, 정량 척도입니다. 사용성을 하나의 점수로 바꿔 시점끼리 또는 제품끼리 견주려고 만든 설문입니다.

1. 시스템 사용성 척도 — 열 문항 설문으로 0에서 100 사이 점수를 냅니다. 68점이 평균선으로 알려져 있어 우리 점수가 바깥과 견줘 어디쯤인지 말할 수 있습니다.
2. UMUX — 같은 것을 네 문항으로 줄인 설문이라 응답률이 걱정되는 자리에서 대신 씁니다.

기법은 다르지만 돌리는 순서는 대체로 같습니다.

1. 무엇을 알고 싶은지 한 문장으로 적습니다. "초대 화면을 평가한다" 는 질문이 아닙니다. "초대할 사람의 메일 주소를 모르는 사용자가 초대를 끝내는가" 가 질문입니다.
2. 그 문장에 답할 수 있는 기법을 고릅니다. 이유를 알고 싶으면 사람을 만나는 쪽, 비율을 알고 싶으면 숫자를 모으는 쪽입니다.
3. 조건에 맞는 참여자를 모읍니다. 대개 여기가 가장 오래 걸려서, 유료 플랜을 쓰는 30인 팀의 관리자 다섯 명을 구하려면 두 주를 잡습니다.
4. 과업과 질문을 적은 진행 계획을 만들고 동료를 상대로 한 번 예행합니다. 이 자리에서 "이 버튼 찾기 쉽죠?" 같은 유도 질문을 걸러 냅니다. "이 버튼을 찾아 보세요" 로 바꾸면 답이 아니라 행동이 돌아옵니다.
5. 돌리고, 관찰한 것을 적고, 팀과 함께 봅니다. 끝에 남아야 하는 것은 보고서가 아니라 다음에 고칠 목록입니다.

고를 때 걸리는 조건은 셋입니다. 화면이 이미 있는지, 사용자가 이미 쓰고 있는지, 시간이 얼마나 있는지입니다. 화면을 그리기 전이면 구조 조사와 인상 조사가 남고, 화면이 있으면 사용성 테스트와 전문가 평가가 열리고, 쓰고 있는 사용자가 있어야 행동 관찰과 정량 척도가 돌아갑니다. 하루가 있으면 전문가 평가나 게릴라 테스트, 한 주가 있으면 모더레이티드 테스트 다섯 건, 한 달이 있으면 정량 척도까지 붙일 수 있습니다.

"이건 리서치 질문이 아니라 화면 평가예요. 무엇을 알고 싶은지부터 한 줄로 적읍시다."

목적이 정해지지 않은 채로 조사를 시작하면 결과가 감상으로 돌아온다는 지적입니다.

"이번 주엔 트리 테스트로 메뉴 이름만 확인하고 화면은 그다음에 그릴게요."

구조가 틀린 상태에서 그린 화면은 다시 그려야 하니 순서를 바꾸자는 제안입니다.

"다섯 명 중 셋이 막혔다고 60퍼센트라고 쓰지는 맙시다."

적은 인원으로 한 조사에서 비율을 뽑으면 근거보다 오해를 만든다는 뜻입니다.

페이지덱에서 무료 팀의 유료 전환을 다루던 분기에 이 말들이 자주 오갔습니다. 규원이 결제 화면을 새로 그려 보자고 했을 때 민서는 화면 대신 질문을 먼저 적었습니다. "결제를 시작한 관리자가 회사 카드 정보를 손에 넣기까지 무엇을 하는가" 였습니다.

민서가 먼저 꺼낸 것은 세션 리플레이였습니다. 결제 화면에 들어왔다 나간 세션 스무 개를 재생해 보니 열두 개가 카드 번호 칸 앞에서 3분 넘게 멈춰 있었습니다. 어디서 멈추는지는 알았지만 왜인지는 알 수 없어 다음 주에 모더레이티드 테스트를 다섯 건 붙였습니다. 다섯 중 넷이 같은 말을 했습니다. 카드를 자기가 들고 있지 않아 재무 담당자에게 물어봐야 하는데, 화면을 닫으면 처음부터 다시 해야 할 것 같아 그냥 두었다는 것이었습니다.

지현과 태오가 함께 본 자리에서 결론은 화면을 다시 그리는 쪽이 아니라 결제 담당자를 따로 지정해 초대하는 흐름을 만드는 쪽으로 났습니다. 숫자로 어디인지를 찾고 사람을 만나 왜인지를 들은 순서가 이 결정을 만들었습니다.

리서치를 사용자에게 무엇을 원하는지 묻고 그대로 만드는 일로 읽는 경우가 가장 많습니다. 사용자 중심이라는 말이 붙어 다니니 자연스러운 오해입니다. 그런데 사람이 말하는 해법은 대개 자기가 아는 제품에서 본 것입니다. 초대가 불편하다는 사용자에게 무엇이 있으면 좋겠냐고 물으면 열에 아홉은 엑셀 파일로 한 번에 올리게 해 달라고 답합니다. 정작 필요한 것은 주소를 몰라도 초대장을 보낼 수 있는 흐름이라 요청을 그대로 받으면 아무도 쓰지 않는 업로드 기능만 하나 늘어납니다. 그렇게 요청 목록을 받아 적다 보면 반년 뒤에는 기능이 스무 개 늘어난 채 전환율은 그대로인 제품이 됩니다. 가져와야 하는 것은 요구된 해법이 아니라 그 요구를 만든 상황입니다.

다섯 명이면 충분하다는 말을 모든 기법에 적용하는 오해도 흔합니다. 널리 알려진 경험칙이라 숫자만 기억에 남은 탓입니다. 이 말이 성립하는 자리는 정성 사용성 테스트뿐이고, 그나마도 큰 문제 대부분이 다섯 명 안에서 한 번은 나타난다는 뜻이지 다섯 명이 전체를 대표한다는 뜻이 아닙니다. 사용성 점수가 나아졌는지를 다섯 명으로 판단하면 한 사람이 바뀔 때마다 결과가 20퍼센트씩 흔들립니다. 이 오해를 그대로 두면 다섯 명 중 셋이 했다는 관찰이 60퍼센트라는 숫자로 문서에 적히고, 그 숫자를 근거로 잡은 다음 분기 계획이 통째로 틀어집니다.