직접 설계한 서비스를 가지고 직접 사용성 테스트를 수행해보는 기분은, 눈을 가리고 목적지까지 걸어가다가 잠깐 가리개를 들어서 앞을 보는 찬스를 얻은 것과 비슷하다.
눈을 감고 앞으로 걸어가면, 한 걸음 한 걸음마다 두려움이 몰려온다. 바로 앞에 장애물이 있진 않은지, 이 방향이 맞긴 한건지. 실제로 눈을 가리고 걸어가면 바로 발 아래있는 맨홀에 빠질 수도 있고, 완전 엉뚱한 방향으로 걸어갈 수도 있다.
그래서 사용성 테스트는 왠만하면 해보는게 좋다고 본다. 전혀 안하면, 아무나 잡고 한 번만 물어봐도 알 수 있을 정도로 치명적인 실수도 전혀 대응하지 못하고 걸어가게 될 수도 있다. ‘눈을 가렸다’라는 비유를 썼지만, 사실 이건 ‘비유’가 아니다. 실제로 프로젝트를 한 달 정도만 참여하면 그 결과물에 대해선 눈이 멀게된다. 설계한 당사자는 모든 기능을 너무나 능숙하게 쓸 수 있기 때문이다. (아니 여기서 이걸 딱 누르면 이렇게 딱 되는건데, 이걸 왜 몰라? 다 바보 아냐?)
그리고, 가급적이면 빠른 시간내에 해보는 것이 좋다고 본다. 눈을 가리고 있기 때문에, ‘완전 엉뚱한 방향’으로 가고 있을 가능성도 있다. 이 때는 둘 중 하나다. 반대 방향으로 가고 있다는 것을 빨리 알아채고 제대로된 방향을 찾느냐, 아주 늦게 알아채고 절망하느냐. 조금이라도 빨리, 눈가리개를 들어서 확인해봐야 한다. 빠른 시간내에 꼭 해봐야 한다. 눈을 감고 시작하기 때문에, 사실 제대로 된 방향으로 가고 있을 확률이 지극히 낮기 때문이다.
그럼 왜, 왜 테스트를 안하게 될까? 크게 두 가지 경우가 있다.
1. 귀찮아서.
사용성 테스트와 인터뷰를 하는 것은 무지무지 귀찮다. 사실 눈가리개를 들어올리는 정도로 설명이 안될 정도로 무지무지 귀찮고 힘들다. 시간도 꽤 걸린다.
인터뷰나 테스트가 쓸모없다고 주장할 근거는 너무나 많다. 통계적으로 무의미한 숫자다, 사용자들은 자신이 원하는 것을 모른다(여기선 꼭 포드와 잡스의 격언이 함께함), 조작이나 유도가 너무 쉽다 등등. 하지만 역시 가장 근본적인 이유는 ‘귀찮음’이라고 본다.
일단, 백만명을 만날 수 없기 때문에 단 한명도 만날 필요가 없다는 것은 말이 안된다. (통계적 의미를 찾는 이에게는 딱 10명만 만나보라는 말을 해주고 싶다. 5명 넘어가면서 계속 똑같은 대답을 듣는 것이 지겨워지기 시작할 것이다. 누구한테 물어봐도 나오는 똑같은 말이 바로 찾아야할 ‘그것’이다)
사용성 테스트는 애당초 사용자들이 원하는 것을 알아내기 위해서 하는 것도 아니다. 그냥 만든걸 주고, 이거 해봐 저거 해봐 하는 것이다. 잘 하면 OK인 것이고, 못하면 거길 수정해야한다는 것을 발견하는 것으로 끝이다. 거기서 ‘그럼 어떻게 하면 잘 할 수 있을거같아?’라고 물어보는 것도 큰 의미는 없다.
조작이나 유도. 무척 쉽긴 하지만, 자기가 직접 설계하고 진심으로 잘되길 원하는 경우라면 굳이 조작이나 유도도 하지 않을 것이다. (반대의 경우가 더 많겠지만, 반대의 경우는 그냥 눈을 가리고 쭉 걸어가는 거라고 보면 된다. 뭐 눈을 감고 걸어가도 운이 좋으면 도착할 수도 있는것 아닌가)
결국 근본적인 원인은 귀찮음인 것… 사용성 테스트나 인터뷰를 완강히 거부하는 사람들을 보자. 혹시 한번도 테스트나 인터뷰를 직접 수행해보지 않은 사람이 아닌가?
2. 잘못 온거면 어떡하지?
잘못온걸 알았다 해도 이미 돌이킬 수 없는 상황에선 위와 같은 두려움이 생기게 된다. (사실 일찍 해도 생긴다) 그래서 그냥 모른척, 끝까지 가보게 된다.
어떻게 할까
여러가지 방법으로 테스트를 진행해봤지만, 음… 일단 지금까지의 미천한 경험으로 미루어봤을 때, 상당히 심플한 테스트 설계 + 최대한 자세한 프로토타입 + 5~7명 정도를 빠르게 여러번 수행하는 것이 가장 효과적인 것 같다. 테스트에서 너무 많은 것을 알아내기 위해 너무 많고 깊은 질문을 하는 것, 페이퍼 프로토타입으로 진행하는 것은 효과가 많이 떨어질 것 같다.
상세하고 깊은 질문의 문제
긴 시간동안 많은 질문을 퍼부어도, 결국 남는 것이 그리 많지 않다는게 일단 문제. 그리고 데이터가 많아져서 분석시간이 오래걸리는 것도 문제. 그리고 질문이 깊어지면 깊어질 수록 인터뷰 대상자는 상상의 나래를 펼치기 때문에 왜곡도 깊어진다는 것이 문제…
무의식적으로 보인 행동을 조용히 관찰하다가, 행동이 딱 끝나면 ‘방금 왜 그렇게 하셨죠?’ 하는 정도의 간단한 질문 까지만 하는게 좋다. 그것도 뭔가 ‘어…’하면서 생각하기 시작하면, 그때부턴 거짓말을 하는걸로 의심해도 될 것이다.
(만약 사용자의 삶이나 실제 사용 패턴을 알아봐야 하는 경우라면, 인터뷰 전에 그 사람의 로그 데이터를 분석해보거나, 다이어리 데이터를 수집하는 것을 병행해야 한다. 인터뷰 대상자가 나쁜 마음을 먹고, 나를 속이려 들기 때문이 아니다. 자기 자신에 대한 기억은 생각보다 엄청나게 부정확하다는 것이 문제다.)
페이퍼 프로토타입의 문제
페이퍼 프로토타입은 프로젝트 내부에서 소통하는데는 쓸 수 있지만, 외부 참가자에게 테스트할 때는 별로 효과적이지 않은 것 같다. 실제 사용성 이슈는 아주 작은 아이콘이나 미묘한 색의 차이에서도 발생하는데, 이런건 페이퍼 프로토타입으로 잡아낼 수는 없다. 그리고 가짜인게 너무 티가 나서 몰입이 쉽지 않다는 것도 문제.