사용성 테스트 가이드라인
사용성 테스트 배우기 #14
사용성 테스트 가이드라인
사용성 테스트 가이드라인에 대해 얘기하고자 합니다.
Demetrius Madrigal and Bryan McClain 저자의 글 원문을 번역했습니다.
사용성 테스팅은 사용자 경험 리서치에서 가장 덜 매력적이지만 가장 중요한 측면이 있습니다. 사용성 테스팅은 지난 수년 동안 우리가 가장 자주 수행한 유저 리서치 형식 중 하나가 되었습니다. 그렇게 하면서, 몇 가지 모범 사례를 배웠고 잠재적 위험을 보았습니다. 이 정보를 보고 도움을 얻을 여러 이해관계자들, 디자이너들, 엔지니어들과 우리가 배운 것을 공유하는 것이 중요하다는 생각이 들었습니다.
사용성 테스트 세션에 관여하고 관찰하기
디자이너와 이해관계자는 모두 사용성 테스트 세션을 관찰함으로 많은 것을 얻어낼 수 있습니다. 애플리케이션과 그 유저 인터페이스에 대한 참가자의 리액션을 직접 목격하는 것은 리서처가 리포트와 미팅, 프레젠테이션 등을 통해 전달하기 정말 어려운 애플리케이션과 사용성 이슈를 이해할 수 있게 도와줄 것입니다. 만일 몇 번의 테스트 세션을 관찰할 기회를 가지게 된다면, 분명 거기서 이득을 얻을 수 있을 것입니다.
한 두 번의 테스트 세션을 기반으로 결론으로 넘어가기
사용성 테스트에 참가하는 참여자는 독특합니다. 사용성 테스트 세션을 관찰할 때, 이를 항상 염두에 두는 것이 중요합니다. 한두 명의 참가자가 주는 피드백은 아마도 전체 타깃 마켓이 애플리케이션이나 디자인에 대해 줄 피드백을 반영하지 못할 수도 있습니다. 리서처는 개개인의 코멘트나 독립된 사건에 집중하기보다는 전체적으로, 큰 그림에서 사용성 문제 패턴 유형을 찾아야 하는 것이 중요합니다. 그러니 이를 염두에 두고, 각각의 참여자의 의견이 좋다고 하더라도 이를 특정 디자인 방향에 대한 결론으로 건너뛰는 것을 피해야 합니다. 어떤 결정이건 내리기 전에 유저의 피드백에 대해 리서치 팀과 충분히 대화할 시간을 가져야 합니다.
유저 리서치 팀에게 방향 제시하기
보통, 유저 리서처는 애플리케이션이나 그 비즈니스 목표를 만드는 데 기여했던 이해관계자나 디자이너만큼 그것을 제대로 이해하지 못할 수 있습니다. 유저 리서처로서, 애플리케이션의 가치 평가와, 마켓에서 애플리케이션이 가진 목표, 유저가 달성했으면 하는 목표 등을 분명히 이해하는 데 클라이언트에게 의존해야 합니다. 이런 목표들을 더 잘 이해할수록, 그것을 달성하도록 리서치를 계획할 수 있습니다. 킥오프 미팅이나 이해관계자 인터뷰를 진행하면서 이런 데이터를 수집하려고 노력해야 합니다. 이는 리서치 결과를 행동으로 옮길 수 있게 만드는 데 도움을 줄 수 있습니다.
리서처 의견 존중하기
전반적으로 말하자면, 유저 리서처는 리서치를 수행하는 것에 대해서는 더 많은 경험과 지식을 가지고 있습니다. 사용성 연구 계획과 관련한 의사결정을 내릴 때 그들의 조언을 참작하는 것이 중요합니다. 만일 리서처들이 스케줄, 리크루팅, 태스크 시나리오, 테스트 진행, 또는 다른 사용성 연구 계획 요소와 관련한 조언을 한다면, 그들이 해주는 조언이 사용성 테스팅에 대한 경험과 깊이 있는 지식을 기반으로 그들이 조언을 해준다는 것을 확신할 수 있을 것입니다. 리서치 작업은 협업 프로세스로 할 때 가장 좋기 때문에, 최선의 결과를 달성하기 위해서 개발팀이 리서치 팀과 협력하는 것이 굉장히 중요합니다.
유저 행동을 포함한 스크린 요구하기
리크루팅은 보통 사용성 테스팅에서 가장 크리티컬 한 요소입니다. 만일 잘못된 참가자가 타깃 마켓을 대표하지 않는 사람을 대상으로 사용성 테스팅을 진행한다면, 애플리케이션의 유저 테스트를 잘못 수행하고 있음을 깨닫게 될 것입니다.
애플리케이션 개발자 친구와 함께 했던 대화가 기억납니다. 그는 소비자 애플리케이션의 유저 테스트 진행에 새로운 기능을 테스트하고자 했습니다. 그는 애플리케이션에 더 많은 옵션과 더 많은 정보가 들어가길 원했었습니다. 하지만 저는 그 애플리케이션의 목표 유저의 거의 대부분이 그가 제안한 굉장히 기술적인 언어를 헷갈려할 것이며, 그가 유용하다고 생각하는 옵션 중 많은 부분을 일반 사용자들은 난감해했을 것이라고 생각했습니다.
그렇다면 이는 참가자 선정 시 애플리케이션 기술 숙련도가 높은 참여자 그룹과 그렇지 않은 참여자를 선정하여 비교 사용성 테스트할 필요가 있습니다.
그래서 필요로 하는 것이 목표 사용성 테스트 대상을 타깃 선정하기 위한 스크리너가 필요합니다.
스크리너 응답자 중 목표 타깃에 적합한 참여자를 최종 선발하는 것입니다.
스크리너에 행동 관련 질문, 예를 들면 주당 인터넷 이용시간, 소셜 네트워킹 사이트와의 상호작용, 또는 특정 모바일 폰 기능 이용 등을 포함시키면, (기술 숙련도가 높든지, 낮든지) 잠재적 참가자의 기술적 능력 수준에 대한 훌륭한 아이디어를 얻을 수 있습니다.
특징적 유저 행동을 당신의 타깃 기준과 매칭 시키는 것은 잘못된 유저를 대상으로 애플리케이션을 디자인하는 일이 없도록 도와줄 것입니다.
불필요한 요구사항으로 리크루터 발목 잡기
제대로 된 참가자를 뽑는 것만큼 중요한 것이 참가자 자체를 뽑는 것입니다. 예를 들면 A 업체의 경우 사용성 테스트 진행을 위한 참가자 선정 시 안드로이드의 특정 디바이스의 어떤 모델을 소유하고 있으면서, 특정 버전까지 업데이트 한 참가자를 요구하는 스크리너를 본 적이 있습니다. 이렇게 불필요하게 엄격한 리크루팅 요구사항을 다른 리크루팅 요구사항과 묶는 것은 적절한 사용성 연구를 수행하는 데 필요한 일정 수준의 참가자를 모집하는 것을 거의 불가능하게 만듭니다. 게다가, 그런 엄격한 요구사항을 적용하면, 보다 광범위하게 정의된 마켓에서 상대적으로 벗어나는 사람을 참가자로 뽑게 될 수도 있습니다. 유저 퍼소나의 정확한 묘사와 일치하는 참가자를 뽑아야 하는 것이 아니라, 퍼소나의 이용 행동과 기술적 능력에 가까운 참가자를 뽑아야 하는 것입니다.
테스트 세션의 비디오 클립을 녹화하라.
사용성 문제를 소통하는 데 비디오 클립은 매우 귀중하며, 정말로 홈런을 날릴 수 있게 해줍니다. 참가자의 얼굴에 보이는 감정적 반응을 보고 그들의 피드백을 듣는 것은 정말로 중요합니다. 비디오 클립을 준비하는 것은 의사결정자에게 변화의 정당성을 입증시켜 줍니다. 애플리케이션의 질을 보장하는 데 필요한 예산이나 시간을 잠재적으로 추가 편성받을 수 있도록 도와줍니다.
클라이언트가 사용성 연구의 전체 비디오를 볼 것이라는 기대하지 마세요
만일 당신이 클라이언트가 사용성 연구를 하며 찍은 전체 비디오를 리뷰에 앞서 사전에 다 볼 것이라고 기대한다면, 크게 후회하게 될 것입니다. 소규모 사용성 연구라 할지라도 로우 비디오가 10시간에서 20시간은 나올 것입니다. 저희는 이 분야에서 전문성을 키워온 지 수년이 되었지만, 몇 분 이상 사용성 테스트 세션 비디오를 보는 클라이언트를 거의 본 적이 없습니다. 간혹 전체 로우 비디오를 본 클라이언트가 있었는데 존경스럽습니다.
유저 리서처는 로우 비디오를 기반으로 좋은 사용성 레포팅 제출하기 위해서는 반드시 대부분의 비디오를 봐야 할 것이며 참가자 간의 대답을 비교해볼 수 있도록 조직적으로 노트 필기를 해야 할 것입니다. 그리고 레포팅에 필요한 부분만 비디오 클립으로 편집해서 리뷰해야 합니다.
반복적 사용성 테스팅을 수행하기
제가 만나본 대부분의 클라이언트는 한 번의 대규모 연구로 모든 사용성 테스팅을 해버리려고 합니다. 이는 사용성 테스트 목표와 맞지 않는 몇 가지 이유가 있습니다. 먼저, 더 중요한 사용성 이슈는 매우 중요할 수도 있는 또 다른 이슈를 발견하기 어렵게 만드는 경향이 있습니다. 연구를 통해 찾는 더 심각한 사용성 이슈가 더 심각할수록, 놓치는 이슈 또한 더 심각해질 것이기 때문입니다.
실제 유저가 사용성 연구에 참여하게 하기 전에, 휴리스틱 분석이나 전문가 리뷰로 시작하는 것이 보통 가장 좋은 방법입니다. 한 번의 전문가 리뷰는 애플리케이션이 가진 가장 분명한 사용성 문제를 밝혀낼 수 있도록 도와줄 것이기 때문에, 더 비용이 많이 드는 사용성 테스팅에 들어가기 전에 유저 인터페이스를 개선하기 위한 몇 가지 수정을 할 수 있을 것입니다.
한 번의 사용성 테스팅 프로세스에는 제한된 수의 참가자를 대상으로 테스트를 하게 되며, 밝혀낸 문제를 해결하는 데 필수적인 수정을 거친 후에, 다시 테스팅하면 좋습니다. 단 한 번의 테스트로 12명을 테스트하여 프로젝트를 종료하지 말고, 1차 테스트에 6명, 그리고 수정 및 개발, 다음에 2차 테스트 6명 하는 것이 좋습니다. 반복적 사용성 테스팅은 린 UX에 적합하고 애자일 개발 사이클에 더 쉽게 적용할 수 있다는 장점도 있습니다.
타깃 유저 그룹에 해비 유저, 비 해비 유저 참여시키기
만일 하나 이상의 타깃 오디언스를 대상으로 하는 어프리케이션을 개발하고 있다면, 사용성 테스팅을 할 때, 반드시 해비 유저와 비 해비 유저를 반드시 포함시키도록 해야 합니다.
해비 유저 그룹은 사용성 이슈를 잘 넘겨가는 경향이 있음을 보았지만, 그들은 유저 인터페이스에 대해서 가장 비판적이기도 합니다. 반면, 덜 능숙한 비 해비 유저 그룹은 태스크를 수행하는 데 더 어려움을 겪지만, 그들은 그 어려움의 원인을 애플리케이션의 기능이나 디자인이 아닌 자신의 능력으로 놀리는 경향이 있습니다.
테스트 세션에 개발자의 직접 참여 제한하기
사용성 테스트의 목표는 애플리케이션이 세상에 나왔을 때, 애플리케이션의 목표 유저가 스스로 유저 인터페이스를 이해할 수 있는지 확인하는 것입니다. 그렇게 하기 위해서는, 참가자가 실제로 제품을 사용하는 맥락을 테스트 세션에서 흉내 낼 수 있다면 가장 좋습니다.
즉, 이 애플리케이션에 대해 많이 알고 있는 개발자가 바로 그들 옆에 앉아 있지 않는 것입니다. 간혹 개발자는 테스트 참여자가 과업 수행 시 답답함을 견디지 못하고 끼어들고 싶어 합니다. 이 경우 참여자는 테스트 그 자체는 위축되고 전체적으로 테스트가 망치게 됩니다.
개발자는 관찰실에서 테스트 세션을 관찰하는 동안, 조용히 앉아서 관찰하고 노트 필기하려고 노력하는 것이 좋습니다. 테스트 세션에서 개발자가 궁금한 점이 있거나, 새로운 질문을 던지는 한 가지 방법은 유저 리서처에게 SNS(예. 카톡) 슬쩍 전달하거나, 아니면 마지막 세션 종료 후 개발자의 질문을 포함시켜 달라고 하는 것이 더 좋습니다.
참가자에게 사용성 테스팅 환경 등 설명하기
참가자들은 사용성 테스트 진행 시 부담이 큽니다. 원웨이 미러로 인해 테스트 세션에 생기는 되는 미지의 요소는, 같은 방 안에서 다른 사람이 컴퓨터나 자신을 찍는 카메라를 가지고 있는 것보다 더 참가자를 더 긴장하고 의식하게 만드는 경향이 있습니다.
그렇기 때문에 동의서 작성 후 모든 것을 오픈하는 것이 좋습니다. 사용성 테스트 환경 이해, 진행 요령 등등
유저 리서치 팀을 알아가기
앞서 언급했듯이, 유저 리서치 작업은 협업 프로세스로 할 때 최상의 결과가 나옵니다. 협업 작업은 다른 팀에서 온 멤버들이 서로를 정말로 알아가고 효과적으로 커뮤니케이션할 때 가장 좋습니다. 그러므로, 저희는 우리가 함께 일하는 개발팀과 장기적 관계를 발전시키는 것을 좋아합니다. 우리가 그들의 프로세스를 알게 되고 그들이 우리 것을 알게 되면, 준비 시간이나 요구사항을 줄이면서 그 팀들을 위해 빠르고 유종적으로 유저 리서치를 진행할 수 있게 되며, 우리 연구 결과를 소통하는데 어떤 방법을 선택할 수 있는지 알게 됩니다. 만일 이런 유형의 관계를 리서치 팀과 형성하게 된다면, 엄청난 이득을 보게 될 것이다.
지나치게 결함이 있거나 불안정한 기술적 프로토타입 이용
결함이 있거나 불안정한 기술적 프로토타입은 사용성 연구를 상당히 복잡하게 만들 수 있습니다. 리서처로서, 만일 참가자가 태스크를 수행하려고 하는 동안 버그나 작은 결함을 발견하게 된다면, 애플리케이션의 실제 디자인보다는 버그나 작은 결함에 반응하는 경향이 있습니다. 이런 유형의 피드백은 테스트 세션 동안 얻을 수 있는 액셔너블한 데이터의 양과 질을 위태롭게 만들 수 있습니다. 또한, 버그가 세션 시간을 2배 가까이 늘어지게 할 수도 있기 때문에, 스케줄에 부정적인 영향을 미칠 가능성이 있습니다. 항상 테스트 진행 시 개발자는 수시 대기하고 있어야 합니다. 버그는 사용성 문제가 아니므로 개발자가 바로 대처하여 태스크 수행이 원활히 진행할 수 있도록 도와줘야 합니다. 저희는 사전에 자체 테스트를 해보는데 시스템 문제로 인해 그 가능성이 조금이라고 있다고 판단이 된다면 전체 테스트 진행 시간의 25%는 여유 있게 개발 수정할 수 있는 시간을 확보하면 됩니다. 예를 들면 2시간 테스트 진행이지만, 1시간 30분 테스트 진행, 30분 기타 질의 및 시스템 버그 해결 등
물론, 목업을 이용해서 테스트해야 하는 것을 테스트하지 못할 때도 있는데, 이 경우 불완전한 제품을 참가자에게 보여줘야 합니다. 이런 경우, 프로토타입의 상태를 참가자에게 알려주고 기술적 지원을 해줄 개발팀 멤버와 함께 하는 것이 중요합니다.
마무리
유저 리서처로서, 저희는 서로 다른 유형의 애플리케이션을 많이 보며, 많은 사용성 테스트를 합니다. 저희가 여기서 보여주는 간단한 가이드라인이 사용성 테스팅을 진행하는 데 도움이 될 것입니다. 전반적으로, 저희가 여기서 간단히 설명한 가이드라인은 거의 들어맞을 것이다. 물론, 예외적인 상황에서는 여기서 추천한 것의 정 반대로 행동하는 것이 최선일 수도 있습니다. 당신의 상황과 제품 목표에 가장 적합한 행동 방침을 개발하기 위해 리서치 팀과 협업하는 것은 순전히 여러분에게 달려 있습니다. 사용성 테스트의 매력은 애플리케이션에 대한 유저 피드백을 받는 것은 즐거우면서도 얻는 것이 많습니다. 이 가이드라인이 여러분 모두 사용성 테스팅 프로세스를 즐기는 데 도움이 되었으면 합니다.
전민수 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
