5명만 UT하면 된다는 말의 진실
“5명만 만나보면 대부분의 문제를 알아낼 수 있어요.. 한 .. 85%?”
정말 그런가요? 납득이 되기 어려운 부분이 있습니다. 아무튼 맞다고 치고, 아니, 결론부터 말하면 틀렸습니다.
대개 근거로 인용되는 것은 ‘닐스노먼그룹 아티클 ‘Why You Only Need to Test with 5 Users’ 입니다. 무엇이든 비판적으로 받아들여야 합니다. ‘사람들은 글로 쓰여있으면 진짜인 줄 안다.’는 말을 대학원 다니던 시절 교수님에게 들은 적 있는데.. 과연 이 연구 지금 받아들이기에 괜찮을까요? 한 번 봅시다.
A Mathematical Model of the Finding of Usablility Problems라는 제목이고.. 1993년에 출판되었습니다. 1993년, 그러니까 31년 된 연구죠. 31년이 지난 지금도 충분히 의의가 있을까요? 다행히 레퍼런스 포함 8쪽짜리 짧은 논문이군요.!
논문을 톺아보자
11개의 사용성 문제를 다룬 연구 분석을 통해 “발견되는 사용성 문제 수”와 “평가 횟수” 의 연관 관계를 밝혔습니다. 그러니까 평가 횟수를 알면 발견되는 사용성 문제의 수도 예측할 수 있다는 뜻입니다.
휴리스틱 평가와 User Testing, 두 가지 방식의 평가법을 다룹니다. 두 방식에는 물론 차이가 있습니다. User Test는 사용자 사고방식, 작업 방식 관찰을 통해 문제를 찾고 휴리스틱 평가는 전문가가 UX 원칙에 따라 문제를 찾는 방식입니다.
사용성 문제는 평등하지 않다.
연구는 11가지 시스템에 대한 평가를 리뷰를 했습니다. User Test 만 한 경우가 5건, 휴리스틱 평가가 이루어진 경우는 6개네요. 인터페이스는 GUI, CUI(글자 베이스 인터랙션), 그리고 놀랍게도 VUI까지 등 다양한
인터랙션을 다뤘습니다. 평가 범주로 보면 지금 와서도 충분히 의의가 있을 것 같습니다.
물론 당시와 지금은 테스트 환경도 달라졌으며, 인터페이스에 대한 사람들의 숙련도가 달라졌으니 수치 자체에 대한 보정이 필요해 보입니다. 이 연구는 스마트폰이 보급되기 전에 주로 웹 사용성에 대한 연구였습니다. 지금은 49% 사람들이 하루에 11번 이상 앱을 켜는 세상에 살고 있으니까요. (https://buildfire.com/app-statistics/) 하지만 이 문제는 일단 넘어가도록 합시다.
유의 깊게 볼 부분은 오른쪽 항목에 한 번의 평가로 찾을 수 있는 문제의 수(Problems found by one evaluation)입니다. 위에 두 줄만 볼까요? 스프레드 시트와 같은 오피스 프로그램은 시스템이 복잡해서 발견할 문제가 많고 (145개), 한 번의 평가로 발견되는 문제의 비율이 가장 적습니다(16%). 반면에 달력 프로그램은 발견할 문제의 수도 적고(40개), 단 한 번의 평가로 36%의 문제를 찾을 수 있습니다. 오피스 프로그램의 2배가 넘죠.
이것의 의미하는 바는 ‘사용성 문제는 평등하지 않다.’는 것입니다. 직관적으로 생각해도 단순한 기능의 테스트를 하는데 많은 수의 사람이 필요하지 않고, 복잡한 기능의 경우 적은 수의 테스트로는 충분하지 않다는 것을 알 수 있습니다.
그래도 85% 문제를 찾을 수 있는 거 맞죠? 아뇨.
간단한 사고실험을 해봅시다. 5명 사용성 테스트를 통해 다음의 문제를 85% 확률로 찾을 수 있었을까요?
적록색맹을 가진 저시력자 고객이 취소 버튼과 적용 버튼을 헷갈려서 잘못 누르는 문제
라디오처럼 모든 버튼이 한눈에 보이길 원하는 고령 인구 고객이 2 depth에 들어간 버튼을 찾지 못하는 문제
사용자가 인풋필드에 정보를 입력하던 중 문자가 날아와서 인터랙션에 혼란을 겪는 문제
제가 즉석에서 지어낸 시나리오들인데요, 앞서 말한 것처럼 ‘사용성 문제는 누구에게나 같은 확률로 일어나지 않습니다.’ 즉, 어떤 횟수를 채운다고 누군가의 문제를 찾는 것이 아닙니다. 제품팀의 편향도 큰 문제입니다. 시니어 고객의 멘탈 모델은 제품 기획 시에 따로 다뤄지지 않는 경우가 많은데요, 현재 우리나라 기준 고령자 인구는 900만 명이 넘습니다.
위의 그래프는 ‘31% 사람들이 겪는 (혹은 31% 확률로 일어날 수 있는) 문제’의 경우 테스트 수와 발견된 문제의 상관관계를 보여줍니다. 즉, 5명의 사용성 테스트를 통해 85%의 문제를 찾을 수 있는 게 아니라, 5명의 사용성 테스트를 통해 31% 확률로 일어날 문제를 발견할 확률이 85%입니다. 이 문제에 대해서는 아래 수학적으로 다시 설명해 보겠습니다.
다시 말해서 우리가 잘 알고 있는 명제(5명만 인터뷰하면 된다)는 두 가지를 전제하고 있습니다.
첫째, 모든 사용자가 평등하다
다시 말해서, 사용성 테스트에서 지구인 중 누군가를 랜덤으로 추출할 수 있거나, 개인이 특정 문제를 겪을 확률은 같다는 뜻입니다. 현실은 당연히 그렇지 않으므로, 저희 할머니가 겪을 문제나 장애인이 겪을 문제는 UT에서 발견되거나 대처되기 어렵습니다. 이 경우, 다양한 상황에 처한 고객군의 문제를 해결하고 싶은 제품팀은 적극적으로 편향시킨 고객군을 리크루팅 해야 합니다.
예를 들어, 논문에는 사용성 지식이나 인터페이스에 대한 지식이 높은 사람의 경우 보통 사람에 비해 더 많은 문제를 발견할 수 있었음을 보여주고 있습니다. 꼭 전문성으로 나누지 않더라도, 우리는 직관적으로 평가자(사용자)마다 각각 문제를 발견할 확률이 다르다는 걸 이해하고 있습니다.
둘째, 31% 확률로 일어나는 문제에 경우에만 그렇다.
즉 소수가 겪는 문제는 5번의 UT로는 찾기 어렵습니다. 10% 확률로 나타나는 문제는 18-20번의 UT를 해야 찾을 수 있으니까요. 전 국민을 대상으로 하는 정부 프로그램처럼 애자일 프로세스를 따르지 않고 완성도 높은 제품을 만들어야 하는 경우 더 많은 UT를 시행하는 것이 좋다고 생각합니다.
반대의 경우는 ‘대다수가 겪는 문제’를 찾기 위해서는 굳이 5번의 UT도 필요 없습니다. 2-3건으로 충분합니다. 어차피 통제된 상황에서 하는 테스트고, 완벽하게 문제를 찾아낼 수도 없습니다. 리크루팅도 빡빡하게 하지 않고 사내 UT정도면 충분합니다.
현실적으로 문제 30개를 찾더라도 개발팀에서는 5개도 소화할 여력이 부족합니다. 우선순위가 낮다며 무덤으로 들어간 백로그는 영원히 발굴되지 않습니다.
수학적으로 볼까요?
‘5명의 사용성 테스트를 통해 31% 확률로 일어날 문제를 발견할 확률이 85%입니다’ 이건 어떻게 해석해야 할까요? 참고하기 좋은 기가 막힌 아티클이 있습니다. 원문이 편하신 분은 Why you only need to test with five users (explained)을 읽어주세요. 그게 아니라면 아래의 문제를 봅시다.
동전 앞면을 80% 확률로 보려면 동전을 몇 번 던져야 할까?
잠시 생각해 보시죠. (간단한 수학 문제입니다.)
정답은 3번입니다. 한 번 계산해 볼까요? 모든 경우의 수를 나열해 보면 됩니다.
세 번 동전을 던졌을 때 나오는 경우의 수는 8가지입니다. 원래는 각 확률을 따로 계산해야 하지만 앞, 뒷면 나올 확률이 같고 동전이 제 자리에 서지 않는다고 가정합시다. 모두 뒷면이 나오는 경우는 단 한 가지입니다. 따라서 동전을 세 번 던지면 앞 면을 볼 확률이 7/8, 즉 87.5%가 되는 것이죠.
여기서 동전의 앞면을 우리가 발견할 수 있는 사용성 문제라고 생각하면 됩니다. 즉, 50% 확률로 일어날 사용성 문제는 동전의 앞면과 같습니다. 3명만 테스트하면 찾을 수 있다는 뜻입니다. 반대로 동전 앞면이 나올 확률이 10%라면 18번 정도 동전을 던져야 합니다. 5명의 테스트로는 찾기 어렵다는 뜻이죠.
사용자를 직접 만나지 않고 문제 찾기?
그렇다면 애자일 하고 빠르게 문제를 해결할 때는 적은 수의 UT를 하고, 더 많은 수의 문제를 꼼꼼하게 풀려고 할 때는 많은 수의 고객과 UT를 하면 되는 걸까요?
답이 그렇게 단순하지는 않습니다. 단순히 사용성 문제만 하더라도 <휴리스틱 평가>, 즉 전문성을 가지고 가이드라인대로 평가를 했을 때도 꽤 많은 문제를 찾아낼 수 있기 때문이죠. (위 그래프 참조) 어찌 보면 심리학적인 사용성 원리를 기반으로 문제를 찾는 것이기 때문에 직접 고객을 만났을 때 찾을 수 있는 문제와 크게 다르지 않을 수 있습니다.
실제로 디자인 시안을 배포하기 전에 구글의 머터리얼 디자인 가이드(https://m3.material.io/) 혹은 애플의 휴먼인터페이스 가이드(https://developer.apple.com/design/human-interface-guidelines)를 참고하는 것만으로도 많은 실수를 예방할 수 있습니다.
그렇다고 휴리스틱 평가만 하면 만사 OK도 절대 아닙니다. 전문성 평가로는 ‘고객이 처한 특수한 상황이나 사고방식에 기인한 문제’를 찾아낼 수 없기 때문입니다. 예를 들면 쿼티 키패드가 아닌 천지인 키패드를 사용한다거나, 우리 서비스에서 사용하는 ‘비밀번호’라는 개념을 다른 서비스에서 다른 개념으로 사용하고 있기 때문에 겪는 혼란을 캐치할 수 있습니다.
그래서, 결론이 뭐야?
‘몇 명이냐’에 정답은 없다. 문제도 사용자도 평등하지 않다.
팀이 사용성 문제를 소화할 여력이 있다면 5명 이상을 인터뷰하는 것도 방법입니다. 반대로 사용성 문제를 소화할 여력이 없다면 1~2명으로 충분할지도 모릅니다. 무작정 사용성을 위해 UT를 진행하는 것은 욕심일 수 있습니다. 사용성을 높이는 것이 제품을 성공시키는 방법은 아니니까요.
‘몇 명을 테스트할까? 대신에 ‘누구를 만족시켜야 할까?’를 고민하라.
단순히 테스트 수를 늘린다고 모든 문제를 찾아낼 수 있는 것은 아닙니다. 고객의 문제는 평등하지 않기 때문이죠. 이 기능을 우리 할머니도 잘 써야 하는 것인지, 옆집 아저씨도 잘 쓰길 바라는 것인지, 화장실에서 응가하면서도 편하게 써야 하는지, 흔들리는 지하철에서 써야 하는지, 고민해 보는 것이 필요합니다.
닐스노먼그룹의 아티클에서 평가된 인터페이스의 대부분은 PC, 웹 사용 상황에서 평가되었습니다. 하지만 오늘날 디지털 제품을 사용하는 맥락은 셀 수 없을 만큼 다양합니다. 이를 고려한 사용성 평가가 이루어져야 합니다.
0명을 평가하면 배움이 0이다. 반복한다. 0명을 평가하면 배움이 0이다.
사실 가장 중요한 것은 ‘하기나 해’입니다. 한 명도 테스트하지 않으면 찾을 수 있는 문제는 0개입니다. 몇 명을 할지 고민이 된다면 일단 ‘사용성 평가를 꾸준히 하는 제품 개발 프로세스’를 만드는 것이 우선입니다. 잘하는 것은 그다음이고요.
테스트 횟수를 채우는 게 아니라 꾸준히 하는 게 중요하다.
사용성 평가를 하는 가장 큰 이유는 ‘시간을 아끼려고’입니다. 너무 많은 테스트를 하느라 개발이 늦어지면 안 됩니다. 개발팀에서 소화할 수 있는 만큼 문제를 찾고, 고칩니다. 이러고 나면 새로운 문제가 발견될 수도 있고 기존에 찾았던 문제가 문제가 아니게 될 수도 있습니다. 중요한 것은 이 과정을 반복함으로써 하나의 스프린트처럼 다루는 것입니다. 반복적 디자인(Iterative Desgin) 프로세스를 통해 점점 더 나은 제품을 만들 수 있습니다.
리서처 혼자 하는 평가가 아닌 함께 하는 평가 문화를 만들어라
통계에 의하면 리서처가 아닌 개발팀이 각각 문제를 찾을 확률은 50:50이라고 합니다. 단순히 관찰자를 한 명 추가하는 것만으로도 더 많은 사용자 문제에 공감하게 만들 수 있으며, 리서처는 발견하지 못한 문제를 발견할 확률을 단순 계산으로 2배나 올려줄 수 있습니다.
사실 사용성 평가는 고객 중심의 문제를 해결하는 수많은 방법 중 하나 일뿐입니다. 좀 더 깊게 들어가면 방법에 따라, 상황에 따라 고객을 만나야 하는 수는 전혀 달라질 수 있습니다. ‘누가 몇 명 해야 된다더라’를 떠나서 비판적 사고로 문제를 깊게 분석하고 제대로 풀고자 하면 훨씬 좋은 프로세스를 만들 수 있는 것 같습니다.
다른 의견, 제안 모두 환영합니다.
끗.
