[사용성 테스트 #2] 사용성 테스트 과제 시나리오 작성 방법

Usability testing: how do we design effective tasks의 글을 번역한 글입니다.

사용성 테스트 과제 시나리오 작성 방법

제품의 라이프사이클 전반에 걸쳐 사용성 테스트를 반복적으로 진행해야 합니다. 이 테스트는 간단한 종이 이미지에서부터 클릭 가능한 프로토타입, 완전한 시스템에 이르기까지 다양한 인터페이스를 포함합니다.

인터페이스의 사용성을 평가하기 위해, 사용자에게 해당 인터페이스를 사용해 특정 작업을 수행해 달라고 요청합니다. 수집한 데이터의 정확성을 높이기 위해, 실제 상황에서 사용자가 수행할 법한 작업들을 종합하여 만듭니다. 이렇게 함으로써 우리가 관찰하는 사용자 행동이 대표성을 가지게 되고, 우리가 찾고자 하는 문제도 실제 사용자들이 마주할 수 있는 문제들이 됩니다.

사용성 테스트 과제 시나리오 설계하기

처음 사용성 테스트에 대해 배웠을 때, 저는 “그냥 간단한 Task를 주고 사람들이 해결하게 하면 끝이구나!”라고 생각했습니다. 하지만 실제로 첫 번째 사용성 테스트를 해본 후, 상황이 전혀 다르다는 것을 깨달았습니다. 많은 질문이 생겼고, 어디서 시작해야 할지, 어떤 Task를 사용해야 할지 전혀 모르겠더군요. 고려해야 할 세부사항도 너무 많았습니다. 그래서 Task를 신중하게 설계하는 것이 정말 중요합니다.

이제 수백 번의 사용성 테스트를 경험한 저의 노하우를 여러분과 공유하고자 합니다. 효과적인 Task를 만드는 방법은 크게 세 가지 단계로 나눌 수 있습니다.

1단계: Task 정하기

하나의 과제 시나리오 Task를 작성하기 전에, 다음 단계를 먼저 진행해 보시기 바랍니다.

1) 사용성 테스트의 명확한 목표 세우기

특히 피드백이 필요한 주요 기능이나 영역을 정하는 것이 중요합니다. 사용성 테스트를 진행할 때는 디자인 팀의 관심사와 요구 사항을 파악하기 위해 그들과 직접 소통해야 합니다.

2) 디자인팀과 ‘함께 하기’

완전히 개발되지 않은 초기 프로토타입을 테스트할 때는, 그 프로토타입이 어떻게 작동하는지, 어떤 부분이 잘 작동하고 어떤 부분이 문제가 있는지를 파악하기 위해 디자이너와 함께 프로토타입을 검토하는 것이 중요합니다.

3) 최소 3번, Task별 인터페이스 살펴보기

첫 번째 점검에서는 전체적인 흐름과 인터페이스의 상호작용에 대한 개요를 파악할 수 있습니다.

두 번째 점검에서는 '사용자의 입장'에서 생각하며 인터페이스를 살펴보고, 사용자가 경험할 수 있는 모든 가능한 문제에 집중합니다. 이 단계에서 여러분이 사용할 잠재적인 Task를 일부 적기 시작할 수 있는데, 이는 평가해야 할 기능과 예상되는 문제 영역을 포함해야 합니다.

세 번째 점검에서는 인터페이스를 다시 살펴보면서 Task를 발전시키는 데 집중해야 합니다. 이 과정에서 여러분이 만든 Task를 평가하고, 필요에 따라 Task를 추가하거나 제거할 수 있는 기회를 갖게 됩니다. 모든 과정을 마친 후에는 작업할 수 있는 많은 잠재적인 Task 목록을 가지게 될 것입니다.

Dumas와 Fox(2008, p1131)는 사용성 테스트에서 사용할 Task 유형에 대해 잘 정리해 주었습니다. 이 내용은 우리가 사용성 테스트 과제에서 사용하는 것과 대부분 유사합니다. 아래에 그 내용을 소개합니다.

(1) 중요한 Task

자주 수행되거나 중요한 기능과 관련된 태스크입니다.

(2) 어려움이 예상되는 Task

평가자가 사용자가 어려움을 겪을 것이라고 생각하는 Task입니다.

(3) 철저한 시스템 조사를 요구하는 Task

시스템의 깊은 부분까지 들어가야만 완료할 수 있는 Task나, 여러 링크나 지름길을 활용하는 Task입니다.

(4) 비즈니스 목표에 영향을 미치는 Task

비즈니스 목표에 중요한 영향을 미치는 Task입니다.

(5) 재디자인된 영역을 살펴보는 Task

새롭게 디자인 된 부분을 평가하는 Task입니다.

(6) 새로운 기능과 관련된 Task

추가된 새로운 기능을 테스트하는 Task입니다.

이 단계에서는 Task 설명을 어떻게 작성해야 할지 고민할 필요가 없습니다. 대신, 여러분이 점검해야 할 모든 부분이 Task에 포함되어 있는지 확인하는 것이 중요합니다

2단계. Task 섬세하기 만들기 

Task의 세밀함은 사용성 테스트의 신뢰성, 타당성, 그리고 데이터의 유용성을 결정합니다. 따라서 이 부분을 제대로 진행하는 것이 매우 중요합니다. 다음 사항들을 반드시 고려해야 합니다.

1. 테스트 구성 방식 

Task는 다음 두 가지 방식 중 하나로 분류해야 합니다.

1) 직접 Task 또는 시나리오 Task

2) 열린 Task 또는 닫힌 Task

여러분은 어떤 방식을 언제 사용해야 할지 결정해야 합니다.

1) 직접 Task 또는 시나리오 Task  

시나리오 태스크는 작은 사용자 스토리처럼 구성됩니다. 일반적으로 캐릭터, 상황, 목표 달성을 위한 필수 세부사항이 포함됩니다. 반면, 직접 Task는 완전히 지시적입니다. 

<시나리오 Task>

"여러분은 토요일에 저녁 파티를 열 계획입니다. 그래서 BBC 푸드 웹사이트에서 치킨 카레 레시피를 찾고 싶습니다."

반면, 직접 Task는 다음과 같은 시나리오로 구성됩니다.

<직접 Task>

"BBC 푸드 웹사이트에서 치킨 카레 레시피를 찾아보세요."

위의 두 가지 유형 중에서, 우리는 보통 테스트에 시나리오 Task를 사용합니다. 이는 참가자들이 쉽게 이해할 수 있는 실제 상황을 모방하기 때문에, 그들이 보다 자연스럽게 행동할 수 있게 도와줍니다. 이렇게 하면 사용자 테스트의 부자연스러움을 크게 줄일 수 있습니다.

<시나리오 Task 예>

"여러분의 무고한 여동생이 이번 토요일에 결혼을 하기로 했는데, 예비 신랑이 이미 결혼했다는 소식을 들었습니다! 여동생을 구하기 위해 가능한 한 빨리 비행기 티켓을 예약하고 싶습니다."

2) 닫힌 Task 또는 열린 Task

닫힌 Task는 참가자가 해야 할 일에 초점을 맞추고 있습니다. 이 유형의 Task는 하나의 정답만 존재하기 때문에, 참가자가 Task를 성공적으로 해결했는지 실패했는지를 쉽게 측정할 수 있습니다. 가장 일반적으로 사용되는 방식입니다. 예를 들어, 휴대폰으로 전화하는 방법을 테스트하고 싶다면

<닫힌 Task 예>

"내일 월세를 내겠다고 집주인에게 문자하고 싶습니다. 그녀의 번호는 7921233290입니다."

열린 Task는 최소한의 정보만 제공하며, 사용자에게 원하는 행동에 대한 덜 구체적인 지침을 줍니다. 이렇게 하면 사용자가 시스템을 더 자유롭게 탐색할 수 있습니다. 이 방식은 사용자가 어떤 영역에서 지속적으로 상호작용하는지, 또는 어떤 부분에서 문제가 발생하는지를 파악하고 싶을 때 특히 유용합니다.

예를 들어, ABC.com 테스트에서 디자이너들이 사용자가 ABC에 대해 알아내는 데 가장 중요한 정보가 무엇인지 이해하고 싶다면, 열린 Task가 적합합니다. 저는 이 Task를 사용했습니다.

<열린 Task 예>

"여러분은 친구가 'ABC'라는 말을 하는 것을 들었습니다. 그래서 ABC가 무엇인지, 그리고 그것이 여러분에게 어떤 이점을 줄 수 있는지 궁금해졌습니다."

열린 Task를 사용할 때는 세 가지 주요 제약이 있습니다.

첫째, 참가자가 Task를 스스로 통제하기 때문에, 필요한 유저 피드백을 놓칠 수 있습니다. 반대로, 사용성 테스트의 핵심이 아닌 부분에 너무 많은 시간을 쏟을 수도 있습니다. 이 문제를 해결하기 위해 여러 개의 닫힌 Task를 준비해 특정 기능을 놓쳤을 때 보완할 수 있습니다.

둘째, 일부 참가자는 어디를 봐야 할지, 언제 Task를 완료했는지 불확실하게 느낄 수 있습니다. 또 다른 참가자들은 사용성 테스트를 빨리 끝내고 싶어 하여 충분히 노력하지 않을 수도 있습니다.

셋째, 열린 Task는 성공률을 측정할 수 없고 정답이 없기 때문에 성과 비교가 필요할 경우 적합하지 않습니다.

2. Task의 표현 

1) 유저를 특정한 답으로 유도하는 Task 단서는 피하세요.

Task를 만들 때, 참가자가 수행해야 할 행동이나 시스템에서 사용되는 용어가 포함되지 않았는지 확인하세요. 예를 들어, OO 사용성 테스트에서는 참가자가 모든 인형을 탐색하는 데 사용하는 '탐색' 링크를 이해하고 있는지 알고 싶었습니다. 그래서 우리는 참가자들에게 '당신은 인형을 탐색하고 싶다'고 말하는 대신, 인형의 종류를 찾아보라고 요청했습니다.

2) 현실적이되 애매모호함은 피하세요.

Task는 실제 상황에서 수행할 수 있어야 하며, 그 설명은 명확해야 합니다. 애매모호한 표현은 피해야 합니다.

3) 적절한 수준의 디테일을 보장하세요.

참가자가 무엇을 해야 하는지 알 수 있도록 충분한 정보를 제공하되, 자연스럽게 탐색하는 데 방해가 되지 않도록 해야 합니다. 컨텍스트 설명은 너무 길지 않아야 하며, 그렇지 않으면 참가자는 집중력을 잃고 잊어버릴 수 있습니다.

닫힌 Task를 사용할 때는 참가자가 목표를 달성했는지 알 수 있을 만큼 구체적인지 확인해야 합니다. 예를 들어, '당신은 친구에게 사진을 보여주고 싶다'와 '당신은 친구에게 소 그림을 보여주고 싶다'라는 두 설명을 비교해보세요. 어떤 것이 더 나은가요? 첫 번째 설명은 목표가 불분명해서 참가자가 아무 사진이나 보여주고 Task를 완료했다고 생각할 수 있습니다. 이렇게 되면 사용성 문제를 놓칠 수 있습니다. 반면 두 번째 설명은 요구사항을 더 효과적으로 전달합니다. 이 경우, 참가자는 소 그림을 찾는 것이 목표가 되어, 네비게이션과 인터랙션을 평가할 수 있는 기회를 제공합니다.