인지적 워크스루

화면 시안을 놓고 모인 자리는 대개 인상을 주고받다 끝났습니다. 누군가는 버튼이 눈에 안 띈다고 하고 누군가는 글자가 많다고 합니다. 다섯 명이 모이면 다섯 가지 소감이 나오는데 무엇부터 고쳐야 할지는 아무도 말해 주지 않습니다.

더 큰 문제는 만든 사람이 자기 화면에서 절대 막히지 않는다는 점입니다. 어느 버튼이 무엇을 하는지 이미 알고 있으니 아무리 써 봐도 처음 온 사람이 겪을 막힘은 드러나지 않습니다.

사용성 테스트를 돌리면 답이 나오지만 사람을 모아야 합니다. 조건에 맞는 참여자 다섯 명을 구하는 데만 2주가 걸리는 일이 흔한데, 시안은 이번 주에 정해야 합니다. 페이지덱에서 민서가 초대 화면을 다시 그렸을 때도 다음 주에 개발 시작이 잡혀 있었습니다.

인지적 워크스루는 이 빈자리를 메우려고 만든 방법입니다. 사용자를 데려오는 대신 사용자의 사고 흐름을 흉내 냅니다. 화면을 한 단계씩 넘기면서 매번 같은 질문을 던지고, 그 답이 막히는 자리를 문제로 적습니다.

과업을 한 문장으로 적는 데서 시작합니다. "초대 화면을 평가한다" 는 과업이 아닙니다. "메일 주소를 모르는 동료를 문서에 초대한다" 가 과업입니다. 목적지가 분명해야 그 길에서 벗어났는지 판단할 수 있습니다.

1. 과업을 정하고, 그 과업을 하는 사람이 누구인지 함께 적습니다. 오늘 가입한 사람인지 6개월 쓴 사람인지에 따라 같은 화면의 답이 달라집니다. 점검은 보통 아무것도 모르는 쪽으로 잡습니다.
2. 올바른 경로를 단계로 적습니다. 화면을 누르는 순서대로 여섯에서 열 단계 정도가 나옵니다. 유저 플로우를 이미 그려 뒀다면 그 경로를 그대로 가져옵니다.
3. 단계마다 네 가지 질문에 답합니다. 사용자가 지금 무엇을 하려는지 스스로 알고 있는가, 그것을 할 수단이 화면에 보이는가, 그 수단이 자기가 원하는 것과 이어진다고 알아볼 수 있는가, 누른 뒤에 제대로 됐는지 알 수 있는가입니다.
4. 답은 예 또는 아니오로 적고, 아니오면 왜 그런지를 한 줄 붙입니다. "3단계 세 번째 질문 아니오 — 버튼 이름이 공유 인데 사용자는 초대할 사람을 찾고 있어서 같은 것이라고 연결하지 못함" 같은 형태입니다.
5. 다 돌고 나면 아니오가 몰린 단계부터 봅니다. 한 단계에서 세 사람이 같은 질문에 아니오를 냈다면 그 자리가 첫 번째 수선 대상입니다.

진행은 세 명에서 다섯 명이 모여 90분 안에 끝냅니다. 한 사람이 단계를 읽어 넘기고 한 사람이 받아 적습니다. 만든 사람도 들어오되 변론하지 않는 것이 규칙입니다. "그건 여기 설명이 있어요" 라는 말이 나오는 순간, 설명을 읽지 않는 사용자의 시선이 만든 사람의 시선으로 돌아갑니다.

프로토타입이나 와이어프레임만 있어도 돌아갑니다. 실제로 동작하지 않아도 화면 순서와 문구만 정해져 있으면 네 질문에 답할 수 있습니다.

처음 한 번만 지나가는 흐름에 가장 잘 맞습니다. 가입, 온보딩, 첫 결제, 계정 연결처럼 사용자가 익숙해질 기회 없이 한 번에 통과해야 하는 자리입니다. 이런 흐름에서는 두 번째 시도에서 나아진다는 가정이 성립하지 않아서, 한 단계만 막혀도 그대로 이탈로 이어집니다.

만들기 전 단계에도 잘 맞습니다. 개발이 끝난 뒤에 발견하면 고치는 값이 크지만, 화면 순서만 그려진 상태에서는 문구 하나 바꾸는 일로 끝납니다. 사용자를 모을 시간이나 예산이 없을 때 대신 꺼내는 수단이기도 합니다.

맞지 않는 자리도 분명합니다. 매일 쓰는 숙련 사용자의 화면에서는 네 질문의 답이 전부 예로 나옵니다. 그 사람들이 느끼는 문제는 몇 번 더 눌러야 하는지 같은 효율 쪽이라 여기 걸리지 않습니다. 시각적 완성도나 속도도 이 방법으로는 보이지 않습니다.

한계는 두 가지입니다. 하나는 점검하는 사람이 정답 경로를 이미 알고 있다는 점입니다. 모르는 척하는 것과 진짜 모르는 것은 다르고, 그래서 결과는 실제 사용자가 막히는 자리와 겹치기도 하고 어긋나기도 합니다. 다른 하나는 얼마나 많은 사람이 그 자리에서 막히는지 알 수 없다는 점입니다. 문제 목록은 나오지만 빈도가 없어서, 발견한 것 중 무엇이 실제로 큰 손실인지는 나중에 모더레이티드 테스트나 이탈 수치로 확인해야 합니다.

"이번엔 사람 모을 시간이 없으니 워크스루로 한 바퀴 돌고 가죠."

사용자를 부르는 대신 팀이 사고 흐름을 따라가며 먼저 걸러 내자는 제안입니다.

"3단계에서 다들 아니오가 나왔어요. 버튼 이름부터 바꿔야 할 것 같습니다."

특정 단계에 문제가 몰렸으니 거기를 먼저 손보자는 뜻입니다.

"그건 지금 변론이고요, 일단 아니오로 적어 두고 넘어가시죠."

만든 사람의 설명이 점검 시선을 흐리지 않게 막는 말입니다.

페이지덱에서 민서는 새 흐름을 개발에 넘기기 전날 이 자리를 잡습니다. 태오는 어느 단계가 구현하기 까다로운지 같이 보고, 수아는 고객에게 그 화면을 설명해 온 사람이라 어디서 문의가 오는지 압니다.

지현은 나온 항목을 전부 고치지 않고 이번에 고칠 것과 미룰 것을 나눕니다. 기준은 그 단계를 지나는 사람이 몇 명인지입니다. 가입 직후 모두가 지나는 2단계의 문제는 이번에 고치고, 설정 깊은 곳에서만 나타나는 문제는 남겨 둡니다.

사용성 테스트를 대신한다고 읽는 경우가 가장 많습니다. 둘 다 막히는 자리를 찾는 방법이라 그렇게 보입니다. 하지만 이 방법이 내놓는 것은 막힐 것 같은 자리의 목록이고, 사용성 테스트가 내놓는 것은 실제로 막힌 장면입니다. 앞엣것을 뒤엣것으로 믿는 팀은 문제가 안 나왔다는 이유로 그대로 내보내고, 예상 못 한 자리에서 이탈이 생긴 뒤에야 사람을 부릅니다. 순서는 반대입니다. 워크스루로 싸게 걸러 낸 뒤 남은 것을 사람으로 확인합니다.

그냥 다 같이 써 보는 것과 같다고 읽는 것도 흔합니다. 회의실에서 화면을 넘겨 보는 모습이 비슷하니 자연스러운 생각입니다. 차이는 단계마다 같은 네 질문을 강제로 던진다는 데 있습니다. 그냥 써 보면 사람들은 눈에 띄는 것만 말하고, 아무 말 없이 지나간 단계는 문제가 없어서가 아니라 아무도 그 단계를 의식하지 않아서 조용합니다. 질문 없이 돌리면 한 시간을 써도 인상 몇 개만 남습니다.