전직 UX 리서처가 실무 경험을 바탕으로 적어보는 글
이커머스 회사에서 UX 리서처로 일했던 실무 경험을 바탕으로 UT(Usability Testing)에 대해 써보려 한다. UX 리서치는 다양한 방법이 있지만, 그중 UT는 실제 사용자를 대상으로 서비스의 사용성을 테스트하는 리서치다. 고객과 직접 만나 제작자의 관점에서는 알 수 없었던 사용성 이슈나 서비스 개선 포인트 등의 인사이트를 얻을 수 있는 조사 방법이다.
사용성 테스트는 프로덕트에 따라 환경과 태스크가 모두 상이하겠지만, 나의 경우 앱 서비스를 주요 프로덕트로 UT를 진행했기 때문에 앱 서비스 UT 경험을 바탕으로 서술한다.
UT는 Usability Testing의 약자이다. 서비스의 실제 이용자들을 대상으로 그들이 어떻게 서비스를 사용하는지 관찰하는 조사이다. 이를 통해서 서비스가 기획, 디자인한 대로 잘 사용이 되는지 테스트를 해볼 수 있다.
개발자, 기획자, 디자이너는 만드는 사람들이다. 만드는 사람들은 앱의 구현이 가장 중요한 우선순위기에 중요한 문제점을 때로 놓치기도 한다. 앱/웹 서비스의 경우, 사용성은 매우 중요하므로 실제 고객을 대상으로 테스트를 하여 서비스 개선 인사이트를 발굴하는 목적으로 활용한다.
물론 기획자나 디자이너가 직접 테스트 케이스를 만들거나 QA와 함께 배포 전 테스트를 할 수 있지만, 실제 유저들이 이용 과정에서 만나는 불편함 등은 오직 실제 문제를 해결하고자 서비스를 이용하는 유저들만이 알고 있는 경우도 있기 때문에 더 나은 서비스 사용성을 위해 시행한다. 배포 전의 프로토타입으로 테스트하는 경우도 있고, 현재의 서비스를 대상으로 할 수도 있다.
참여자들이 성공적으로 주어진 태스크를 수행할 수 있는지 확인하기 위해
태스크를 수행하는데 어느 정도의 시간이 걸리는지 알아보기 위해
우리 웹/앱 서비스에 대한 참여자들의 만족도를 알아보기 위해
사용자 만족도와 태스크 수행 성공(전환율 등..)을 개선하기 위해 어떤 것들을 바꿔야 할지 확인하기 위해
유저들이 서비스를 사용할 때 기획/디자인의 의도대로 사용하는지 확인하기 위해
서비스 출시 전, 프로토타입 대상으로 고객 반응, 사용성 확인하고 궁극적으로는 비용을 절감하기 위해
UT를 실행한다.
크게 아래의 프로세스를 따라 UT가 진행된다.
가설 정하기 → 태스크 정의와 시나리오 작성 → 리쿠르팅 → UT진행
각 단계마다 중요한 점들이 있는데, 오늘은 가설 정하기와 태스크 정의에 대해서 적어보도록 하겠다. 즉, 테스트 설계에 대한 부분이다.
첫 번째로 할 일은 UT를 진행하는 목적을 다시 생각해 보는 것. 즉, 테스트를 통해서 확인하고 싶은 사항을 정해야 한다.
ex1. 새로운 서비스 출시를 앞두고 우리가 설계한 서비스를 사용자가 잘 이해하고 있는지, 프로토타입을 사용해보는 과제를 통해 이해도와 사용성 이슈를 확인하려 한다.
ex2. 고객센터나 앱 후기 등에서 사용자 불편이 다수 접수되고 있는데, 어떤 맥락에서 사용자가 불편을 겪는지 알아보고 개선점을 도출하고자 한다.
ex3. 상품 결제 과정에서 결제 카드 선택이 어려울 것 같다. 개선을 하고 싶은데, 실제 고객이 카드 선택에서 어려움을 겪는지 확인하고 개선 사항과 우선순위를 파악하고자 한다.
위처럼 뚜렷한 목적과 확인하고자 하는 대상이 있을 때 더욱 뾰족한 조사 결과를 도출할 수 있다. 여느 연구와 마찬가지로 사용성 테스트도 가설을 잘 잡아야 마지막 결과까지 매끈하게 도출할 수 있다.
혹은 의문문의 형태로 작성해 보는 것도 도움이 된다.
사용자가 할인을 받고 싶을 때 쿠폰 페이지로 잘 찾아갈 수 있을까?
원하는 상품에 쿠폰을 적용하는 건 어렵지 않을까?
확인하고 싶은 대상과 가설을 설정했으면, 이제는 실제 테스트에서 어떤 태스크를 줄지 설계해야 한다. 여기서 태스크(Task)란, 유저에게 주어지는 미션 같은 것이다. 예를 들면 아래와 같다.
태스크 예시
이전에 구매한 상품의 리뷰를 작성해 보세요.
쿠폰을 다운로드하고 원하는 상품에 적용하여 결제까지 진행해 보세요.
가설을 바탕으로, 유저에게 확인하고자 하는 것들을 볼 수 있는 미션을 정하는 것이 바로 태스크를 정하는 것이다. 여러 개의 태스크들이 모여 사용자 조사 시나리오가 되는 것으로, UT 시나리오 작성이란 여러 가지 태스크들을 어떤 순서로 유저에게 수행 요청할 것인지, 무엇을 주요 확인할 것인지, 추가 질문할 사항들은 무엇인지 등을 미리 적는 것이다.
<시나리오 작성 시 유의사항>
UT는 실제 사용자를 만나는 자리로, 아이스브레이킹이 필요하다. 캐주얼한 스몰토크 등으로 분위기를 편안하게 만드는 질문들로 테스트를 시작하기
바로 태스크 수행을 요청하기보다 서비스 이용행태나 관련 주제 관심도 등 물으며 좁혀가기 (이는 테스트 이후 유저 행동 파악과 분석에 참고가 되기도 하여 유용함)
태스크 수행 시의 순서를 고려하기. A 태스크를 진행 후, B 태스크를 사용자에게 요청 시 확인이 어려운 태스크도 있다. (ex. 리뷰 작성 완료 후에는 리뷰 유도 팝업 이해도나 지각도 확인이 어려움 등). 실제 유저가 미션을 수행할 때의 상황에 입각하여 테스트 시나리오를 작성해야 한다.
하나의 태스크 안에서 확인하고자 하는 주요 사항들과 추가 질문 등을 함께 적어 참고할 수 있도록 하기.
미리 공유된 시간 내에 테스트를 마무리할 수 있도록 시간을 고려하여 태스크와 질문 구성하기
<UT 시나리오의 역할>
이 시나리오는 주로 실제 UT 진행 시, 직접 사용자를 만나 테스트를 진행하는 모더레이터가 숙지하는 진행 카드 같은 것으로, 길면 1시간까지도 진행되는 UT에서 혹시 놓친 확인 사항은 없는지 확인할 수 있는 안내서이자 초보 모더레이터에겐 커닝 페이퍼가 되기도 한다.
모더레이터뿐만 아니라, 관찰룸에서 함께 테스트를 진행하는 같은 팀원 혹은 참관을 온 다른 팀원들에게도 어떠한 순서와 내용을 점검할 것인지 미리 확인하고 진행 시 같이 따라갈 수 있는 안내 책자 역할도 함께 한다.
모더레이터가 테스트 진행 편의를 위해 개인적으로 확인하고 참고할 사항들이 있는 경우, 모더레이터용과 참관용 시나리오를 따로 만들어 활용하기도 한다.
<UT 시나리오로 소통하기>
자발적으로 리서처들이 테스트를 진행하는 경우도 있으나, 다른 팀에서 사용성 조사를 요청하는 경우도 있다. 이때는 해당 부서가 어떤 것을 확인하고자 하는지 시나리오 작성 전 미팅을 통해 사전 파악을 할 필요가 있다. 서비스 기획 의도나 우려하는 페인포인트 등에 대해 확인한 뒤 태스크와 시나리오를 작성하면 비용을 줄일 수 있다. 시나리오 작성 후에도 가능하다면 함께 미팅을 해서 확인할 사항들을 공유하고 최종적인 시나리오 작성을 마무리하는 단계가 있다.
직접 미팅에 제약이 있다면, 테스트 설계 후 관련 문서나 페이지를 공유하며 질문 및 의견을 받을 수 있도록 해도 괜찮다. 슬랙이나 지라 등 요즘은 협업 툴을 많이 사용하고 있으니, 활발한 소통이 가능한 환경이라면 미팅은 생략가능.
<시나리오 적는 방법>
워드, 한글, 페이지 등 문서 편집 툴에서 작업을 해도 되고 편한 사람은 피그마, powerpoint, 키노트 등을 활용해도 무관하다. 중요한 것은 콘텐츠이지만 추가 고려해야 할 사항은 이 시나리오를 함께 공유할 사람이 있을 경우, 그 사람이 읽었을 때도 어떤 태스크를 수행할 것인지 알아볼 수 있어야 한다는 것이다.
즉, 아무리 테스트 진행 시의 질문 리스트를 추려놓은 것으로 적는다고 하여도, 나만 이해할 수 있도록 적으면 안 된다. 공유를 하게 된다면, 확인 사항과 테스크, 소요 시간등을 명확히 기재하면 소통이 쉽다.
이번 글에서는 UT의 개념과 필요성, 그리고 테스트 설계에 대해 알아보았다. 다음 글에서는 리쿠르팅과 UT 진행에 대해서 적어보려 한다. 시간이 되면 사실 가장 중요한 부분인 결과 분석과 공유에 대해서도 다뤄보고 싶다. 그럼 안녕