사용성 테스트

사용성 테스트(UT)

사용자에게 특정 과업을 수행하도록 과제(Task)를 부여한 뒤 그 일을 진행하는 과정(행동)을 관찰하는 방법

• 의도한 서비스 시나리오대로 유저가 행동하는지 아닌지 알 수 있음
• 필수적인 컨트롤 요소를 인지/이해/예측/실행 하는지 알 수 있음
• 이외의 다양한 컨트롤 요소를 인지/이해/예측/실행 하는지 알 수 있음

---

✅ 사용성 평가는 유저를 평가하는 것이 아니다.

• 사용자가 기능을 통해 다음 단계 진행을 할 수 있는가? 할 수 없으면 문제점이 무엇인가?
• 고객이 우리가 제공하고 있는 서비스의 구조와 기능을 의도한 대로 인지/이해/예측/실행 할 수 있는가?

---

✅ 사용성 테스트 진행 프로세스

• 회사에서의 리서치 진행 프로세스
  

• 사용성 테스트의 일반적 과정

  1. 참여자를 모집한다.
  2. 우리의 서비스를 사용해 보도록 한다.
  3. 진행자는 참여자가 길을 잃지 않도록 안내한다.
  4. 참관자들은 고객의 행동을 관찰한다.
  5. UT가 끝나면 도출된 이슈에 대해 브리핑한다.
  6. 빠르게 개선한다.
  7. 반복한다.

---

✅ Agile하게 리서치 하기

• 꼭 정석적인 사용성 테스트를 할 필요는 없다
  • UT는 정성적 테스트이며, 무언가를 증명하는 것이 아니다.
  • 애자일 테스트에서는, 인사이트를 얻기 위해 절차의 변경이 가능하다.
  • 기본적으로 진행자(moderator)는 참여자의 생각을 말로 표현하도록 유도한다.
• 사용성 테스트는 누구나 해도 된다
  • 모든 프로덕트에는 문제가 있고, 누가 사용성 테스트를 하던지 간에 심각한 문제는 쉽게 발견된다.
  • 다만 프로덕트의 사용성 문제는 그 프로덕트를 만드는 사람 스스로 발견하기 어렵다. (이미 어떻게 작동하는지, 작동 될지 알기 때문이다.)
  • 때문에 우리의 프로덕트와 관련이 없는 사람들을 대상으로 사용성 테스트를 해야한다.
• 하지만 왜 안하는가?
  • 대부분의 사람들이 사용성 테스트 경험이 없으며, 때문에 중요성을 모른다.
  • 시간이 부족하거나 우선 만들어놓고 나중에 수정하자고 하거나, 완성되지 않은 결과물이라며 보여주기를 꺼려한다.

---

✅ Agile하게 리서치 하기

큰 규모의 프로젝트와 애자일 프로젝트에서의 사용성 테스트 비교

사용성 테스트 참여자는 몇 명을 모집해야 할까?

위 지표는 참여자 수에 따른 문제점을 찾을 확률을 나타내는 표이다.

---

✅ 온라인 vs 오프라인

기존의 리서치 방식은 참여자를 초청하여 Off-line에서 대면으로 진행했다.

• 장점 : 참여자의 표정과 행동을 직접 관찰할 수 있다.
• 단점 : 참여자 리크루팅 소요시간이 길고, 오프라인 특성상 비용이 많이 든다.

On-line UTsms Off-line의 단점을 일부 보완하여 비대면 형태로 진행이 가능하다.

---

✅ 스티브 크룩의 사용성 원칙 TOP3

제 1법칙

• 사용자를 고민에 빠뜨리지 마라!
  • 모든 페이지는 쉽고 분명해야 한다.
  • 사용자는 작동방식까지 이해하려 하지 않는다. 적당히 임기응변한다.

제 2법칙

• 고민없는 명쾌한 클릭이라면 클릭 수는 중요하지 않다.
  • 고민없는 세번의 클릭이 심사숙고 해야하는 한번의 클릭보다 낫다.
  • 사용자는 최선의 선택을 하지 않는다. 최소 조건만 충족되면 만족한다.

제 3법칙

• 불필요한 단어는 삭제하라.
  • 쓸데없는 말을 줄이고 본론부터 얘기해라.
  • 사용자는 페이지를 읽지 않고 훑어본다.

---

✅ 사용성 테스트 단계별로 알아보기

⭐ part 1

• UT 문제 정의

  • 문제 정의는 사용성 테스트에서도 가장 중요한 부분이다.
    무엇에 대해 테스트 할지, 누구에게 어떻게 질문할지 등을 고려하는 단계

• 초보자가 문제 정의 단계에서 자주 하는 실수

  • 데이터를 그저 반복해서 수집
  • 깊은 분석 없이 일반적이고 피상적인 분석이나 단순한 설문을 진행
  • 질문을 작성할 때 깊이 고민하지 않음
  • 이미 다들 알고 있는 내용을 정리할 뿐

• 사용성 테스트 문제 정의(좀 더 명확한 문제 정의를 위해서)

  • 내가 해결하고자 하는 문제에 직접 연관된 사람(고객)을 만나서 인터뷰 해보자
  • 해결하고자 하는 문제의 구조를 분해해보자
  • 구체적으로 어떤 데이터를 살펴봐야 할지 고민해보자
  • 실제 문제를 분석하기에 앞서 현 상황에서 고객의 상황을 시뮬레이션 해보자
  • 고객 행동에 대한 가설을 세워보자

💬 실습을 위한 팁

내가 개선하고자 하는 프로덕트/서비스를 하나 선택하여 그에 대한 문제 정의를 해보고 리서치 계획을 세워보자

• 데스크 리서치
  • 데스크 리서치는 서비스와 관련된 외부 상황(트렌드, 시장환경 변화)부터 서비스의 내부 상황(조직, 협업 구조, 서비스 시스템)까지 다방면으로 서비스가 놓여있는 상황을 파악하기 위한 방법론
  • 문제 정의 단계에서는 내가 해결하고자 하는 문제에 직접 연관된 사람을 만나봤다면, 데스크 리서치에서는 다른 사람이 리서치 한 것을 찾고 검토하는 것
  • 내가 개선하고자 하는 서비스에 대한 통계 분석/트렌드 분석/벤치만킹/사용성 평가/VOC분석 등 을 수행하는데, 회사에서 직접 데이터를 얻을 수 없다면 논문, 기사, 리포트, 자료 등 여러 방면으로 찾아보자
  • 최상의 리서치는 사용자/사용자의 환경/서비스의 목표 3가지 관점이 겹치는 지점이다.
    • 서비스를 이용하는 사용자는 누구인지 파악해보자
    • 그 사용자가 서비스를 사용하는 환경과 맥락은 무엇인지 파악해보자
    • 서비스가 목표로 하는 것은 무엇인지 파악해보자

💬 실습을 위한 팁

내가 개선하고자 하는 프로덕트/서비스에 대한 문제 정의가 어느정도 되었다면 현황을 파악하기 위한 데스크 리서치를 수행해보자

• 이해관계자 인터뷰

  • 회사에서 일하다 보면 타 부서로부터 요청받은 리서치를 단순히 설계하거나, 피상적인 사용성 테스트를 하는 것에서 그치거나, 가끔은 높으신 분들이 정한대로 진행되기도 한다.
    하지만 리서처는 회사의 이해관계자들이 이야기하는 것이 정답이라고 생각하지 말고 항상 의심하자
  • 대부분의 이해관계자는 솔루션 두출을 하고싶어 하고 빠르고 쉬운 해결책을 얻고 싶어한다.
  • 그들은 아직 문제가 무엇인지 잘 알지 못할 수 있기 때문에 관점을 바꾸어보자

• 리서처가 이 단계에서 해야할 일

  • 이해관계자에게 issue or task 목록 작성을 요청해보자
  • 이슈 논의는 항상 함께 공유되어야 한다
  • 주요한 이슈를 추리고 그 중에서 가장 중요한 것을 함께 논의해보자
  • 이해관계자의 기분을 나쁘게 하는 커뮤니케이션을 자제하자
  • 논의 전에는 항상 어떤 내용에 대해 이야기 할 것인지 미리 주제를 전달해주자

💬 실습을 위한 팁

내가 개선하고자 하는 프로덕트/서비스를 직접 만들고 있는 사람을 찾기 어렵다면, 내가 이 서비스를 기획하는 사람이라고 가정하여 이슈 목록을 작성하고 그 중 서비스의 목표에 부합하는 우선순위 이슈를 찾아보자

• 사용성 테스트 Task 작성하기
  • 각 화면, 세부 영역 별로 사용자가 할 수 있어야 하는 Task를 작성해보자
  • 문제 정의와 데스크 리서치 등에서 수집한 정보를 바탕으로 현재 해결해야 할 문제에 집중한다.
  • Task 작성은 처음에는 브레인 스토밍을 통하여 아이디어를 수집하고 우선순위 작업을 통해 먼저 확인할 내용을 정리한다.

---

⭐ Part 2

• 리서치 대상자 선별

  • 리서치 대상자를 아무나 해도 된다고 생각하면 안된다.
  • 모든 사람을 위한 서비스라고 해도 내가 해결하고자 하는 문제에 집중된 사용자를 찾아야 한다.
  • 가장 좋은 것은 고객 데이터를 보유하여 인구통계학적 정보나 고객의 행동데이터를 통해 선별하는 것이지만, 그 작업이 힘든 경우는 직접 사용자 그룹을 구분하는 작업을 해보자.

• 리서치 대상자 선별

  • 리서치 대상 그룹을 4가지 축으로 구분하여 리서치 대상 선별의 우선순위를 살펴보자

여기에서 대상 고객은 앞서 문제 정의/데스크 리서치/이해관계자 인터뷰 등의 과정에서 발견한 정보를 기반으로 선정해야 한다.

💬 실습을 위한 팁

앞서 수집한 정보들을 기반으로 리서치 대상에 적합한 고객들의 특성을 정의해보자(연령대, 서비스 이용 패턴, 고객의 니즈 등)

• 리서치 참여자 사전동의

  • 리서처는 항상 리서치에 참여하는 고객에 대해 사전 동의를 받아야 한다.
    • 사용성 테스트 시 화면 녹화, 녹음에 대한 동의
    • 비밀 유지에 대한 동의
    • 개인 정보 수집 및 이용에 대한 동의
  • 참여 동의 과정의 효과
    • 공식적인 과정을 거침으로써 참여자가 걱정하는 부분들을 안심시켜 참여자의 긴장을 완화
    • 리서치 과정을 설명하고 목적을 분명히 함으로써 리서치에 대한 공감대를 높일 수 있다.

• 리서치 참여자 모집하기

  • 참여자 선별 후 대상자에게 참여 여부/리서치 일정/리워드 등을 안내
  • 사용성 테스트 진행 시 필요한 준비를 미리 안내(앱 설치 또는 원격 연결 등)
  • 화면을 함께 보면서(미러링) 전화로 진행하는 경우 이어폰을 준비하도록 함
  • 조용한 장소에서 진행하도록 요청하며, 이동 중/운전 중에는 진행이 불가함을 안내
  • 대면으로 진행할 경우에는 조용한 회의실 등에서 주변 소음에 방해받지 않도록 진행

• 사용성 테스트 진행하기

  • 모든 준비가 되었으면 일정에 맞춰 사용성 테스트를 진행한다.
    • 원격으로 진행할 경우 모니터 화면을 녹화하는 프로그램을 미리 설치
    • 대면으로 진행할 경우에는 참여자의 반응을 자세히 살피기 위해 녹화 장비 등을 미리 준비
    • 작성된 Task를 바탕으로 테스트를 수행하고 별도의 인터뷰를 섞어 진행할 수 있다.

💬 진행자로서 저지르는 실수

• 말을 너무 많이 하지 마라
• 디자인을 설명하지 마라
• 참여자의 질문에 답변하지 마라
• 자꾸 인터뷰를 하려고 하지말고 사용성 테스트를 하라
• 대답을 유도하거나 선호도를 묻지 마라

• 결과 정리 및 리뷰
  • 애자일한 사용성 테스트에서는, 각 세션이 끝난 후 발견한 이슈에 대해 짧게 요약한다.
  • 모든 세션이 끝난 후에는 사용성 테스트에 참관한 사람들에게 브리핑을 한다.
  • 빠르게 다음 사용성 테스트를 준비 할 것인지 아니면 깊은 분석을 할 것인지 의사결정을 진행한다.
  • 위 과정이 끝난 이후에는 결과를 분석하여 이후 Action Item을 도출한다.
  • 별도의 리뷰 세션을 통해 결과를 리뷰하고 다음 스텝으로 향하자