휴리스틱 평가

화면의 문제를 찾으려면 사람을 데려와 써 보게 하는 것이 정석입니다. 문제는 그 자리가 비싸다는 점입니다. 조건에 맞는 참여자 다섯 명을 구하는 데 두 주가 걸리고, 한 명당 한 시간씩 진행하고 사례비를 주고, 녹화를 다시 보며 정리하는 데 또 며칠이 듭니다.

그렇게 어렵게 마련한 자리가 뻔한 문제로 채워지는 일이 잦았습니다. 다섯 명 중 셋이 같은 오류 메시지 앞에서 멈췄는데, 이유를 보니 무엇이 잘못됐는지도 어떻게 고치는지도 안 적혀 있고 "요청을 처리할 수 없습니다" 한 줄만 떠 있었습니다. 이런 것은 화면만 들여다봐도 알 수 있는 종류입니다. 두 주를 기다려 모은 사람들에게 확인받을 일이 아니었습니다.

1990년에 야콥 닐슨과 롤프 몰리히가 내놓은 방법이 이 낭비를 겨눕니다. 사람을 부르는 대신 아는 사람 몇이 원칙 목록을 들고 먼저 훑어 값싼 문제를 털어 내자는 것입니다. 화면을 보고 "제 생각엔 이게 불편해 보여요" 하고 말하는 것과 다른 점은 판단의 근거가 개인 취향이 아니라 공개된 목록이라는 데 있습니다.

여섯 단계로 돌아갑니다. 참여자 모집이 없으므로 준비까지 합쳐 보통 이틀이면 끝납니다.

1. 원칙 목록을 정합니다. 대개 닐슨 휴리스틱 열 가지를 그대로 씁니다. 시스템 상태가 보이는가, 사용자가 실수에서 빠져나갈 길이 있는가 같은 항목으로 이루어진 사용성 점검 기준입니다.
2. 평가 범위를 과업 단위로 자릅니다. "제품 전체" 는 범위가 아닙니다. "무료로 가입해 팀원 세 명을 초대하기" 처럼 시작과 끝이 있는 흐름 하나를 잡습니다.
3. 평가자 서너 명을 세우고 각자 따로 돌게 합니다. 한 사람이 찾아내는 문제는 전체의 3분의 1 남짓이고, 사람마다 걸리는 자리가 달라서 따로 돌린 뒤 합쳐야 목록이 채워집니다.
4. 각자 화면을 두 번 훑습니다. 첫 번째는 흐름을 파악하는 데만 쓰고, 두 번째에 원칙 목록을 들고 항목별로 다시 봅니다. 한 번만 보면 전체 구조를 모른 채 지적을 적게 되어 실제 흐름에서는 문제가 아닌 것이 섞입니다.
5. 찾은 문제마다 세 가지를 적습니다. 어느 화면의 어느 지점인지, 열 가지 중 어느 원칙에 어긋났는지, 심각도가 얼마인지입니다. 심각도는 0에서 4까지 매기는데 0은 문제가 아님, 4는 출시를 막아야 하는 수준입니다.
6. 목록을 한자리에 모읍니다. 겹치는 지적을 하나로 합치고, 심각도가 엇갈리면 그 자리에서 맞춥니다. 끝에 남는 것은 보고서가 아니라 심각도 순으로 늘어놓은 고칠 목록입니다.

심각도를 매기는 단계를 건너뛰면 목록이 쓸모를 잃습니다. 지적 40개가 순서 없이 늘어서 있으면 받아 든 쪽은 어디부터 손대야 할지 몰라 전부를 미룹니다.

화면은 이미 있는데 시간과 예산이 없을 때 첫 번째로 꺼내는 방법입니다. 사용성 테스트를 잡기 전에 돌려 두면 값비싼 관찰 시간을 큰 문제에 쓸 수 있습니다. 실제 과업을 시켜 보며 막히는 지점을 찾는 그 자리를 "버튼 이름이 무슨 뜻인지 모르겠다" 로 채우지 않게 됩니다.

한계는 셋입니다.

전문가가 찾은 문제와 사용자가 실제로 막히는 자리가 늘 겹치지는 않습니다. 원칙 목록은 화면이 갖춰야 할 일반적인 조건을 다루기 때문에, 업무 용어를 몰라서 막히는 문제는 잡아내지 못합니다. 회계 담당자만 아는 말이 버튼에 적혀 있어도 평가자에게는 그냥 낯선 단어일 뿐입니다.

거짓 양성이 많습니다. 원칙에 어긋나지만 실제로는 아무도 걸려 넘어지지 않는 지적이 섞여 나옵니다. 그래서 심각도 1 이하로 매겨진 항목을 전부 고치려 들면 품만 들고 사용성은 그대로입니다. 사용성은 사용자가 목적을 얼마나 쉽고 정확하게 이루는가를 가리키는 말인데, 그 기준으로 보면 고쳐도 달라지는 것이 없는 항목들입니다.

결과가 평가자에 달려 있습니다. 사용성을 아는 사람 셋이 도는 것과 그 분야를 처음 보는 사람 셋이 도는 것은 결과가 다릅니다.

"사용자 인터뷰 잡기 전에 휴리스틱 평가부터 돌리죠. 뻔한 건 털고 들어가게요."

값싼 방법으로 먼저 걸러 비싼 자리를 아끼자는 제안입니다.

"이거 심각도 3으로 봤어요. 배포를 막을 정도는 아닌데 다음 스프린트에는 잡아야 해요."

문제를 찾았을 뿐 아니라 언제 고칠지까지 정하는 말입니다.

"저는 열다섯 개 적었는데 민서 님 목록이랑 겹치는 게 넷뿐이네요."

따로 돌았기 때문에 합쳐야 전체가 보인다는 것을 확인하는 대목입니다.

페이지덱이 초대 흐름을 고치던 주에 민서가 이 방법을 돌렸습니다. 디자이너 두 명과 지현까지 셋이 각자 하루씩 초대 화면을 훑고 목록을 들고 모였습니다. 합쳐 보니 지적이 31개였는데 셋이 모두 적은 것은 두 개뿐이었고, 그 둘이 심각도 4를 받았습니다. 초대 메일이 발송됐는지 화면에 아무 표시가 없는 것과, 잘못 입력한 주소를 지울 방법이 없는 것이었습니다.

31개를 다 고치지는 않았습니다. 심각도 3 이상인 아홉 개만 그 스프린트에 넣고 나머지는 목록에 남겨 뒀습니다. 두 주 뒤 사용자 다섯 명을 불러 같은 흐름을 테스트했을 때, 그 아홉 개와 겹치는 문제는 한 건도 나오지 않았고 대신 아무도 예상 못 한 것이 나왔습니다. 팀원의 메일 주소를 모르는 사람이 초대 자체를 포기한다는 것이었습니다.

사용자 테스트를 대신할 수 있다고 보는 경우가 가장 많습니다. 같은 화면에서 문제를 찾아내는 활동이고 결과물도 비슷한 목록이라 자연스러운 오해입니다. 그런데 둘이 찾는 문제의 종류가 다릅니다. 이 방법은 화면이 규칙을 어긴 자리를 찾고, 사용자 테스트는 사람이 실제로 멈춘 자리를 찾습니다. 앞의 초대 화면 사례가 그 차이입니다. 평가로 대체하고 끝내면 그 제품은 원칙에는 어긋나지 않지만 아무도 끝까지 가지 못하는 흐름을 그대로 안고 출시됩니다.

혼자 돌려도 된다고 생각하는 것도 흔합니다. 사용자를 부르지 않으니 사람 수는 중요하지 않아 보입니다. 하지만 한 명이 잡아내는 것은 전체의 3분의 1쯤이고, 세 명으로 늘리면 6할 정도까지 올라갑니다. 다섯 명을 넘기면 새로 나오는 것이 거의 없어 늘릴 이유가 사라집니다. 혼자 돌린 결과를 놓고 "점검했다" 고 말하면, 실제로는 셋 중 둘을 못 본 목록을 완결된 목록으로 여기고 다음 단계로 넘어가게 됩니다.