사용성 리스크

기능이 안 쓰이는 이유를 한 덩어리로 다루던 시절이 있었습니다. "안 써요" 라는 보고 안에는 서로 다른 원인 네 가지가 섞여 있었는데, 구분할 말이 없으니 회의는 매번 같은 자리에서 갈렸습니다.

권한 설정 기능을 세 달 걸려 만들었는데 사용률이 3퍼센트로 나온 자리가 그랬습니다. 한쪽은 애초에 필요 없는 기능이었다고 했고, 다른 쪽은 필요는 한데 찾지 못하는 것이라고 했습니다. 두 진단의 처방은 정반대입니다. 앞쪽이 맞으면 기능을 지워야 하고 뒤쪽이 맞으면 화면을 고쳐야 합니다. 근거 없이 고른 쪽이 틀리면 세 달을 더 씁니다. 그래서 원인을 네 갈래로 갈라 이름을 붙였고, 그중 두 번째가 사용성 리스크입니다.

이 위험이 있는지는 물어서 알 수 없고 시켜 봐야 압니다. 절차는 세 단계입니다.

1. 과업을 한 문장으로 줍니다. "외부 협력사에게 이 문서 하나만 열어 주세요" 라고 말하고 아무 안내도 하지 않습니다. 어디를 누르라고 한 마디만 보태도 측정은 끝납니다.
2. 옆에서 지켜보며 시간을 잽니다. 실제 과업을 시켜 보며 막히는 자리를 찾는 이 방법을 사용성 테스트라 합니다. 다섯 명 중 셋이 3분 안에 끝내지 못하면 사용성 리스크가 있다고 봅니다.
3. 어디서 멈췄는지 적습니다. 메뉴를 못 찾은 것과 찾고도 뜻을 몰라 되돌아간 것은 고칠 곳이 다릅니다.

가치 리스크와는 물어볼 것이 다릅니다. 필요하냐고 물었을 때 그렇다고 답하는데 시켜 보면 못 하는 상태가 사용성 리스크이고, 필요하냐는 질문에 아니라고 답하면 그건 가치 쪽입니다. 들어오는 문의 문장으로도 갈립니다. 어디 있냐는 물음은 사용성이고, 왜 없냐는 물음은 가치입니다.

확인하는 시점은 만든 뒤가 아니라 만들기 전입니다. 화면만 그려 둔 프로토타입으로도 같은 과업을 시켜 볼 수 있고, 코드가 없으니 고치는 데 반나절이면 됩니다.

"사용률 3퍼센트인데, 가치 쪽인지 사용성 쪽인지부터 갈라야 합니다."

지우는 결정과 고치는 결정이 갈리니 원인을 먼저 특정하자는 말입니다.

"다섯 명 중 셋이 3분 안에 못 찾았어요. 만들기 전에 다시 그립시다."

측정 결과가 기준을 넘었으니 화면을 되돌리자는 뜻입니다.

"문의가 전부 어디 있냐는 거예요. 기능은 있는데 못 찾는 겁니다."

문의 문장의 형태로 원인을 사용성 쪽으로 판정했다는 말입니다.

페이지덱은 권한 설정 기능을 만들기 전에 민서가 화면만 그려 다섯 명에게 같은 과업을 시켰습니다. 셋이 3분을 넘겼고, 셋 다 같은 자리에서 멈췄습니다. 문서 메뉴 안에 있을 것이라 생각한 항목이 계정 설정 쪽에 있었습니다. 지현이 그 자리를 옮기기로 정하고, 태오는 구조가 바뀐 뒤에 작업을 시작했습니다.