테스트

시안을 팀 안에서만 확인하고 개발로 넘기던 시절이 있었습니다. 리뷰에 모인 사람들이 모두 고개를 끄덕이면 통과입니다.

문제는 그 자리에 앉은 사람 전원이 제품을 이미 아는 사람이라는 데 있습니다. 어느 버튼이 무엇을 하는지, 이 화면 다음에 무엇이 오는지를 알고 보면 흐름이 매끄럽게 느껴집니다. 같은 화면을 처음 보는 사용자 다섯 명에게 시켜 보면 넷이 두 번째 화면에서 멈추는 일이 실제로 벌어집니다. 팀이 본 것은 화면이고 사용자가 만난 것은 낯선 절차라서, 같은 그림을 보고도 다른 것을 겪습니다. 이 차이는 회의를 한 번 더 해서는 줄지 않습니다.

이 단계에서는 만드는 일이 멈추고 확인만 합니다. 앞 단계에서 반나절이나 이틀을 들여 만든 프로토타입이 그대로 재료가 됩니다.

1. 사용자 다섯 명쯤을 만나 과업을 줍니다. 어떻게 생각하는지 묻지 않고 실제로 해 보게 하는 사용성 테스트 방식을 씁니다. 의견을 물으면 그럴듯한 답이 나오고, 시켜 보면 막히는 자리가 나옵니다.
2. 진행하는 사람과 기록하는 사람을 나눕니다. 혼자 하면 다음 질문을 생각하느라 방금 본 장면을 놓칩니다.
3. 결과는 잘 만들었는지에 대한 판정이 아니라 막힌 지점의 목록입니다. 다섯 명 중 몇 명이 어디서 멈췄는지를 숫자와 함께 적습니다.
4. 앞 단계로 되돌아가는 것이 정상입니다. 화면만 문제면 프로토타이핑으로, 해법 방향이 틀렸으면 아이디에이션으로, 애초에 풀려던 문제가 아니었으면 정의로 돌아갑니다.

한 바퀴로 끝나지 않는다는 점이 이 단계의 성격입니다. 세 사람이 같은 자리에서 멈췄다면 고친 뒤에 다시 다섯 명을 만나는 것이 다음 순서입니다. 다섯 명이면 크게 걸리는 문제는 대부분 드러나므로 인원을 늘리는 대신 횟수를 늘립니다.

"테스트에서 다섯 명 중 넷이 두 번째 화면에서 멈췄어요."

숫자와 함께 막힌 지점을 보고하는 말입니다.

"의견은 묻지 말고 과업만 주세요."

무엇을 하게 시킬지가 이 방법의 조건이라는 지적입니다.

"이건 화면 문제가 아니라 문제 정의가 틀린 것 같아요."

두 단계 앞으로 돌아가야 한다는 판단입니다.

페이지덱의 문서 공유 흐름을 다시 만들 때 민서가 종이 시안 여덟 장으로 다섯 명을 만났습니다. 네 명이 권한을 고르는 화면에서 멈췄고, 멈춘 이유가 모두 같았습니다. 읽기 전용과 편집 가능이라는 말 대신 회사에서 쓰는 다른 표현을 기대하고 있었습니다. 지현은 그 결과를 받아 문제 정의 문장을 한 번 고쳤습니다.