by
Mar 02. 2022
프로덕트 팀의 첫 UT 도입기
실은 UT는 처음이라서요
지난해 12월, 프로덕트 팀의 PM으로 합류하며 디자이너님이 주도하고 있던 기존 프로덕의 리뉴얼 프로젝트에 참여하게 되었다.
초기 기획 및 개발 검토, 디자인 초안 등은 마무리된 상황이었으나 몇 가지 가설에 대해 확신하기 어려운 상황이었다. 결국 사용자를 만나 직접 확인해보는 게 가장 정확할 거라고 생각하여, UT를 제안했다.
그러나 회사로써는 프로덕트 팀의 편성이 처음이라 UT를 진행해본 사람이 없었고, 이에 간단한 리서치 및 세팅 후 처음으로 UT를 진행하게 되었다.
오늘은 당시 진행한 UT의 프레임워크, 노하우 혹은 시행착오에 대해 공유하고자 한다.
UT(Usablility Test)란 무엇인가? 이를 통해 무엇을 알고자 하는가?
관련되어서는 이미 온라인에 정의, 방법론/프레임워크 등이 다양여 간략하게만 정리하고자 한다. 말 그대로 '사용성 테스트'로, 기획/디자인된 프로덕트를 실제 사용자 (혹은 이에 준하는 테스터가) 프로덕트를 사용하는 과정에서 불편함 없이, 의도대로 사용하며 목적한 바를 달성할 수 있는가? 를 알아보기 위한 일련의 과정이다.
1. 개요 : 핵심 기능을 발견/인지 → 사용 → 특정 문제를 해결, 정보를 이해~획득하는 과정을 관찰하고 평가
2. 알고 싶은 것 : 핵심 기능을 잘 발견하고 잘 쓰는가?
3. 이를 알기 위해 알아야 하는 것
1) 무엇을 물어볼 것인가?
2) 누구에게 물어볼 것인가?
3) 실제 결과는 어떠한가?
4) 결과를 바탕으로 개선, 수정해야 하는 것은 무엇인가?
4. 과정
1) 테스트할 항목을 정하여 질문/테스트를 설계한다.
2) 이에 알맞은 테스터를 선발고 일정을 조율한다.
3) 테스트를 수행한다.
4) 결과를 관찰, 분석하여 이를 다시 프로덕트에 반영한다
5) 필요시 위 과정을 반복한다.
5. 특징 : 정성적 접근이므로 5~10명 정도면 충분하다 (통계적 유의미성을 고려하지 않는다)
프로덕트 팀에게 UT가 필요한 이유는 무엇인가?
1. 프로덕트는 사용자의 문제를 해결하기 위한 수단이다. 사용자는 본인의 문제를 해결하고자, 본인이 의도한 행동을 혼선과 불편함 없이 수행할 수 있어야 한다. UT는 이를 실제로 관찰, 분석할 수 있는 방법론이다.
2. 애자일 agile의 관점에서 조직/팀이 달성하고자 하는 것을 조금 더 먼저, 그리고 더 적은 리스크로 달성할 수 있다면 이득이다. 그리고 조직/팀이 달성하고자 하는 것은 기획/디자인/개발한 프로덕트가 실제로 사용자의 문제를 제대로 해결하는 것이다. 혹은 해결하는지 확인, 학습하는 것이다. UT는 이를 제품의 실제 개발~출시 전에 실제로 알아보기 위한 방법론이다.
어떤 프레임워크로 진행했나?
UT 진행에 앞서 설계한 프레임워크. 여러 자료를 참고하여 상황에 맞게 수정해보았다.이미 온라인에 존재하는 여러 후기, 방법론과 프레임워크를 살펴보았으나 모든 일이 그렇듯 '완벽한 방법' 혹은 '단 하나의 방법'은 존재하지 않았다. 아마 여러 UX 관련 연구나 전문가들의 후기, 조언들이 파생되거나 재사용되었을 테지만, 결국 UT는 고객에 대해 학습하기 위한 하나의 수단, 과정일 뿐이었다. 그래서 사실 프레임워크에 대해 크게 고집하지 않고, 필요한 대로 조정하기로 했다.
그리고 기획자로써 생각하기에 가장 중요한 점은 모든 항목, 질문에는 배경/가설/의도가 있어야 한다는 점이다. 달리 말해, 배경과 가설, 의도만 확실하다면 이를 확인할 수 있는 어떤 문서, 템플릿, 프레임워크도 무관하다고 생각한다.
모든 항목, 질문에는 배경/가설/의도가 있어야 한다. 이것만 확실하다면
이를 확인할 수 있는 어떤 문서, 템플릿, 프레임워크도 무관하다.
1. 답을 얻고자 하는 질문은 무엇인가?
결국 UT는 고객을 만나, 고객에 대해 무언가를 파악, 학습하기 위한 방법론이다. 그렇다면 고객에 대해 알고 싶은 부분이 무엇인지 확실해야 한다. 그리고 기획 혹은 프로젝트를 시작하며 세운 핵심 가설에 관한 부분이 UT의 테스트 항목이 될 것이다.
2. 테스터(고객)의 간략한 인적 정보와 선발 이유
고객이라고 해서 다 같은 고객이 아니다. 사용자 유형에 따라, 행동 패턴/빈도에 따라, 혹은 인적정보에 따라 사용자는 모두 다르다. 그리고 UT는 '아무 고객'에 대해 학습하는 게 아니라, 핵심 가설이 대상으로 하는 고객에 대해 학습하기 위한 과정이다. 따라서, UT를 통해 만날 고객이 누구여야 하며, 그래서 실제로 누굴 만났는지 기록한다.
3. 테스터의 실제 반응/질문
테스트의 중간 혹은 끝에서, 테스터는 직접 질문을 하거나 혹은 어떤 의견을 건넨다. 어떤 점이 헷갈렸는지, 불편했는지, 기대와 달랐는지 등. 답을 얻고자 하는 질문에 관련된 내용이라면 기록해둔다. 이는 실제로 고객의 반응을 가장 명시적으로, 직접적으로 확인할 수 있는 부분이다.
4. 관찰한 내용
그러나 때로는 말이 아닌 행동을 통해 반응을 확인할 수 있다. 사람은 말이 아닌 몸짓과 눈빛으로도 표현을 하고, 혹은 이 표현이 말과 다르기도 하다. 그래서 나의 경우 관찰자로서 고객에 대해 '관찰한' 내용을 함께 기록해두었다. 가령 어느 부분에서 손이 멈췄는지, 어떤 버튼이나 메뉴로 되돌아갔는지 등. 이는 테스터의 실제 반응/질문과 어우러져, 테스터 혹은 테스트 항목에 대해 더 깊게 이해하게 도와주었다.
5. 테스트 과정 자체에 대한 비고
테스트를 진행하는 과정에서, 담당자와 관찰자는 비단 테스터 혹은 프로덕트에 대해서만 학습하는 게 아니라, 이 테스트 과정 자체에 대해 배우기도 한다. 잘못된 부분, 아쉬운 부분, 그러므로 개선할 부분 등. 혹은 그저 단순한 아이디어가 떠오를 수도 있다. 이런 내용들은 다음 테스트에 참고할 수 있는 항목이 되므로 기록해두었다.
6. 테스터의 기타 의견
테스터는 테스트 항목 이외의 내용에 대해 의견을 주기도 한다. 사용자로서 먼저 제품에 대해 접하는 기회이기도 하고, 선발된 테스터가 서비스에 관여도 혹은 관심이 많을 수도 있기에, 새로운 기능 혹은 변화된 모습에 대해 이런저런 감상과 질문, 의견이 생기기 마련이다. 그러나 이는 테스트를 통해 확인하려는 핵심 내용은 아니기에, 별도로 분리해둔다. (단, 때에 따라 주요한 단서 혹은 인사이트를 발견할 수도 있으므로 기록 자체를 누락시키지는 않는다)
이어지는 글
