사용성 테스팅의 허드렛일 하기
사용성 테스트 배우기 #16
사용성 테스팅의 허드렛일 하기
사용성 테스팅의 허드렛일 하기 전문을 번역하였습니다.
“일찍 그리고 자주 테스트하라”는 오래된 격언을 모두 들어보셨을 겁니다. 하지만 누군가에겐 사용자 테스팅이 벅찬 과제일 수도 있습니다. 참가자를 모으고, 실제 테스트를 하고, 기록하고, 결과를 분석해야 하죠. 굳이 언급하지 않더라도, 피드백을 이해하고, 행동을 취하기 전에 무엇을 우선수위로 둬야 하는지 밝히는 것은 말할 것도 없습니다. 그리고 이것들이 허드렛일처럼 느껴질 수도 있습니다.
이번 포스트에서는, 테스트를 진행하는 동안 발견한 것들이 제대로 문서화되었는지 확인하고, 더 나은 사용자 경험을 만드는 해결책으로 바꾸는 방법을 낱낱이 살펴보겠습니다.
즉, 이 글은 “어떻게” 사용자 테스팅을 하는지에 대한 가이드가 아닙니다. 만일 사용자 테스트를 수행하는 방법에 대해 더 알고 싶다면, UXPin의 무료 e북 The Guide to Usability Testing을 확인해보세요.
정형적 방법론 vs 린 방법론
제가 커리어를 쌓기 시작했을 때, 모든 것은 큰 리포트에 매우 정형적으로 기록되어, 긴 시간이 걸리는 프레젠테이션으로 클라이언트에게 보였습니다. 제게는, 정형적 문서화와 여러 페이지의 산출물이 행동보다는 토론을 독려했었습니다만, 이 부분에 대해선 나중에 다루도록 하겠습니다. 이것이 그 옛날에 제가 일을 했던 방식이었죠. 오늘날, 제겐 토론 말고 행동이 가장 중요합니다.
Image Credit: Opensource.com, Creative CommonsTrade Me에서 근무한 후, 저는 뉴질랜드의 UX 디자인 컨설팅 선도 회사이자 최근 Price Waterhouse Coopers에 인수된 Optimal Experience로 옮겼습니다. 우리는 최근에 정형적 접근법에서 떠나 Google Venture’s design sprints에 적응하고 있습니다. 뉴질랜드의 어느 누구도 이런 작업을 하고 있는 것 같지 않은데, 이는 우리 팀이 이 전력질주하는 방법의 선구자가 될 수 있게 해 주고 있습니다.
c우리는 일을 하는 새로운 방법을 발견했고 토론보다 행동을 하는 최고의 방법을 발견했습니다. “준비, 조준, 발사” 보다는 “준비, 발사, 조준”을 하는 경우가 훨씬 많아졌습니다. 하지만 이렇게 하다 보면 훨씬 빠르게 배우게 됩니다.
덧붙여, 우리가 정형적인 환경과 린 환경에서 모두 어떻게 “허드렛일을 했는지” 살펴봅시다.
훌륭한 테스팅 문서화는 준비가 필요하다
훌륭한 문서와 해결책을 만드는 것은 사용성 테스팅을 준비할 때 시작됩니다. 맛있는 식사와 같은 것이죠. 미리 고기를 손질하고 채소를 잘라놓고, 재료를 준비하지 않으면, 훌륭한 맛을 낼 수가 없습니다. 사용성 테스팅 문서화도 마찬가지입니다. 만일 미리 모든 것을 정리해두지 않으면, 안 됩니다.
Photo Credit: Thomas Link, Creative Commons제일 중요한 걸 맨 먼저 해야 합니다. 참여하는 모든 사람의 역할을 정리해야만 합니다. 사용자 테스팅 세션이 참여하는 사람에는 다음과 같은 유형이 있습니다.
참가자: 당신이 테스트하고자 하는 유저 퍼소나 중 하나를 대표하는 사람입니다. 유저 퍼소나를 만드는 것에 대해 더 많은 것을 알고 싶다면, UXPin가 이 주제에 대해 다룬 글을 보시면 됩니다.
퍼실리테이터: 참가자와 함께 프로세스를 촉진하는 역할을 맡은 사람입니다. 퍼실리테이터는 질문을 하고, 진짜 문제를 발견하기 위해 캐묻고, 테스트를 최대한 현실처럼 느껴지도록 만듭니다.
서기: 테스팅 세션이 진행되는 동안 참가자가 하는 말, 참가자가 하는 행동, 퍼실리테이터가 던지는 질문 등 모든 것을 기록하는 역할을 맡은 사람입니다. 이것이 안전망이 되기 때문에 매우 중요합니다. 이 노트는 언제 무엇이 알고 싶을 때 첫 번째로 확인할 수 있는 것입니다.
클라이언트: 클라이언트가 유저 테스트를 참관하게 하는 것은 매우 중요합니다. 참가자가 그 제품을 가지고 얼마나 고생을 하는지 직접 볼 수 있는 기회죠. 그들이 제품을 개선하게 하는 데 동기부여가 될 것입니다.
디자이너와 개발자: 반드시 그 제품을 만들었던 디자이너와 개발자들이 참여하게 하고 싶을 것입니다. 자신들이 만든 것의 실패를 보는 것은 그들이 현실을 보고 유저의 관점에서 디자인하고 개발할 수 있도록 동기부여할 것입니다.
돌봄이: 클라이언트를 돌볼 사람이 있어야 합니다. 돌봄이는 클라이언트가 세션이 끝날 때까지 토론을 미루도록 하여 가능한 한 많은 것을 찾아 적는 일에 집중할 수 있도록 합니다.
Photo Credit: Nicholas Wang, Creative Commons당연히 여러분은 이 모든 사람들을 한 방에 모을 수 없을 것입니다. 때문에 스크린 쉐어링 소프트웨어를 준비하여 참가자의 기기에서 어떤 일이 일어나는지 클라이언트와 돌봄이, 서기가 있는 관찰자 방에 연결해주는 것이 좋겠죠.
테스팅 세션 동안 기록하기 위해 필요한 것
Photo credit: Rosenfeld Media, Creative Commons세션이 진행되는 동안, 클라이언트와 돌봄이는 가능한 한 많은 것을 찾아 포스트잇 노트에 받아 적을 것입니다. 각 노트는 그들이 찾은 것의 유형에 따라 색으로 구분되어야 합니다. 어떻게 하는 것인지 살펴봅시다.
긍정 =녹색: 예를 들어, 참가자가 별문제 없이 우리 서비스에 가입했을 때
부정 = 핑크: 예를 들어, 참가자가 쇼핑 카트를 찾지 못할 때
관찰(긍정도 부정도 아니지만 흥미로운 것) = 파랑: 예를 들어, 참가자가 검색 대신 탐색하여 제품을 찾을 때
찾은 것에 기반하여 포스트잇에 숫자 붙이기: 정확히 어떤 일이 일어났었는지 보기 위해 노트를 다시 찾아볼 때 도움이 될 것입니다. 어떤 퍼소나와 어떤 발견 내용이 연결되는지 찾을 때도 도움이 됩니다. 예를 들어, 온라인 쇼핑을 하지 않는 모든 참가자는 쇼핑 카트를 찾을 수 없었다.
한 노트에 하나의 발견 내용만 적기: 여러분이 찾은 것을 적었으면, 발견 내용 전용 면에 붙여 두세요. 큰 폼보드를 사용하면 좋습니다.
고려해볼 수 있는 다른 것들입니다.
세션 녹화:
스크린 캡쳐링 소프트웨어를 통해 세션을 기록하고 싶을 것입니다. 이것은 세션에 올 수 없었던 클라이언트와 이해관계자들과 공유할 수 있습니다. 헌신적인 필기해주는 사람이 있었다면, 비디오를 다시 볼 필요는 없을 것입니다.
클러스터 노트:
세션 사이에, 찾은 것을 기반으로 노트를 묶어보세요. 예를 들어, 진행하다 보면 긍정, 부정, 관찰과 관련하여 찾은 것들을 묶어볼 수 있을 것입니다. 발견 내용에 대한 토론은 세션 사이에 할 수 있습니다.
급하게 바꾸지 마세요: 클라이언트는 아마도 한 두 세션을 기반으로 디자인을 바꾸고 싶어 할 것입니다. 변화를 만들기 전에 더 많은 증거가 필요하다는 것을 상기시켜 주는 것이 여러분의 책임입니다. 4명의 참가자가 여러분이 변경 전에 테스트해야 할 최소한의 요건입니다. 4명의 참가자 후에 변화를 만들고자 한다면, 발견 내용은 정말 분명해야만 합니다. 예를 들어, 참가자의 100%가 지금까지 그 이슈를 발견한 경우죠. 발견 내용의 신뢰 수준과 변화를 만들 시점에 대해 더 알고 싶다면 이 글을 읽어보세요.
결국, 여러분은 헌신적인 노트 테이커가 받아 적은 정식 노트와 참가자 세션의 비디오 기록, 비슷한 발견 내용으로 묶인 포스트잇으로 가득한 벽을 얻게 될 것입니다.
앞서 말했듯이, 세션이 끝난 후에 여러분이 할 수 있는 접근법엔 다음 두 가지가 있습니다.
정형적 접근법: 발견 내용을 요약하여 클라이언트에게 전달할 문서
린 접근법: delivers가 프로토타입을 문서화하는 반복 과정(?)
정형적 접근법
정형적 접근법에서는, 모든 발견 내용은 발견 내용의 임팩트와 컨설턴트의 추천사항이 담긴 문서로 요약됩니다. 정형적 리포팅의 주요 페인 포인트 중 하나는 발견 내용의 순위를 매기는 것입니다. 발견 내용은 참가자가 ‘태스크를 달성하는 것을 방해하는 것’과 ‘단순히 실수하게 만드는 것’, 두 개의 그룹으로 우선순위화 하면 쉽습니다. 하지만 그걸 넘어 순위를 매기는 것은 어렵죠.
우리는 보통 발견 내용을 다음 세 가지 기준에 따라 묶습니다.
마이너: 짜증과 혼란을 유발하거나 드물게 발생하는 이슈
메이저: 사이트 이용을 어렵게 만들지만 유저가 극복할 이슈
심각: 참가자가 태스크 완수를 못하게 막는 이슈
발견 내용을 카테고리화 하는 방법은 완전히 다음과 같은 관점에서 카테고리화 하는 것에 달려있습니다. 유저에게 중요한 것을 기준으로 카테고리화 하였는가? 무엇이 클라이언트에게 중요한가? 무엇이 가장 고치기 쉽거나 어려운 것인가? 여러분은 모든 관점을 정형적 리포트에 집어넣을 수 없기 때문에 이는 주요 페인 포인트입니다.
또 다른 페인 포인트는 발견 내용을 세 가지 카테고리로 분류하는 것입니다. 여러분은 20개 이상의 발견 내용을 하나의 카테고리로 묶을 수 있습니다. 물론 그 20개 이상의 발견 내용 중 일부는 다른 것보다 더 중요할 수 있지만, 그걸 어떻게 알 수 있을까요?
정형적 접근법의 불리한 점
정형적 문서에서, 여러분은 개발자와 디자이너를 위해 발견 내용의 우선순위를 정해야 합니다. 이는 그들이 솔루션을 반영하기 전에 어디서 시작해야 하는지 알려줄 것입니다. 또한 시간과 예산이 보통 부족하므로, 여러분은 해결책의 우선순위 또한 정해야 합니다. 왜 그래야 할까요? 여러분은 단지 발견 내용만 있는 문서를 클라이언트에게 전할 수 없기 때문입니다. 여러분이 게임 플랜을 짜주지 않는 이상 그들은 그 다음에
무엇을 해야 할지 모르기 때문이죠.
Image credits: Opensource.com. Creative Commons린 접근법
린 접근법은 유저 테스팅 발견 내용을 정형적으로 분서화하는 것보다 훨씬 더 효과적입니다. 최종 결과물은 정형적 보고서 대신 워킹 프로토타입이 됩니다. 린과 전형적 접근법 사이의 차이점은 테스팅 세션이 끝난 후에 나타납니다. 이에 대해 얘기해봅시다.
노트를 다시 살펴보자: 세션이 끝나면, 참가자를 제외한 모든 사람들은 포스트잇 앞에 가서 모든 발견 내용들이 제대로 묶였는지, 빠진 것은 없는지 확인합니다. 이렇게 함으로 팀은 좋은 토론을 할 수 있는 기회를 얻게 되고, 이는 현 디자인에서 무슨 일이 왜 일어났는지에 대한 지식을 쌓는데 도움이 될 것입니다.
해결책을 내놓자: 다음 단계는 발견 내용에 대한 해결책을 제시하는 것입니다. 이를 진행하는 데 사용되는 프로세스는 ‘협동 디자인’라고 불리는 것으로, 디자인 해결책을 만드는 협동적 방법이죠. 통합설계 접근법을 이용하는 주요 이유는 다양한 유형의 사람들을 참가시켜 서로 다른 관점에서 해결책을 내놓기 위함입니다. 예를 들어, 여러분은 UX와 IXD 컨설턴트, 클라이언트, 고객, 고객지원팀 직원, 다른 산업 전문가 등을 참여시키면 더 나은 솔루션을 내놓을 수 있습니다.
문제의 발산과 수렴
통합 설계에 대해 더 자세히 살펴봅시다. 이 협동적인 방법은 문제를 발산하고 수렴하며 이루어집니다. 다른 말로 하면, 가능한 많은 해결책을 내놓고, 최선의 것으로 좁혀나가는 것이죠.
Photo Credit: jeanbaptisteparis, Creative Commons 2.0.이 프로세스는 유저 테스트에서 얻은 포스트잇 노트 클러스터 중 하나에서 발산해 나감으로 시작합니다. 각 멤버는 가능한 많은 솔루션을 내놓고 그룹에게 보여줍니다. 모든 사람의 발표를 들은 후에, 그룹은 포스트잇 노트에 피드백을 적고, 그 피드백과 관련된 아이디어에 노트를 붙여줍니다. 그다음에, 모든 사람이 최고의 아이디어라고 생각하는 것에 빨간 점을 붙여 투표합니다.
그러면 그 그룹은 가장 많은 투표를 얻은 해결책으로 좁혀나갈 수 있을 것입니다. 팀은 그들의 피드백, 투표한 것, 다른 사람의 아이디어를 훔치는 것에 기반하여 디자인을 재정비 하기 시작합니다. 이게 한 번 끝나고 끝나고 나면, 그 발견 내용 클러스터를 위한 최선의 한 두 가지 해결책을 투표합니다. 이 과정은 모든 발견 내용 클러스터를 발산 수렴할 때까지 반복합니다.
이런 세션은 디자인 솔루션을 찾아야 할 발견 내용 클러스터의 양이 얼마나 되느냐에 따라 하루 이틀 동안 진행됩니다. 이 프로세스에 대해 더 알고 싶다면 Google Ventures design team의 글을 읽어보세요. 비록, 유저 리서치의 트렌드를 파악하는데 꽤 도움이 되는 Optimal Workshop이 Reframer라 부르는 이 정성적 리서치 툴을 우리도 이제 막 다루기 시작했지만 말이죠.
Source: Reframer이 린 프로세스의 다음 단계는 협동 디자인에서 얻은 수렴된 솔루션을 워킹 프로토타입으로 만드는 것입니다. UXPin 같은 툴을 이용하여 할 수 있겠죠.
Source: UXPin프로토타입을 만드는 것은 여러분의 작업이 작동하는 방법에 대한 작업 예시가 됩니다. 이 와이어프레임에는 그 인터랙션과 주요 변경사항에 대해 설명하기 위해 노트로 주석을 답니다. 또한 클라이언트가 디자이너와 개발자들에게 만들 것이 무엇인지 전달하는데 이용되기도 합니다.
린 접근법의 가치와 부족한 점
린 접근법을 통해 발견 내용을 가공하는 것은 발견 내용을 정형적으로 문서화하는 것보다 훨씬 더 효과적입니다. 무엇보다도, 모든 발견 내용이 이미 포스트잇에 기록된 것을 보고서에 다시 적는 일은 기본적으로 반복적인 데이터 입력이 될 것이기 때문입니다. 두 번째로, 서로 다른 관점으로 솔루션을 만들어내는 다양한 분야의 사람들이 모인 팀으로 이를 진행할 수도 있기 때문입니다.
Photo Credit: Rosenfeld Media, Creative Commons하지만, 이 방법에 부족한 점이 없는 것은 아닙니다. 그것들을 살펴봅시다.
포스트잇을 잃어버릴 수 있다: 포스트잇은, 쉽게 잃어버릴 수 있습니다. 영원히 붙어있지 않기 때문에 몇 번 세션이 진행되고 나면 사라지곤 합니다. 사진을 찍어 나중에 참고할 수 있도록 하세요. 만약을 위해서요. 하지만, 경고하자면, 그 사진은 포스트잇을 기록하는 최선의 방법이 아닙니다. 사진은 때로 흐릿하게 찍힐 수도 있으니까요.
노트를 우선순위화 하기 힘듦: 포스트잇을 가지고 당신의 발견 내용을 우선순위화 하는 것은 어렵습니다. 협동 디자인 세션을 진행하는 동안 발견 내용의 클러스터에 태클을 걸 수 있기 때문입니다.
기억해야 할 또 다른 한 가지
이 프로세스는 워킹 프로토타입을 제작하는 것에서 끝나지 않습니다. 만일 여러분이 린 프로세스를 완전히 제대로 진행하고 싶다면, 당신이 제안한 솔루션이 발견 내용을 해결하는지 확인하기 위해 프로토타입을 테스트해야 합니다. 첫 번째 테스트는 모든 발견 내용을 해결하는데 100% 효과적이지 않을 것이기 때문에, 여러분은 사용자 테스팅, 협동 디자인과 프로토타이핑 다시 하기 등의 과정을 반복해야 합니다. 이상적인 방법은, 프로세스를 그 제품의 최선의 솔루션을 발견할 때까지 반복하는 것입니다.
마지막 경고 하나
많이 반복하다 보면, 어떤 솔루션이 어떤 발견 내용과 관련이 있는지 따라가는 것이 어려워질 수 있습니다. 그러므로 만일 이해관계자가 왜 이런 변경을 했냐고 물어보면, 여러분의 디자인 결정에 대해 뭐라고 답할 것인지 분명하게 준비하세요.
끝내기
두 접근법 모두 완벽하지 않습니다. 그리고 다행스럽게도 Reframer 같은 툴 덕분에 이 프로세스는 훨씬 덜 고통스러워질 것입니다.
Source: Reframer둘 중에는, 린 방법으로 가는 것이 최선일 수 있습니다. 린 방법이 문서화보다 행동을 더 선호하기 때문입니다. 프로세스가 끝날 때면, 그냥 쌓아두고 말 문서 대신에 적용할 수 있는 워킹 프로토타입을 얻게 될 것입니다.
전민수 UX 컨설턴트 소개
(UX 실무 경력: 27년차 UX 전문가: LG전자, 서울시청 등 약 300회 이상 UX 컨설팅 수행)
(UX 강사 경력: 23년차: 삼성, SK, KT 등 약 1,000회 이상 UX 강의 진행)
https://brunch.co.kr/@ebprux/1332
[실시간 Live 강좌] (PM/PO/UI/UX/리서치) 수강생 모집 중
(이비피알유엑스 라이브클래스에서 매월 최소 1개에서 최대 4개 강좌 (온라인) 줌 Live 강좌 진행) (PM/PO/UI/UX/리서치/UX 방법론&프로세스 프레임웍)
[VOD 강좌] (PM/PO/UI/UX/리서치) 수강생 모집 중
(인프런에서 총 20개 VOD UX 강좌를 오픈했습니다)
(PM/PO/UI/UX/리서치/UX 방법론&프로세스 프레임웍)
https://www.inflearn.com/users/196290
