사용성 테스트 보고서: 문제를 녹화와 연결하는 방법

보고서는 관찰에서 시작합니다

‘참여자가 탐색 방식을 마음에 들어 하지 않았다’는 말로는 무엇을 고쳐야 할지 알 수 없습니다. 녹화를 보면 반품 기능을 찾으려고 결제 메뉴를 세 번 열고 도움을 요청했을 수 있습니다. 이는 특정 과제에서 재현할 수 있는 문제입니다.

인터페이스 버전, 기기, 시나리오, 성공 기준, 진행자의 지원 등 테스트 조건을 남기세요. 조건이 빠지면 팀이 프로토타입의 문제를 실제 제품의 오류로 보거나 힌트를 받아 성공한 과제를 혼자 해결한 것으로 볼 수 있습니다.

세션에서 검증 가능한 발견 사항을 정리하세요

1. 중요한 장면을 표시하세요

   각 세션에서 과제 시작, 어려움, 작업 재개, 결과를 표시합니다. 전사문을 화면 녹화와 대조하세요. ‘클릭했어요’라는 말이 실제 클릭과 항상 일치하지는 않습니다. 행동 전후의 타임코드를 남겨 맥락을 볼 수 있게 하세요.

2. 관찰과 해석을 구분하세요

   관찰란에는 행동과 결과를 적으세요. 추정 원인은 별도 항목에 적습니다. ‘결제 메뉴에서 반품 기능을 찾았다’는 관찰입니다. ‘메뉴 이름이 불분명하다’는 다음 인터페이스에서 검증할 수 있는 가설입니다.

3. 비슷한 사례를 비교하세요

   비교할 수 있는 과제에서 같은 문제가 나온 경우에만 사례를 묶으세요. 몇 명이 그 문제를 겪었고 몇 명이 해당 과제를 수행했는지 표시합니다. 소규모 조사에서 나온 비율을 전체 제품 사용자에게 그대로 적용하지 마세요.

4. 조치와 검증 방법을 정하세요

   과제가 중단됐는지, 도움이 필요했는지, 추가 단계를 거쳐야 했는지 평가하세요. 제품 상황에 맞춰 우선순위를 합의합니다. 제안한 변경이 효과가 있었는지 다음 테스트에서 어떤 관찰 가능한 결과로 판단할지 적습니다.

사용자가 주문을 반품할 방법을 찾습니다

아래는 가상의 교육용 예시입니다. 명칭, 조건, 결과는 방법을 설명하기 위한 것입니다.

발언 하나만으로 화면에서 일어난 일을 알 수는 없습니다. 예시의 녹화에서는 결제 메뉴를 두 번 열었고 진행자가 힌트를 줄 때까지 과제가 중단됐습니다. 프로토타입 버전과 함께 문제 카드에 적으세요.

주문 상세에 링크를 넣는 것은 검증할 제안입니다. 다음 테스트에서 참여자가 도움 없이 기능을 찾고 어느 주문을 반품하는지 이해하는지 확인합니다.

보고서용 문제 카드

카드를 먼저 만들고 주요 장애물을 짧게 요약하세요. 결론이 테스트 자료와 연결된 상태로 남습니다.

짧은 문제 제목:
버전 / 기기 / 과제:
참여자와 타임코드:
관찰한 행동:
과제에 미친 영향:
진행자의 도움 여부:
비슷한 세션에서의 반복:
추정 원인:
우선순위와 근거:
제안하는 변경:
결과를 검증하는 방법:

보고서를 바탕으로 조치할 수 있는지 확인하세요

• 중요한 발견 사항을 녹화에서 찾을 수 있습니다.
• 과제를 스스로 완료했는지 알 수 있습니다.
• 원인은 가설로 표시돼 있습니다.
• 제안에 다음 테스트의 검증 기준이 있습니다.