[기초/이론] 사용성 테스트 알아보기

사용성 테스트 (Usability Test)

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

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

 

사용성 평가 (Usability Test) ≠ 유저 테스트 (User Test)

사용성 평가는 우리의 제품을 평가하는 것이지 사용자를 평가하는 것이 아니다.

• 사용자가 OOO(기능)을 통해 XXX(다음 단계 진행)을 할 수 있는가? 할 수 없다면 문제점은 무엇인가?
• 고객(User)이 우리가 제공하고 있는 서비스의 구조와 기능을 의도한 대로 인지 / 이해 / 예측 / 실행 할 수 있는가?
• 인지 : 사용자가 눈으로 확인/발견 하였는가
• 이해 : 사용자가 무엇이라고, 또는 어떤 의미로 이해하였는가
• 예측 : 무엇을 하는 기능인지, 또는 다음 화면을 어떻게 예상하였는가
• 실행 : 예측과 일치하지 않는 부분 or 일치하지 않는 부분

 

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

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

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

 

꼭 정석적인 사용성 테스트를 할 필요는 없다

• UT는 정성적 테스트이며, 무언가를 증명하는 것이 아니다.
• 애자일 테스트에서는, 인사이트를 얻기 위해 절차의 변경이 가능하다.
• 기본적으로 진행자(moderator)는 참여자의 생각을 말로 표현하도록 유도한다.

 

사용성 테스트는 누구나 해도 된다

• 모든 프로덕트에는 문제가 있고, 누가 사용성 테스트를 하던지 간에 심각한 문제는 쉽게 발견된다.
• 다만 프로덕트의 사용성 문제는 그 프로덕트를 만드는 사람은 스스로 발견하기 어렵다(이미 어떻게 작동하거나, 작동 될지 알기 때문에)
• 때문에 우리의 프로덕트와 관련이 없는 사람들을 대상으로 사용성 테스트를 해야 한다.

 

그런데 왜 안하는가?

• 대부분의 사람들이 사용성 테스트 경험이 없으며, 때문에 중요성을 모른다.
• 시간이 부족하다거나, 우선 만들어놓고 나중에 수정하자고 하거나, 완성되지 않은 결과물이라며 보여주기를 꺼려한다거나 한다. 이 것은 분명 잘못된 것이다.

 

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

 

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

3명이면 충분하다. 사용자 테스트 수가 늘어날 수록 문제를 찾는 것이 100%에 수렴하지만 완만한 곡선이다. 3명으로만으로도 75%의 문제를 찾을 수 있다. → 즉, 3명의 테스트를 여러번 하는게 더 효율적이다.

 

Online UT vs Offline UT

기존의 리서치 방식은 참여자를 초청하여 Off-line에서 대면(Contact) 형태로 진행

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

On-line UT는 Off-line의 단점을 일부 보완하여 비대면(Untact) 형태로 진행이 가능

 

스티브 크룩의 사용성 원칙 TOP 3

• 제 1법칙 : 사용자를 고민에 빠뜨리지 마라! 모든 페이지는 쉽고 분명해야 한다. 사용자는 작동방식까지 이해하려 하지 않는다. 적당히 임기응변한다.
• 제 2법칙 : 고민없는 명쾌한 클릭이라면 클릭 수는 중요하지 않다. 고민없는 세번의 클릭이 심사숙고 해야하는 한 번의 클릭보다 낫다. 사용자는 최선의 선택을 하지 않는다. 최소 조건만 충족되면 만족한다.
• 제 3법칙 : 불필요한 단어는 삭제하라. 쓸데없는 말을 줄이고 본론부터 얘기해라. 사용자는 페이지를 읽지않고 훑어본다.