brunch

You can make anything
by writing

C.S.Lewis

by UX 컨설턴트 전민수 Dec 15. 2016

게릴라 사용성 테스트 실무 방법

사용성 테스트 배우기 #05

게릴라 사용성 테스트 실무 방법 


userbrain에 올라온 Markus Pirker의 글  7 Step Guide to Guerrilla Usability Testing: DIY Usability Testing Method을 전문 번역한 글입니다. 


사용자 경험과 제품 개발 분야에서는 리서치와 플래닝이 쇼를 지배합니다. 둘 중 하나라도 무시하는 것은 엄청난 유저 이탈, 고객 서비스에 대한 니즈(와 비용)의 증가, 개발에 들어가는 시간과 비용의 증가 등을 비롯해 모든 부분에서 가능한 자원을 완전히 낭비하면서 여러분과 여러분 조직에 역효과를 낳을 것입니다. 


하지만 데드라인은 다가오고 예산은 적을 때 여러분은 어떻게 해야 할까요?


큰돈이 들지 않는 린이자 애자일 테스팅 접근법인 게릴라 사용성 테스팅을 해볼 수 있습니다. 게릴라 테스팅에서 최선의 결과를 뽑아내기 위해 이를 수행하는 방법을 7단계로 보여 드리겠습니다. 하지만, 그에 앞서 먼저 게릴라 테스팅에 대한 3가지 가장 많이 받는 질문에 답을 해보겠습니다. 


게릴라 테스팅은 어떻게 쓰이는 건가요?


게릴라 테스팅은 다음과 같은 것들을 고민할 필요가 없기 때문에 셋업 하기 쉽습니다. 

기록 장치 비용
리서치 랩
참가자가 방문하게 하기 (이동 경비, 약속 잡기, 스케줄과 약속 취소)
문서 작업과 관리 신경 쓰기
타깃 고객층과 매칭 되는 인구통계적 정보를 가진 제대로 된 참가자 선정하기. 게릴라 테스팅에 적합한 사람들은 지금 당장 참여할 수 있는 사람이다


이는 게릴라 테스팅을 엄청나게 린하고 애자일 하게 만들어 줍니다. 우리는 2 시간 정도의 짧은 시간 안에 인사이트를 얻어낼 수 있습니다. 


각 세션을 매우 짧고(약 15분) 압축되어 있습니다. 

여러분은 어떤 사람에게 접근해서,
여러분의 제품에 대한 몇 가지 질문에 답을 해줄 수 있냐고 물어봅니다,
그들에게 한 두 가지 태스크를 주고,
그들의 인터랙션을 관찰합니다.
그들의 경험에 대해 물어보면
끝입니다.


여러분은 테스트를 진행하는 동안 정성적 데이터를 수집하게 되기 때문에, 가장 큰 사용성 이슈를 잡아내는 데는 3명에서 5명 정도만 필요합니다. 


발견된 사용성 이슈는 당장 개선될 수 있고 개선된 디자인은 다음 테스팅 라운드에서 타당성을 검증받습니다. 


게릴라 리서치는 사용성 테스팅의 가치를 깨닫지 못하고 있는 이해관계자들에게 첫걸음을 떼기에 가장 완벽한 방법입니다.

 

계획과 시행에 몇 달씩 걸릴 수도 있는 빵빵한 사용성 테스팅에 돈을 쓰는 것보다 몇 시간 들이면서 돈은 거의 들이지 않아도 되는 게릴라 테스팅을 하는 것이 훨씬 더 쉽게 받아들일 것입니다


약간의 인사이트는 아무 인사이트도 없는 것보다 낫습니다. 그러니 여러분이 시행하는 리서치가 빠르고 간단하더라도, 매우 가치 있으며 아무 리서치도 하지 않는 것보다 낫다는 거죠. 


게릴라 테스팅에 적합한 참가자를 어디서 찾아야 하죠?


전통적인 사용성 연구와 비교했을 때, 게릴라 테스팅의 참가자들은 선정되지 않고, 그냥 여러분이 그들에게 접근하면 됩니다


참가자를 찾는 가장 쉬운 방법은 여러분의 가족이나 친구를 테스트 참가자로 이용하는 것입니다. 그들이 어디에 사는지 알고 있기 때문에 그들은 도망칠 수 없죠. 


문제는, 여러분의 가까운 친구와 가족들이 종종 여러분과 여러분의 제품에 대해 너무 많은 것을 알고 있기 때문에, 진정한 생애 첫 사용자 경험을 그들로부터 얻기란 어렵습니다. 또한, 엄마나 이모는 여러분의 감정에 대해 지나치게 배려하고 착하게 대할 것입니다. 


그러한 이유로, 여러분과 여러분 제품에 대해 아무런 지식이 없는 새로운 참가자에게 테스트하는 것이 때론 더 낫습니다. 


그런 사람들을 찾기에 완벽한 장소는 사람들이 자연스럽게 좋은 기분 상태를 가지는 커피숍이나 쇼핑센터 등입니다. 




프로 팁

프로토타입 또는 웹사이트가 온라인에서 작동된다면 안정적인 와이파이 연결이 가능한 곳으로 고르세요. 충전기나 추가 파워 팩 또한 잊지 않도록 합니다. 테스트를 진행하는 동안 배터리가 떨어지는 일은 없어야겠죠. 


3. 게릴라 테스팅은 언제 시작해야 하나요?


저희가 하고 있는 두 비즈니스(Userbrain & Simplease)에서 사용성 테스트를 엄청 많이 했었지만, 아직까지 마이너 한 문제를 한 가지라도 발견하지 못했던 적은 한 번도 본 적이 없습니다. 


가능하면 일찍, 자주 테스트 하야만 하는 이유입니다. 제품이 개발될수록 점점 더 문제를 고치는 비용이 비싸질 것이기 때문이죠. 


기억하세요. 유저 피드백의 가치를 경험하는 데는 완성된 제품이 필요하지 않습니다. 만일 여러분이 런칭 직전에만 테스트하려고 기다린다면, 이미 무언가 고치기엔 너무 늦어버릴 것입니다. 

그럼 시작해 봅시다!


1단계. 태스크 리스트를 작성하라


가장 먼저 할 일은 여러분의 사이트에서 사람들이 할 수 있어야 하는 중요한 태스크를 모두 적은 리스트를 작성하는 것입니다.


만일 사람들이 무언가 사러 여러분의 사이트를 방문한다면, 테스트받는 사람에게 물건 구매를 요구하는 태스크를 가지고 있어야 합니다. 만일 계정을 새로 만들길 원한다면, 회원가입을 하라고 요청하면 되는 거죠. 


예를 들어, 페이스북의 액션은 다음과 같을 것입니다.

새로운 포스트 스크롤해서 보기
상태 업데이트 하기
개인 메시지 보내기
사진 올리가
친구 추가하기
비밀번호 바꾸기


이제 여러분의 목록을 써보세요. 사람들이 여러분 사이트에서 하는 중요한 것들을 모두 생각해보고 짧은 태스크 리스트를 작성해보세요.


그리고 상세하게 적느라 시간을 낭비하지 마세요. 그냥 리스트만 적으세요. 나머진 다음 단계에서 다루겠습니다. 


만일 잘 안 된다면, 다음 글이 도움이 될 것입니다.

- 사용성 테스팅을 개선하기     위해 더 나은 태스크를 작성하는 방법

- 지금까지 시도해보지 않았지만, 반드시 해야 하는 6가지 사용성 태스크

- 사용성 테스트에서 절대 물어보면     안 되는 3가지


2단계. 태스크의 우선순위를 매기고 무엇을 테스트할지 정하라



리스트를 만들었으면, 이제 그 태스크가 얼마나 자주 수행되느냐에 따라서 1점부터 3점까지 점수를 매겨 모든 아이템에 우선순위를 정할 시간입니다. 


Add:
3. 대부분의 유저가 대부분의 경우에 하는 태스크에는 3점
2. 가끔 한다면 2점
1. (이커머스 사이트에서 제품 반품과 같이) 어쩌다 한 번 씩 한다면 1점


그래서, 다음은 페이스북의 리스트에 우선순위를 매겨봤습니다. 

Scroll through new posts: 3
Update your status: 2
Send a private message: 1
Upload a photo: 2
Add a friend: 1
Change your password: 1


랭킹을 매기는데 너무 많은 시간을 쏟지 마세요. 다만 대부분의 사람들이 대부분의 경우에 이용하는 태스크가 무엇인지만 확실히 찾으세요.


왜냐고요? 모든 것을 한 번에 테스트할 수 없기 때문입니다. (게릴라 사용성 테스트에서는 그렇지 않다는 거죠.) 그리고 만일 여러분이 첫 테스트에서는 가장 중요한 부분의 문제를 찾고 고치는데 집중하고자 한다면, 투입 대비 최고의 산출을 얻을 수 있을 것입니다. 


좋습니다, 다음은 우리의 가장 중요한 태스크 3가지입니다. 


다시 말하지만, 게릴라 사용성 테스팅은 빠르게 결과를 얻고 그에 대한 행동을 즉각적으로 하는 것입니다. 가장 중요한 태스크 3가지만 고르세요. 나머지는 나중에 테스트할 수 있습니다. 


3단계. 태스크를 시나리오로 만들어라


이제 여러분의 태스크를 여러분이 읽고, 이해하고, 따를 수 있는 시나리오로 옮길 시간입니다. 


프로 팁. 시나리오를 제대로 쓰기만 한다면, 여러분의 테스팅은 잘 진행될 것입니다. 그리고 좋은 시나리오를 만드는 것은 마치 타깃 고객에게 테스트하는 것처럼 테스트를 진행할 수 있도록 도와줄 것입니다. 



다음은 유용한 태스크 시나리오를 작성하는 규칙 룰 리스트입니다.


1. 시나리오에서 단서를 제공하지 않는다

명확하고 쉽게 이해할 수 있도록 시나리오를 표현해야 하지만, 스크린 상에 뜨는 흔하지 않거나 독특한 단어는 사용하지 않아야만 합니다. 그렇지 않으면, 여러분의 테스트는 그냥 단순한 단어 찾기 게임으로 변질될 것입니다. 


2. 시나리오를 따라가기 쉽게 만든다. 
말하는 식으로 적고 과학적이거나 학술적인 언어는 언제나 피해야 합니다. 친구나 동료들에게 시나리오를 사전 테스트하고, 시나리오를 쉽게 이해하는지 어떠한 혼란 없이도 따라갈 수 있는지 확인하세요.


3. 테스트에 기여하지 않는 디테일은 모두 잘라낸다.
여러분의 시나리오는 유저에게 콘텍스트(“당신은 ~이다.” “당신은 ~을 하고 싶다.”)를 제공하고 필수적인 디테일(예. 테스트의 유저 네임 및 패스워드)을 모두 줍니다. 그것 말고는 모두 불필요하며, 가능하면 시나리오를 짧게 유지해야 합니다. 


다음은 앞에서 언급했던 리소스입니다. 혹시 또 필요할 수 있으니까요.


How to write better tasks to improve your usability     testing

6 Usability tasks you haven’t tried so far, but     really should!

3 things you shouldn’t ask in a usability test


자, 그럼 이제 3가지 사례 테스트를 가지고 시도해봅시다. 


1단계. 새로운 포스트 스크롤해서 보기


우리는 유저에게 아무런 동기부여나 목표 없이 그냥 “새로운 포스트 스크롤해서 보라”고 말할 수 없습니다. 무엇을 해야 하는지 설명하는 대신, 그것을 해야 하는 이유를 줄 수 있습니다. 


나쁜 경우: 새로운 포스트를 찾기 위해 페이지를 스크롤해서 보세요.


이렇게 줘버리면 유저는 로봇처럼 태스크를 수행할 것입니다. 어떤 동기부여가 되었건, 동기가 없다면 그들은 페이지를 스크롤하기만 할 것이고, 여러분은 사용성을 어떻게 개선해야 하는지에 대하여 전혀 배우는 바가 없게 될 것입니다.


괜찮은 경우: 이 페이지를 살펴보고 어떤 페이지인지 알아내 보세요. 


이는 적어도 열려있고 사람들이 페이지를 보다 자연스럽게 탐색할 수 있도록 해줍니다. 그냥 페이지를 살펴보라고 하는 것만으로도, 어떤 페이지인지 알아내기 위해 포스트들을 스크롤해서 살펴볼 가능성은 높아지는 거죠.


좋은 경우: 오늘 페이스북을 처음 확인하는 시간이라고 상상해보세요. 가서 오늘 게재된 첫 포스트를 찾아보세요. 


마침내, 유저에게 진짜 목표를 주기 때문에, 이 방법은 통할 겁니다. 단순히 무엇을 해야 하는지(나쁜 경우) 말해주거나 그들이 하기를 소망(괜찮은 경우)하는 대신, 자연스럽게 그들이 여러분의 사이트를 이용하도록 동기부여해주는 일을 구체적으로 제시할 수 있습니다.


2단계. 상태 업데이트하기


이번 테스트에서는 실제 데이터를 입력하도록 동기를 부여해야 합니다. (단순히 스크롤만 하면 되는 것이 아닙니다.) 어떻게 하면 되는지 살펴봅시다.


1. 나쁜 경우: 상태 업데이트를 작성하고 프로필 페이지에 게재하세요.

이것은 사이트를 이용하는 방법에 대해 너무 많은 단서를 제공하고 있습니다. 사람들은 그냥 “상태 업데이트”라는 단어와 “프로필 페이지에 게시”라고 이름 붙인 버튼을 찾을 것입니다. 그리고 여기서도 역시나 왜 상태를 업데이트하고 싶은지에 대해 어떤 동기나 이유도 주지 않고 있죠. 


2. 괜찮은 경우: 상태를 업데이트함으로 친구들에게 당신이 무엇을 하고 있는지 알려주세요.

이 문장은 사람들이 왜 자신의 상태를 업데이트하고 싶어 하는지 설명하고 있습니다. 하지만 여전히 별로 좋지 않습니다. 그리고 “상태를 업데이트”라는 사실은 테스트를 간단한 단어 찾기 게임으로 만들고 있습니다. 


3. 좋은 경우: 친구들에게 당신이 무엇을 하고 있는지 알려줄 수 있는 방법을 찾아서 그들에게 당신은 지금 웹사이트를 테스팅 중이라고 얘기하세요.


이는 해당 인터페이스를 이용하는 방법에 대해 어떤 단서도 제공하지 않고 있음으로 테스트를 잘할 수 있습니다. 다시 말하면, 유저에게 구체적인 목표(친구들에게 알려줄 수 있는 방법을 찾아라)와 심지어 여러분이 이용할 수 있는 정보도 제공하고 있습니다. 


이는 테스트 동안 어떤 데이터를 채워 넣어야 하는지를 생각하느라 들이는 심리적 노력을 줄여주는데 도움이 됩니다.


3단계. 사진 올리기


이 부분은 좀 헷갈리긴 합니다. “업로드”나 “사진” 같은 단어를 반드시 피하고 싶긴 하기 때문이죠. (왜냐면 스크린에 보이니까요) 하지만 그러면서도 테스트 참가자들에게 사진을 업로드하라고 어떻게든 얘기해야 합니다. 


1. 나쁜 경우: 사진을 업로드하는 방법을 찾으세요.

이건 뭐 말 안 해도 너무 명백하죠…


2. 괜찮은 경우: 친구와 사진을 공유할 수 있는 방법을 찾으세요.

사실 이문장은 꽤 괜찮습니다. 동기부여 부분은 여전히 없긴 하지만, 친구와 사진을 공유한다는 아이디어는 사람들에게 사진을 업로딩 하는 액션에 대해 생각하게 만드는 좋은 방법입니다. 


3. 좋은 경우: 어젯밤 당신은 파티에 갔다가 재미있는 사진을 몇 장 찍었고, 이제 당신은 친구들도 그 사진을 볼 수 있도록 공유하는 방법을 찾고 있습니다. 

이 문장은 유저로서 여러분이 달성하고자 하는 목표와 상황을 이해하게 해주는 모든 필수 맥락을 제공합니다. 


모든 디테일이 말이 되는지, 전체를 이해하는데 어떻게 기여하는지를 보세요. 그 그림들이 재미있다는 사실은, 일부 유저에게 프리이버시 세팅을 더 고민하게 만들 것입니다.(친구들과 파티한다는 맥락에서 나온 “재미”라는 단어는 대부분의 사람들이 공개하길 원하는 것은 아닐 것입니다.)




4단계: 3가지 시나리오를 모두 합쳐라


좋습니다! 방금 가장 중요한 태스크들을 시나리오로 바꿔봤으니 이제 이것들을 합칠 시간입니다. 


오늘 페이스북을 처음 확인하는 시간이라고 상상해보세요. 가서 오늘 게재된 첫 포스트를 찾아보세요. 
친구들에게 당신이 무엇을 하고 있는지 알려줄 수 있는 방법을 찾아서 그들에게 당신은 지금 웹사이트를 테스팅 중이라고 얘기하세요.
어젯밤 당신은 파티에 갔다가 재미있는 사진을 몇 장 찍었고, 이제 당신은 친구들도 그 사진을 볼 수 있도록 공유하는 방법을 찾고 있습니다.


자, 이건 쉬웠습니다. 이제 여러분이 할 일은 테스트를 시작하는 것입니다. 하지만 그전에 어떻게 하는 것인지 읽고 배워봅시다. 


5단계: 게릴라 테스팅을 시작하라


시작할 때 언급했듯이, 게릴라 사용성 테스팅의 비밀은 사람들에게 접근하여 여러분의 사이트, 앱, 프로토타입을 테스트해달라고 요청하는 것입니다. 


여러분이 누구를 대상으로 테스트를 하고 있는지, 세션을 어떻게 기록할 지에 대해 전혀 걱정할 필요가 없으며, 시작하는 데 문서화된 허가나 그 어떤 것도 필요하지 않습니다. 


그냥 누군가에게 말을 걸고 몇 분만 시간을 내줄 수 있는지 물어보세요. 더 나은 결과를 얻기 위해서는 공짜 커피나 머핀 같은 약간의 보상을 제안하는 것으로 참여에 대한 감사를 표해도 됩니다. 


그리고 여러분이 이런 사람들에게 접근하는 것이 충분히 편안해 지기만 하면, 나머지는 세션을 진행하면 할수록 이해하게 될 것입니다. 


1. 사람들이 참여하도록 유도하는 방법


다음은 사람들에게 접근하면서 여러분이 할 수 있는 말입니다.



“안녕하세요! 저희는 웹사이트(앱, 프로토타입 등 만들고 있는 것)를 작업하고 있는데 저희가 의도한 대로 잘 작동하는지 알고 싶습니다. 그래서 지금 이렇게 낯선 사람에게 몇 분 동안만 저희 사이트를 테스트해보고 어떤지 말해달라고 요청하고 있습니다. 테스트에 한 번 참여해보시겠습니까? 답을 하시기 전에 말씀드리면, 여러분이 잘못하게 되는 일은 전혀 없습니다. 그리고 이에 더불어, 감사의 의미로 제가 사드릴 테디 커피나 머핀이나 원하시는 것을 즐기실 수 있습니다. “


2. 테스트를 하는 방법 설명하기


대부분의 사람들이 사용성 테스팅이 뭔지 모르기 때문에, 보통 시나리오를 주기 전에 설명을 좀 해줘야 합니다. 

“한 가지 당신이 반드시 알아야 할 것은 저희가 테스트하는 것은 사이트이지 당신이 아니라는 것입니다. 그러니 실수하는 것을 전혀 염려하지 않으셔도 됩니다. 여러분은 저희의 실수를 지적하면 됩니다. 사이트를 이용하는 동안, 생각하는 것을 말로 크게 해주시면 좋겠습니다. 그냥 무엇을 보고 있고, 그것이 당신에게 어떤 영향을 미쳤고, 모든 인터랙션 후에 어떤 일이 벌어질 것이라고 기대하는지, 무엇을 달성하고자 하는지 등을 말해주시면 됩니다. 그리고 저희 감정은 신경 쓰지 않으셔도 됩니다. 저희는 사이트를 개선하고 싶고 당신의 솔직한 반응을 듣고 싶습니다.”


자 그럼 이제 재미있는 부분으로 넘어갑니다. 여러분의 시나리오를 그들에게 주고, 등을 기대고 앉아서 유저가 웹사이트, 앱, 프로토타입을 어떻게 이용하는지 관찰하세요. 그리고…


3. 닥치고 있어야 함을 잊지 마세요


시나리오에서도 말했듯이, 여러분은 사이트를 어떻게 이용하는지에 대한 어떤 단서도 제공하면 안 됩니다. 유저를 리드하고 싶지 않으시죠. 그들 스스로 어떻게 찾아가는지 혹은 찾아가지 못하는지 알고 싶을 것이고, 이것이 더 많은 것을 알려줄 것입니다!


유저를 리딩하지 않는 가장 좋은 방법은 테스팅 세션 동안 조용히 하는 것입니다. 실생활에서 우리는 그들이 제품을 사용하는 동안 옆에 앉아있지 않겠죠. 여러분은 테스팅 세션이 가능하면 실제와 가깝기를 원할 것입니다. 


당연히 참가자들도 질문하고 싶은 것이 생길 텐데, 여러분이 옆에 앉아 있으니 자연스레 물어볼 것입니다. 질문할 때마다 불편한 마음을 갖지 않으려면, 이렇게만 말해주면 됩니다.


“좋은 질문입니다. 저희는 사람들이 옆에 도우미가 앉아 있지 않은 상태에서 사이트를 어떻게 이용하는지 보고 싶기 때문에 지금은 대답하고 싶지 않습니다만, 테스트가 끝나면 답해드리겠습니다. 지금이 질문을 해주셨는데, 만일 제가 여기 없고 당신 스스로 이 사이트를 이용하고 있다면 이다음엔 어떻게 하시겠습니까?”


테스트를 진행하는 동안 이 질문과 다른 모든 것들을 다루는 여러분 만의 방법을 찾아가게 될 것입니다.


여러분이 말을 할 수 있는 유일한 시간은 유저에게 씽크얼라우드 하라고 상기시킬 때뿐입니다. 테스트 참가자들은 특히나 뭔가 이해하려고 할 때 조용해질 수 있는데, 바로 이때 여러분이 살짝 찔러주면 됩니다. 


목표는 유저가 가장 많이 말하게 하는 것임을 잊지 마세요. 테스트 시간의 100%를 유저만 얘기하는 것이 가장 이상적입니다. 


4. 질문 토론하기


테스트 참가자가 시나리오를 끝냈고 모든 태스크를 시도해봤다면, 이젠 테스트를 진행하는 동안 떠올랐던 질문을 던지거나 여러분 팔로우업 질문을 스스로에게 던져보세요. 


만일 타깃 고객에게 테스트할 기회가 주어졌다면, 이를 고객 인터뷰로 전환하여 실제 그 제품을 사용할지 물어볼 수 있습니다. 


하지만 이는 더 이상 사용성 테스팅 부분이 아니기 때문에, 저희는 다음 단계로 넘어가도록 하겠습니다. 


6단계: 게릴라 테스팅에서 인사이트를 잡아내라


테스트를 진행하는 동안 인사이트를 잡아내려 하지 마라


네, 맞습니다. 참가자 앉아 있는데 옆에서 계속 뭘 적고만 있다면, 여러분은 그들의 경험을 망치게 될 것이기 때문입니다. 


사람들은 스트레스를 받을 것이고 여러분이 무엇을 받아 적고 있는지, 자기가 뭔가 잘못하고 있는 게 없는지 걱정할 것입니다…


테스트 동안 여러분은 유저를 관찰하고, 그들의 행동과 말의 미묘한 뉘앙스와 그 뒤에 숨겨진 의미를 판독하도록 노력하는데만 집중해야 합니다. 맞습니다, 유저는 씽크얼라우드를 하고 있지만, 사람들은 자신의 무의식적 생각을 의식적으로 바꾸고 말로 표현하는 일을 정말 못합니다.


바로 이것이 여러분이 항상 스스로에게 “이 사람이 지금 표현하고 있는 생각 뒤에 뭔가 더 있는가?”라고 물어봐야 하는 이유입니다. 여러분의 정신은 관찰에 (쓰는 것이 아니라) 집중되어 있어야 하며, 중요한 모든 것을 기억할 수 있음을 깨닫게 되실 겁니다. 일부 잊어버린다 할지라도, 다른 테스트를 또 하면 됩니다(7단계에서 보게 될 것과 마찬가지로 말이죠). 그리고 그게 진정한 문제라면 다시 등장할 것입니다.


그래서 여러분은 어떻게 테스팅 인사이트를 잡아내나요?


방법 #1. 상위 3가지 사용성 문제 리스트를 적어라


리서치 결과를 잡아내는 가장 분명한 방법은 간단하게 그 테스트에서 발견된 3가지 사용성 문제의 리스트를 작성하는 것입니다.




여러분이 찾은 모든 것을 적을 필요는 없습니다. 게릴라 테스팅은 가장 심각한 문제를 찾고 고치는 것이지, 유저가 마주칠 모든 장애물에 대해 고민하는 것이 아닙니다. 만일 사용성 문제를 어떻게 밝혀내는지 궁금하다면, 스티브 크루그가 (이 포스트의 청사진과 같은) 그의 접근법을 설명하는 이 사례 비디오를 보세요.



방법#2. 태스크 완료율 잡아내기


여러분의 리서치 결과를 문서화하는 보다 세련된 방법은 각 참가자의 태스크 완료율을 잡아내는 것입니다. 만일 여러분이 클라이언트나 이해관계자들 앞에서 발표할 무언가가 필요하다면 특히 유용합니다. 다음과 같은 자격을 부여할 수 있습니다.


3.     만일 유저가 태스크를 빠르게 수행할 수 있고 문제가 없었다면,     3점을 주세요.
2.     만일 유저가 태스크를 수행할 수 있었지만 문제가 있었다면, 2점을     주세요.
1.     만일 유저가 태스크를 수행할 수 없다면, 1점을 주세요.


그럼 여러분의 결과는 이렇게 보일 것입니다.



저희는 이 스프레드시트를 Simplease에서 했던 클라이언트 프로젝트에서 활용했었습니다. 무료로 다운로드할 수 있으며, 여러분의 목적에 따라 수정하여 사용해도 됩니다.


7단계: 사용성 문제를 고쳐라



앞서 이 글을 시작할 때 언급했듯이, 문제를 고치는 것은 비쌀 수 있습니다. 특히 이슈가 애플리케이션이나 라이브 웹사이트를 운영하는데 영향을 미친다면요. 바로 이것이 코드를 한 줄도 쓰기 전에 주요 이슈를 고칠 수 있도록 프로토타입을 만들고 가능하면 빨리, 자주 테스트하는 것이 지혜로운 이유입니다. 


하지만 만일 여러분이 이미 프로토타이핑 단계를 거쳤고, 게릴라 테스팅을 통해 찾은 문제를 고치려면 수 백 시간의 개발 시간과 수천 달러의 비용이 발생한다면 어떻게 해야 할까요?


가장 큰 문제를 먼저 고쳐라


 “만일 당신의 직업이 개구리를 먹는 것이라면, 아침에 제일 먼저 하는 것이 최선입니다. 만일 2마리의 개구리를 먹는 것이 여러분의 일이라면, 가장 큰 것을 먼저 먹는 것이 최선입니다. “  - Mark Twain - 


경청하는 독자라면 이미 패턴을 눈치채셨을 겁니다. 처음엔 가장 중요한 태스크만 테스트하고, 그다음엔 가장 중요한 문제만 적고, 이제 가장 큰 문제만 고치는 것이죠. 그리고 이걸 빠르게 하는 겁니다.



빠르게 수정하라


“문제를 고칠 때는, 당신이 할 수 있는 최소한만 해라” ― Steve Krug, 


항상 스스로에게 여러분이 관찰한 그 문제를 사람들이 다시 겪지 않도록 하기 위해서 만들 수 있는 가장 작고 간단한 변화가 무엇인지 물어보세요.  특히 라이브 웹사이트의 경우에 더욱 그러하지만, 사람들은 이 아이디어에 반대할 수도 있습니다. 


Steve Krug는 그의 책, RocketSurgery Made Easy에서 문제의 영구적 해결책을 찾을 필요가 없다고 지적합니다. 문제를 개선하고, 그것이 제대로 작용하는지 테스트를 더 할 수 있는 ‘빠른 수정’을 쉽게 수행하는 방법을 찾으세요. 


리디자인하지 말고, 살짝 수정하세요. 


사용성 테스팅을 몇 번 하고 그 문제를 해결하는 방법을 생각하기 시작한 후에는, 언제나 여러분이 실제 관찰한 문제를 넘어서는 변화를 만들고 싶은 유혹이 생깁니다. 


곧 사이트 전체를 재 디자인하고 싶어 지는 순간이 올 겁니다. 이렇게 재 디자인하려는 경향에는 여러 이유가 있는데, 빠른 수정을 하는 대신에 제대로 하기 위해 처음부터 다시 시작하려는 이유는 이해하기 쉽습니다. 


얼마나 자주 테스트해야 하는가


사용성 테스트에 얼마나 많은 유저가 필요한가에 대한 흥미로운 논의가 있습니다. 유명한 경험법칙은 어떤 애플리케이션에서건 가장 심각한 문제를 발견하기 위해 5명의 유저에게 테스트하라는 것입니다. 하지만 언제나 그렇듯, 상황에 따라 다릅니다.


만일 한 유저가 30초 동안 주요 사용성 버그에 걸려 넘어지는 것을 본다면, 과학적 체계성을 충족하기 위해 4명을 더 테스트할 필요는 없습니다. 결국, 이건 로켓 공학이 아니라는 것이죠. 때론 명확히 보이는 겁니다. 한 유저만 보더라도 말이죠. 


딱 하나 남겨진 문제는 규칙적으로 다시 테스트하는 것입니다(가능하다면 매주). 이렇게 하면 여러분은 조금 변경했던 내용이 실제 문제를 해결했는지 확인할 수 있으며 새로운 변화 때문에 발생된 새로운 문제를 찾아낼 수도 있습니다. 


테스팅을 워크플로우의 일부로 만들어라


게릴라 테스팅이 전통적 사용성 테스팅보다 더 많은 경우에 좋은 방법인 이유는, 규칙적으로 하는 것에 대한 비용을 감당할 수 있기 때문입니다. 돈에 대해서만 얘기하는 것이 아닙니다. 


게릴라 사용성 테스팅은 빠르고 쉽고 저렴합니다, 엄청나게 효과적이며, 이걸 못 하겠다고 변명할 거리가 없습니다. 결국 가장 중요한 것은, 게릴라 사용성 테스팅은 다양한 형태가 있다는 것입니다. 여러분만의 접근법을 만드는 것을 고려해보세요. 하면서 배우는 겁니다. 




전민수 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 방법론&프로세스 프레임웍)

https://ebprux.liveklass.com/


[VOD 강좌] (PM/PO/UI/UX/리서치) 수강생 모집 중  

(인프런에서 총 20개 VOD UX 강좌를 오픈했습니다)

(PM/PO/UI/UX/리서치/UX 방법론&프로세스 프레임웍)

https://www.inflearn.com/users/196290


매거진의 이전글 사용성 테스트 시 유저 관찰하는 요령
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari