사용성 테스트 진행 시 유의할 점
사용성 테스트 배우기 #12
사용성 테스트 진행 시 유의할 점
alistapart.com에 게재한 사용성 테스트 진행 시 유의할 점 번역한 글입니다.
참가자에게 보다 자연스러운 행동을 독려하고 참가자가 저지르기 쉬운 편견 효과를 줄이기 위해 비형식적인 접근법을 이용하고 있습니다. 또한 평가자가 편향적이지 않고 객관적으로 사용성 테스트 결과를 도출하는데 많은 연구를 하고 있습니다.
편향은 피할 수 없다(Bias is unavoidable)
사용성 테스트 진행 시 우리는 계획 단계부터 분석 단계까지 어느 단계에서건 결과에 영향을 미칠 수 있는 많은 인지적 편향을 저지를 수 있습니다. 경험 없는 평가자들 사이에서 나타나는 확증편향은 특히 나타납니다. 이렇게 되면 테스터가 믿고 싶은 바를 확인하기 위해 질문을 만들거나 무의식적으로 특정 응답의 우선순위를 정하고 나머지는 무시하게 만듭니다. 저도 그랬던 적이 있고, 제 동료들이 그러는 것 역시 봤습니다.
예를 들어, 한 번은 특히나 검색 기능을 적용하고 싶어 하는 동료가 있었습니다. 검색의 부족성에 대해 오직 한 명의 응답자만 언급했었음에도 불구하고, 그들은 진짜로 “대부분의 사람들”이 검색을 찾았다고 확신하며 테스팅 프로세스를 마쳤습니다.
우리는 모두 리서치가 우리 팀에게 믿을 만한 안내를 제공하길 원합니다. 대부분은 의도적으로 데이터를 변형시키지 않죠. 하지만 편향은 종종 알지도 못하는 사이에, 리서처가 인지하지도 못했을 때 발생할 수도 있습니다. 최악의 시나리오는, 변형된 결과나 오해를 불러일으키는 결과가 제품의 방향에 대한 정보를 잘못 전달하고 팀에게 그들의 결정에 대한 잘못된 자신감을 줄 수 있다는 것입니다.
Capra은 편향이 주로 계획 단계(테스트 태스크와 시나리오를 짤 때), 그 자체를 진행하는 동안 (참가자와 상호작용하고 그들의 행동을 관찰할 때), 분석 단계(데이터를 해석하고 결론을 낼 때)에서 발생합니다. 저희 팀은 저희가 하는 리서치에서 편향이 생길 기회를 최대한 줄이면서, 저희 팀이 앞으로 나아가기 위해 필요한 빠르고 효율적인 리서치를 하였습니다. 저희가 발전시킨 프로세스과 테크닉을 공유하고자 합니다.
Involve multiple reviewers during planning
저희의 리서치 방식은 굉장히 협동적입니다. 프로덕트 팀의 모든 사람들 (또 때로는 다른 팀 사람들)이 적극적으로 참여합니다. 각 리서치 액티비티에 서로 다른 사람들을 초대하려고 노력하며, 디자이너, 개발자, 프로젝트 매니저, 콘텐츠 프로듀서, 고객 지원, 마케팅 등 다양한 배경과 역할을 가진 사람들이 섞일 수 있게 하려고 노력합니다.
먼저 참여하기로 한 모든 사람들에게 구글 Doc에 두 부분의 테스팅 플랜을 공유하는 것으로 시작합니다. 테스팅 플랜에는 다음과 같은 것들이 들어갑니다.
"테스팅 목표"
여기에 저희는 테스팅을 통해 답을 얻고자 하는 세 가지 질문을 적습니다.
저희 테스트는 일반적으로 짧고 구체적인 리서치 목표에 집중합니다. 예를 들어, “새로운 카테고리 필터 디자인을 사람들이 어떻게 사용하는지 살펴보자”라고 말하는 대신, “현 카테고리 필터가 소팅 탭 이용에 어떻게 영향을 미치는지 찾아보자”와 같은 측정 가능한 결과를 독려할 수 있도록 객관적인 문장 구성에 집중합니다.
"테스트 시나리오"
목표를 기반으로, 참가자와 함께 할 세 가지 또는 네 가지 태스크와 시나리오를 적습니다. 태스크는 수행 가능하게 만들며 실생활의 행동과 최대한 가깝게 만들며, 안내는 구체적일 수 있게 합니다. 각 시나리오에서는 참가자가 인터페이스에 보다 잘 몰입할 수 있도록 맥락을 제공하기도 합니다.
“6월에 시작하는 코스를 찾아라”라고 말하는 대신, “다음 달에 휴가를 갈 텐데, 그때 들을 만한 흥미로운
강의가 없는지 살펴보세요”와 같은 말을 할 수가 있습니다.
전에 했던 어느 섹션에서, 참가자들은 특정 코스를 찾으라는 요구를 받았었는데, 초안에서 “찾으세요”와 “검색해보세요” 같은 단어들을 썼었습니다. 한 동료는 참가자들에게 “코스를 검색해보라”는 요구를 했다가, 이것이 참가자들이 원래 해당 플랫폼에서 코스를 찾을 때 하는 자연스러운 행동을 관찰할 수 있게 해주는 것이 아니라, 검색 영역을 찾도록 유도할 수 있음을 발견했습니다.
지금이야 “검색”이라는 단어가 잘못된 단어 선택이었음이 분명하게 보이지만, 프로젝트에 참여하여 시나리오를 짜는 사람은 이런 미묘한 차이를 간과하기 쉽습니다. 이를 피하기 위해, 저희는 시나리오에 사용된 언어가 특정 방향으로 응답을 유도하지 않는지 확인하기 위해 여러 사람이 독립적으로 시나리오를 읽어봅니다.
Have multiple people analyze results
데이터 해석에서도 편향이 생기기 쉽습니다. 리서치 결과를 입맛에 맞게 골라내는 것과 특정 응답자에게 집중하고 다른 사람들은 무시하는 것은 경험 없는 평가자들 사이에서 흔하게 발생합니다.
수집한 데이터를 분석하는 것 또한 팀원들과 함께 하는 태스크입니다. 최소 두 명이 구글 Docs에 노트 내용을 적어 넣고, Silverback을 이용해 기록했던 세션 비디오를 다시 봅니다.
저희 팀 사람의 대부분은 사용자 테스팅에 경험을 가지고 있지 않습니다. 빈 종이를 주고 각자 결과를 찾아내라고 하는 것은 겁을 주는 일이고 시간 낭비일 수 있습니다. 그들은 무엇을 살펴봐야 할지 모를 것입니다. 그러므로, 보통 테스팅을 책임지고 있는 디자이너가 평가자가 사실 기반 질문들을 묻는 기본 구글 폼을 준비합니다. 저희는 다음과 같은 구조를 사용합니다.
"일반 질문"
참가자의 이름, 연령대, 기술적 역량 수준, 우리 제품에 대한 친숙도, 직업. 저희는 시작할 때 동의서에 사인을 받으면서 이런 류의 질문을 던집니다.
"시나리오 퍼포먼스"
이 섹션에는 각 시나리오의 참가자 퍼포먼스와 관련된 구체적인 질문이 들어갑니다. 주로 몇 가지 간단한 선다형 질문을 이용합니다. 테스트가 짧기 때문에 보통 각 질문마다 복잡한 평가척도보다는 2개에서 3개 정도의 옵션을 제시합니다. 그러면 평가자가 빈칸에 추가적인 정보나 코멘트를 남길 수 있습니다.
각 평가자가 세션 비디오를 시청하는 동안 채워 넣어야 할 구글 양식 예시이런 간단한 폼으로도 평가자에 의한 잘못된 해석의 여지를 줄일 수 있고, 경험 없는 평가자는 자신의 관찰내용을 쉽게 공유할 수 있습니다. 또한 이는 저희가 하는 분석을 정량적 데이터로 뒷받침할 수 있게 해줍니다. (예: 얼마나 많은 사람들이 해당 문제를 경험하였고 얼마나 자주 경험하였는가? 특정 태스크를 완료하는 것이 얼마나 쉽거나 어려웠는가? 얼마나 자주 특정 요소가 기대했던 사용 되었는가? 아니면 무시되었거나 잘못 해석되었는가?)
추가적으로 이 양식에 각 태스크의 퍼포먼스, 인용문, 수치 등 로우 데이터 및 기타 디테일이 들어갑니다. 이 응답 내용과 녹화된 비디오, 모든 사람들이 적은 노트 등을 기반으로, 디자이너는 팀의 리서치 결과를 합칩니다. 저는 보통 다른 스프레드시트에 모든 수집된 데이터를 관련된 데이터끼리 묶는 것으로 시작하는데, 이렇게 하면 모든 데이터를 한눈에 볼 수 있으며, 놓치거나 무시하고 지나가는 것이 없도록 도와줍니다.
스프레드시트에 데이터를 묶고 정리하는 것은 테마와 패턴을 찾는 것을 훨씬 쉽게 만들어줍니다.이 단계에서 저희는 관찰된 행동에서 일반 패턴을 찾습니다. 반드시 어떤 outliers와 모순이 나타납니다. 저희는 계속해서 이를 따로따로 추적합니다. 저희가 규칙적으로 리서치를 하기 때문에, 시간이 지날수록 outliers가 추가되고, 새롭고 흥미로운 패턴 역시 드러나게 됩니다.
그러면 저희는 결과 서머리를 작성합니다. 이러한 패턴들의 아웃라인을 잡고, 그것이 저희 리서치 목표를 어떻게 반영하고 있는지에 대한 짧은 문서를 작성하는 거죠. 태스크 퍼포먼스 수치와 기억할만한 유저의 말, 흥미로운 디테일 및 그 외 팀원들에게 눈에 띄었던 사항들에 대한 내용도 들어갑니다.
이 서머리는 리서치팀과 공유하여 그들의 노트가 제대로 들어갔고 해석되었는지 확인합니다. 그러면 이제 리서처는 모든 것을 유저 테스팅 리포트에 모아 넣어, 나머지 회사 사람들과 공유합니다.
테스팅, 태스크, 시나리오의 목적: 테스팅 플랜에 들어갔던 내용
응답자: 응답자들의 인적사항(일반 질문 섹션을 기반으로)의 간단한 오버뷰
결과와 관찰 내용: 앞서 기록했던 결과 서머리를 기반으로 작성
결론: 다음 단계 또는 이 정보 활용 방안에 대한 제안
팀에서 리포트 작성에 시간을 투자하기 싫어하는 경우도 있지만, 저희는 이것이 유용하다는 것을 배웠습니다. 나중에 다시 찾아보기도 하고 그들도 저희가 찾은 리서치 결과로부터 뭔가 배울 수 있도록 프로젝트에 참여하지 않는 사람들과 공유하기도 합니다. 또한 리서치 결과를 더 짧은 프레젠테이션 포맷으로 만들어서 sprint reviews에서 공유하기도 합니다.
전민수 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
