사용성 테스트 과제 시나리오 작성 방법
사용성 테스트 과제 시나리오 작성 방법
사용성 테스트 과제 시나리오 구성 방법의 글을 번역한 글입니다.
저희는 제품의 라이프사이클 전반에 걸쳐 사용성 테스팅을 반복적으로 시행합니다. 종이 이미지만큼 간단한 것부터 클릭 가능한 프로토타입, 완전 구동되는 시스템까지 테스트하는 인터페이스의 범위는 다양할 수 있습니다.
인터페이스의 사용성을 평가하기 위해서는, 유저에게 인터페이스를 이용해 여러 태스크를 수행해달라고 요구합니다. 우리가 모으는 데이터가 정확하기 위해서, 실생활 맥락에서 사용자가 할 만한 것들을 종합하여 만든 태스크를 사용합니다. 즉, 우리가 관찰하는 유저 행동은 대표성을 가지고 있으며, 우리가 찾는 문제는 유저가 실제 마주할 수 있는 문제들인 것이죠.
테스팅 태스크 설계하기
제가 처음 사용성 테스팅에 대해서 배웠을 때, 저는 “간단하네. 그냥 태스크를 써서 사람들한테 해결해보라고 하고, 그럼 끝이네!”라고 생각했었습니다. 하지만, 제 생애 첫 사용성 테스팅을 해본 후에, 전혀 그렇지 않다는 것을 깨달았죠. 너무나 많은 질문거리가 생겼었습니다. 어디서 시작해야 하거나 어떤 태스크가 이용되어야 하는지도 알지 못했고, 생각해봐야 할 수많은 세부사항이 있었습니다. 여러분은 반드시 태스크를 신중하게 짜야합니다.
자, 이제 수백 번의 사용성 테스팅을 해봤기 때문에, 효과적인 태스크를 만드는 방법에 대한 제 경험을 여러분과 공유하고자 합니다. 여기에는 크게 3가지 단계가 있습니다:
태스크 정하기
태스크 섬세하게 만들기
1단계: 태스크 정하기
앉아서 한 세트의 태스크를 작성하기 전에, 다음 단계를 먼저 거쳤으면 합니다.
테스팅의 명확한 목표 세우기
특히 피드백을 받아야 할 메인 기능/영역이 무엇인지 정하기. 사용성 테스팅을 시행할 때는 언제나 디자인 팀의 포커스와 니즈가 무엇인지 알기 위해 그들을 직접 만나야 합니다.
디자인팀과 ‘함께 하기’
완전히 만들어지지 않은 초기 프로토타입을 테스팅한다면, 그것이 어떻게 작동하고, 무엇이 작동하고 무엇이 작동하지 않는지 알기 위해 디자이너와 함께 프로토타입을 살펴보는 것이 중요합니다.
점검
최소 3번 테스트 인터페이스 살펴보기.
첫 번째 점검에서는 전반적인 플로우와 인터페이스의 인터랙션에 대한 아이디어를 얻습니다.
두 번째 점검에서는 ‘유저의 입장’이 되어보고 유저라면 할 행동에 대해 생각하면서 인터페이스를 살펴보고 그들이 경험할 수 있는 모든 가능 문제에 집중하는 것입니다. 바로 이 단계에서 여러분이 사용하게 될 잠재적 태스크의 일부를 적기 시작할 수 있는데, 이는 여러분이 평가해야 하는 기능, 예상되는 문제 영역 등을 커버해야 합니다.
세 번째 점검에서는, 다시 인터페이스를 살펴볼 때 태스크를 발전시키는 일에 집중해야 합니다. 이는 여러분이 만든 태스크를 평가해보고, 태스크를 추가하거나 제거하는 기회가 될 것입니다. 다 끝냈을 때, 여러분은 작업할 많은 잠재 태스크 뱅크를 가지게 될 것입니다.
Dumas and Fox (2008, p1131)가 사용성 테스팅에서 사용해야 할 태스크의 유형에 대해 매우 잘 서머리를 해주었습니다. 대부분 저희가 테스팅 세션에서 사용하는 것과 유사합니다. 그 내용은 다음과 같습니다:
중요한 태스크. 예를 들면 자주 수행되는 태스크 또는 중요한 기능과 관련된 태스크
평가자가 예상하기에 유저가 어려움을 겪을 것 같은 태스크
보다 철저한 시스템 조사를 하게 하는 태스크. 예를 들면 시스템 체계의 하부에서부터 찾아 들어가야만 성취할 수 있는 태스크, 또는 멀티 링크나 지름길이 있는 태스크
비즈니스 목표에 영향을 미치는 태스크
재디자인된 영역을 살펴보는 태스크
새롭게 추가된 기능과 관련된 태스크
이 단계에서, 여러분은 태스크 설명을 어떻게 적어야 할지 고민하지 않아도 됩니다. 대신, 여러분이 점검해야 할 모든 부분을 태스크에서 다루고 있는지 확인해야 합니다.
2단계. 테스크 섬세하기 만들기
태스크가 얼마나 섬세하게 만들어졌느냐가 사용성 테스팅의 신뢰성과 타당성, 그리고 데이터의 유용성을 결정합니다. 제대로 하는 것이 정말 중요한 것이죠. 여러분은 다음 사항에 대해 반드시 고려해야 합니다:
1. 사용될 태스크의 구성 방식
2. 태스크의 표현
1. 테스트 구성 방식
태스크들은 다음 두 구성 방식 중 하나로 분류되어야 합니다.
1) 직접 태스크 또는 시나리오 태스크
2) 열린 태스크 또는 닫힌 태스크
여러분은 무엇을, 언제 사용해야 하는지 결정해야 합니다.
1) 직접 태스크 또는 시나리오 태스크
시나리오 태스크는 미니 유저 스토리처럼 보입니다. 보통 캐릭터, 컨텍스트, 목표 달성에 필요한 필수 세부사항 등으로 구성됩니다. 반면, 직접 태스크는 완전히 지시적입니다.
<시나리오 테스크>
여러분은 토요일에 디너 파티를 주최하려 합니다. BBC food 사이트에서 치킨 카레 레시피를 찾고 싶습니다.
반면, 직접 테스크는 다음과 같이 시나리오로 구성합니다.
<직접 테스크>
BBC food 사이트에서 치킨 카레 레시피를 찾아라.
위 두 타입 중에서, 저희는 보통 테스팅에 시나리오 태스크를 이용합니다. 왜냐하면 참가자가 쉽게 이해할 수 있는 실제 맥락을 모방하기 때문에, 결과적으로 그들이 보다 자연스럽게 행동할 수 있기 때문입니다. 이는 유저 테스팅의 부자연스러움을 크게 완화할 수 있도록 도와줍니다.
<시나리오 테스크 예>
"여러분의 죄 없는 여동생이 이번 토요일에 결혼을 하는데, 예비 신랑이 이미 결혼을 했다는 소식을 들었다! 여동생을 찾아 구하기 위해 가능한 한 빨리 비행기 티켓을 예약하고 싶다."
2) 닫힌 태스크 또는 열린 태스크
닫힌 태스크는 참가자가 해야 하는 것에 특화되어 있습니다. 이런 유형의 태스크는 하나의 정답을 가지고 있으며, 그렇기 때문에 참가자가 태스크를 해결했는지 실패했는지 측정할 수 있습니다. 가장 흔하게 사용되는 구성 방식이죠. 예를 들어, 폰의 전화통화 방법을 테스트하고 싶다면,
<닫힌 태스크 예>
내일 월세를 내겠다는 말을 하기 위해 집주인에게 문자를 하고 싶습니다. 그녀의 번호는 7921233290입니다.
열린 태스크는 최소한의 정보를 가지고 있으며, 여러분이 유저가 했으면 하는 것에 대한 덜 구체적인 방향을 가지고 있습니다. 이는 유저가 시스템을 탐색할 수 있는 자유를 더 많이 줍니다. 유저가 지속적으로 인터랙트 하는 영역이 어디인지, 또는 그들에게 가장 문제가 되는 것이 무엇인지 찾아내고 싶을 때 특히 유용합니다.
예를 들어, ABC.com 테스팅에서 디자이너들이 유저가 ABC에 대해 알아내는 데 가장 중요한 정보가 무엇인지 이해하고 싶다고 합니다. 이 경우, 열린 태스크가 적절합니다. 저는 이 태스크를 이용하였습니다.
<열린 테스크 예>
여러분은 친구가 ‘ABC’라는 걸 언급하는 것을 들었습니다. 여기에 관심이 생겨서 ABC가 무엇인지, 그것이 여러분에게 무엇을 줄 수 있는지 알고 싶습니다.
열린 태스크를 사용하는 데는 세 가지 주요 제약사항이 있습니다.
참가자가 태스크를 통제하기 때문에, 유저 피드백이 요구되는 기능을 놓칠 수도 있고, 그 반대로 테스팅의 요점이 아닌 부분에서 너무 많은 시간을 보낼 수도 있습니다. 해결책은 여러 닫힌 태스크를 준비하여 참가자가 특정 기능을 커버하지 않을 때 사용하는 것입니다.
일부 참가자는 어디를 봐야 하는지, 언제 태스크를 완료하였는지에 대해 불확실하게 느낄 수도 있습니다. 또 다른 참가자들은 테스트를 끝내는 데 관심이 있어서 실제 하는 만큼 노력하지 않을 수도 있습니다.
열린 태스크에는 태스크 성공률을 매길 수 없으며, 정답이 없기 때문에 퍼포먼스 비교가 필요하다면, 적합하지 않은 방법입니다.
2. 테스크의 표현
1) 유저를 답으로 유도하는 태스크 단서는 피하세요.
태스크를 만들 때 관련 행동을 해결하는 태스크나 시스템에서 사용되는 용어가 들어가지 않았는지 확인하세요. 예를 들어, OO 테스팅에서는, 참가자가 모든 인형을 탐색하는데 이용하는 ‘탐색’ 링크를 이해하고 있는지 알고 싶었습니다. 저희는 참가자들에게 ‘당신은 인형을 탐색하고 싶다’고 말하는 대신, 인형의 유형을 찾아보라고 요구했습니다.
2) 현실적이되 애매모호함은 피하세요.
태스크는 실제 컨텍스트에서 수행될 수 있는 것이어야 하며, 그 묘사는 애매모호하게 해서는 안됩니다.
3) 적절한 수준의 디테일을 보장하세요.
참가자가 자신이 무엇을 해야 하는지 알 수 있는 정도의 충분한 정보를 넣어야 하지만, 자신들이 실제 자연스럽게 탐색하는 것을 방해하지 않는 정도여야 합니다. 컨텍스트에 대한 묘사는 너무 길면 안 됩니다. 그렇지 않으면 참가자는 집중력을 잃고 잊어버리게 될 것입니다.
닫힌 태스크를 이용할 때는, 참가자가 자신이 목표를 달성했을 때 이를 알 수 있을 만큼 충분히 구체적인지 확인해야 합니다. 예를 들어, ‘당신은 친구에게 사진을 보여주고 싶다’와 ‘여러분은 친구에게 소 그림을 보여주고 싶다’라는 두 묘사 사이의 차이점을 비교해보세요 – 어떤 것이 더 낫나요? 전자에서는, 목표가 불분명해서, 유저는 그냥 첫 번째 사진이나 아무 사진을 보여주고는, 태스크를 완료했다고 생각할 수 있습니다. 그 결과, 사용성 문제를 놓치게 될 것입니다. 후자에서는, 태스크가 요구사항을 보다 효과적으로 전달합니다. 태스크는 그들이 소 그림을 찾았을 때 달성되는 것이죠. 무엇보다도, 참가자가 관련 사진을 찾아다녀야 하기 때문에, 이는 저희가 네비게이션과 인터랙션을 더 평가할 수 있는 기회를 제공해줍니다.
