형성적 사용성 테스트
사용자가 어디서 헤매는지 파악하기
형성적 사용성 테스트(UT, Usability Testing)는 참가자가 과제(태스크)를 수행하는 사이 참가자 행동을 관찰하면서 사용성을 진단하는 기법입니다. 실무에서는 주로 사용성 테스트라고 합니다. 사용자를 읽는 법 UX리서치 플레이북(백원희 님) 책에서 본 '형성적 사용성 테스트'를 정리했습니다.
왜 중요한가?
- 프로덕트 완성 전 프로토타입 단계에서 평가를 진행하여 피드백을 얻을 수 있음
- 개발 초반, 중반, 후반: 프로덕트의 방향, 개선할 점을 계속 확인하면서 작업할 것을 권장
- 사용자 중심 프로덕트 제작의 중요한 길잡이 역할을 함
사용성 평가 3 요소
1. 유효성(Effectiveness)
- 태스크를 완료한 참가자가 몇 명인가?
- 얼마나 많은 오류가 발생했으며, 오류의 정도는 어떠한가?
2. 효율성(Efficiency)
- 참가자가 얼마나 신속하게 태스크를 수행하는가?
- 태스크를 끝내기 위해 정신적 에너지가 필요한가?
3. 만족도(Satisfaction)
- 참가자가 프로덕트 경험과 사용성에 만족하는가?
4. 수치를 수집하는 경우
- 참가자들의 태스크 수행 시간, 오류 수 기록
- 문제가 얼마나 심각한지 판단하는 자료로 사용
형성적 사용성 테스트(Formative Usability Testing)
1. 개요
- 리서치 유형: 행동적, 질적, 평가적
- 샘플링: 5~8명
- 소요시간: 2~4주
2. 장점
- 참가자의 대답에 의존하지 않고 직접 행동을 관찰
- 적은 수의 참가자만으로도 대부분의 사용성 문제 발견 가능
- 데이터 분석 과정이 짧은 편이라 리서치 인사이트를 프로덕트에 빠르게 반영할 수 있음
- 상대적으로 시간과 비용이 적게 듦
3. 한계
- 질적 리서치의 특성상 통계적으로 유의미하지 않고, 결과를 일반화할 수 없음
- 테스트가 아닌 실제 환경에서 사용자들이 어떻게 행동할지 예측하지 못함
- 테스트로 드러난 사용성 문제가 출시 후 얼마나 많은 사용자에게 영향을 미칠지 알 수 없음
비교 평가 방법
- 기존 프로덕트와 신규 프로덕트 비교
- 새로운 콘셉트 A와 B 비교 평가
- 두 가지 콘셉트의 장단점 파악에 유리함
1. 참가자 내 연구(Within-subjects Study)
- 같은 참가자가 두 개 이상 복수의 콘셉트를 비교 평가
- 사용자에게 콘셉트를 보여 주는 순서를 임의로 바꾸면서 진행
- 한 번에 두세 개 이상의 콘셉트를 테스트하지 않을 것
2. 참가자 간 연구(Between-subjects Study)
- 그룹을 나누어 한 참가자가 한 개의 콘셉트를 평가
- e.g: 배너 광고가 나오지 않게 설정하는 기능을 사용자가 쉽게 알아채는지 확인할 경우
- 같은 참가자가 서로 다른 콘셉트를 평가할 경우 앞서 평가한 콘셉트 내용이 뒤에 영향을 줌
진행 순서
1. 준비하기(1~2주)
- 리서치 계획서 쓰기(리서치 질문, 테스트 형식)
- 프로토타입 확인하기
- 시나리오와 태스크 만들기
- 디스커션 가이드 작성하기
- 참가자 조건 확정하고 모집하기
- 파일럿(사전) 테스트
2. 테스트하기(1~2일)
- 사전 준비(비밀유지계약서 작성, 레코딩 기기 설치)
- 테스트 목적과 주의사항 안내하기
- 시나리오와 태스크 전달하고 진행하기(세션 15~90분)
- 설문조사하기(선택사항)
- 관찰자들과 디브리핑(보고서 공유)하기
3. 분석하기(1~2주)
- 레코딩 리뷰, 사용성 문제 찾기
- 리포트 준비하기, 발표하기
테스트 형식 정하기
진행 방식에 따라 3가지로 구분
1. 리서처가 대면으로 진행
- 리서처와 참가자가 얼굴을 마주 보고 진행
- 참가자의 행동 관찰, 추가 질문 가능
- 사용자 행동, 구체적인 맥락과 의도 파악에 적합
장점
- 실시간 진행: 참가자의 이해력, 배경 지식에 따라 인터뷰 시간 조정 가능
- 추가 질문, 세부적인 내용을 파고들어 명확한 답을 얻음
- 리서처의 질문에 답하는 것을 편하게 여길 수 있음
단점
- 리서처 진행: 시간이 많이 소요되어 참가자 수 제한적
- 리서처가 다양한 레코딩 장비를 사용할 줄 알아야 함
- 리서처, 참가자의 이동 시간이 필요
2. 리서처가 원격으로 진행
- 리서처와 참가자가 서로 다른 장소에서 원격으로 진행
- 줌(Zoom), 구글 미트(Google Meet) 등 화상회의 툴 사용
- 원격 리서치가 주를 이루는 추세
장점
- 참가자의 이동 시간 절약됨
- 참가자 모집 지역 제한이 없어 다양한 배경의 사용자 모집 가능
단점
- 화상회의, 테스트 플랫폼 준비 시간이 걸리거나 기술 문제로 원활하지 않을 수 있음
- 프로토타입이 참가자 디바이스에서 작동되지 않을 수 있음
3. 리서처 없이 원격으로 진행
- 언모더레이티드 사용성 테스트(Unmoderated Usability Testing)
- 참가자가 태스크를 진행하면서 주어진 질문에 대답함
- 리서처는 테스트 종료 후 레코딩 내용 확인
- 리서치 플랫폼에서 진행: 다수의 테스트 동시에 실시, 빠른 시간에 많은 참가자 데이터 모을 수 있음
- 프로토타입 흐름이 단순할 때 사용
- 필요한 참가자 수가 많을 때 편리함(e.g: 여러 콘셉트로 참가자 간 테스트할 경우 등)
- 시간이 없다는 이유로 사용하는 것은 주의
장점
- 많은 수의 참가자를 테스트할 수 있음
- 모더레이팅이 없어 진행 시간 절약
- 테스트 종료 후 몇 시간 안에 결과가 나옴
- 참가자들이 솔직하게 생각과 의견 표현함
단점
- 시나리오와 태스크를 이해하기 쉽도록 자세하게 설계해야 함
- 참가자가 제대로 파악하지 못할 경우 데이터가 쓸모없어짐
- 추가 질문이 불가능
- 피드백 퀄리티가 떨어질 수 있음
시나리오 작성하기
참가자가 일상에서 겪을 법한 상황을 시나리오로 준비
"강아지가 아플 때를 대비해서 반려동물 보험에 가입하기로 결정했습니다. 반려동물 의료보험 웹사이트에서 가장 적합한 보험 상품을 찾아 결제까지 진행하도록 하겠습니다."
태스크 작성하기
- 평가 항목, 리서치 질문에 맞추어 여러 개의 태스크 작성
- 태스크는 하나씩 전달하고, 참가자가 이를 수행하는 과정을 관찰하며 추가 질문함
- 사용성 테스트의 성패는 태스크 작성하기에 달려 있음
- 프로덕트 평가가 필요한 부분을 선택, 참가자가 해당 요소를 이용해 태스크를 완료하도록 설계
좋은 태스크란?
1. 현실적이다.
- '실제로' 할 법한 행동을 토대로 시나리오와 태스크를 작성
- 실제 행동과 거리가 먼 태스크는 지양
- e.g: 신용카드를 새로 만드는 시나리오
- e.g ⭕️ : 신용카드 신청 전, 여러 신용카드 정보를 살펴보고 비교하는 과정이 자연스러운 흐름
- e.g ❌ : 신용카드를 여러 장 신청해 달라고 하는 등, 실제 행동과 거리가 먼 태스크는 지양
2. 구체적이다.
- 태스크 목적을 자세하고 명확하게 밝힐 것
- e.g ⭕️ : '이번에 자동차를 새로 사게 되었다고 가정하겠습니다. 운전하면서 다양한 혜택을 받을 수 있는 신용카드를 골라 보시겠어요?'
- e.g ❌ : '신용카드를 만들어 보세요.'
3. 힌트를 주지 않는다.
- 태스크를 구체적으로 전달하되, 인터페이스에 쓰인 단어는 사용하지 않기
- e.g ❌ : '주유 할인을 받을 수 있는 신용카드를 찾아보세요'
- 참가자가 '주유 할인'이라는 키워드가 포함된 카드를 바로 골라내기 때문
테스트 목적과 주의사항 안내하기
- 사용성 테스트는 참가자에게 낯설게 느껴질 수 있음
- 도입부에 리서처 소개, 테스트 목적, 소요시간, 레코딩, 자료 사용 등 안내
1. 참가자가 아니라 프로덕트를 평가하는 것이라는 점을 강조한다.
- 태스크를 수행하지 못하거나 헤매는 것은 참가자 능력과 상관없는 프로덕트 문제임을 알릴 것
2. 솔직하게 평가해 달라고 부탁한다.
- 솔직한 피드백이 프로덕트 개선에 도움이 된다고 반드시 설명할 것
- e.g: 리서처는 디자인한 사람이 아니라서 객관적인 평가에도 상처받지 않는다고 강조
3. '소리 내어 생각하기(Think Aloud)'를 요청한다.
- 머릿속에 떠오르는 생각과 감정을 모두 공유해 달라고 할 것
- 태스크에 집중하면 속으로만 생각할 수 있기 때문에 의식적으로 작은 감정이라도 스스럼없이 말해 달라고 할 것
4. 프로토타입이 가지는 한계를 설명한다.
- 테스트 목적으로 만들어졌기 때문에 일부분만 클릭할 수 있다는 점을 설명할 것
5. 원하는 피드백이 있다면 도입부에 미리 언급한다.
- e.g: 천천히 실행하면서 의견을 충분히 주면 좋겠다
- e.g: 카피를 눈여겨봐 달라고 하는 등
시나리오와 태스크 전달하고 진행하기
1. 질문할 때는 단어 하나도 신중하게 선택한다.
- 인터페이스에 쓰인 단어를 사용하지 않고 질문해야 함
- 리서처가 사용하는 단어는 참가자에게 무의식적으로 영향을 줌
- e.g ⭕️ : "이전에 보던 페이지로 가려면 어디를 누르시겠어요?"
- e.g ❌ : "다시 뒤로 돌아가려면 어디를 누르시겠어요?"
- 참가자가 바로 '뒤로가기' 버튼을 찾을 수 있기 때문
2. 참가자의 발언보다는 행동에 주목한다.
- 리서처가 옆에 있어서 부정적인 얘기를 못하거나 헤매는 모습을 보이기 싫어하는 경우도 있음
- 말하는 내용보다는 실제로 관찰한 행동을 중요하게 고려해야 함
3. 참가자에게 무엇을 기대하는지 묻는다.
- 참가자가 버튼을 누르려고 하면, 그다음에 어떤 화면이나 내용이 나올 것 같은지 물어볼 것
- 버튼의 이름이 역할을 제대로 하는지 평가할 수 있음
4. '왜'라는 질문을 적극 활용한다.
- '왜' 그렇게 행동했는지, '왜' 그렇게 대답했는지 추가 질문
- 참가자의 태도와 생각을 알아낼 수 있음
- 알아차리기 힘든 니즈와 소망 엿볼 수 있음
5. 참가자의 실수에 집중한다.
- 실수를 바로 지적하지 않는 게 중요
- 참가자 스스로 인지할 때까지 기다릴 것
- 참가자가 알아차리지 못한다면 충분히 기다린 후, 어떤 생각으로 그렇게 행동했는지 물을 것
- 사람들이 기대하는 바와 프로덕트가 제공하는 경험 사이의 간극 발견
6. 비언어적 커뮤니케이션에 주목한다.
- 참가자의 목소리, 제스처, 표정 변화를 놓치지 않을 것
사용성 문제 찾기
1. 형성적 사용성 테스트 주의할 점
- 참가자 행동을 수량화하거나 일반화하지 않을 것
- 형성적 사용성 테스트 목적: 최대한 많은 사용성 문제를 밝히고, 무엇을 우선순위로 개선할 것인지 결정하는 것
- 우선순위 결정: 사용자 입장에서 문제가 얼마나 심각한지, 얼마나 자주 일어났는지 등, 팀 개발 현황, 비즈니스 상황도 감안해야 함
2. 이해관계자에게 사용성 문제 전달할 경우
- 사용성 심각도 등급(Usability Severity Rating) 이용 추천
- 심각성 정도 표기: 다음 우선순위 설정에 참고
출처: 사용자를 읽는 법 UX 리서치 플레이북(백원희 저)
출처
사용자를 읽는 법 UX 리서치 플레이북(백원희 저)
Jeff Sauro, "Rating the Severity of Usability Problems"
더 보기
#사용성테스트 #UX리서치
