프로덕트 팀의 첫 UT 진행 후기 (1)
질문 설계와 테스트 시행 과정에 관한 깨달음
https://brunch.co.kr/@539insight/91
앞선 글에선, UT에 관한 간략한 정리와, 새로 편성된 프로덕트 팀의 첫 프로젝트에 UT를 도입하며 사용한 프레임워크에 대해 소개했다.
아래의 내용은 첫 UT 과정에서 겪은 좌충우돌을 통해 깨닫거나 배운 점이다.
질문 설계 및 테스터 선정 과정에 대한 깨달음
1. 무엇을 테스트할 것인가? : 가설과 기획 의도가 없다면 질문은 나올 수 없다
내가 UT를 처음 제안했던 당시, 프로젝트를 담당하던 디자이너님의 가설과 기획 의도가 명확하지 않았다. 여러 개선 사항과 및 새로운 기능이 추가되었으나, 그래서 어떤 부분이 어떠 의도 혹은 가설에 의해 변경되거나 추가되었는지가 다소 불분명했다. 그래서 질문 설계에 앞서 가장 먼저 확인한 것은 기획자로써 디자이너님이 생각했던 핵심 가설이었다.
결국 UT는 핵심 가설, 기획 의도에 대한 고객의 반응을 확인하기 위한 수단 혹은 방법론이다. 답을 얻고 싶은 질문이 있어서 진행하는 과정이다. 고객을 만나 질문을 할 수 있으려면 우선 질문거리가 있어야 한다. 질문이 있으려면 확인하고 싶은 핵심 가설과, 기획 의도가 있어야 한다.
조금이라도 경험이 쌓였거나 연차가 있는 이들에겐 너무나 당연한 이야기지만, 주니어 혹은 처음 진행하는 이들에겐 이 지점이 때로 생소하다.
2. 누구에게 물어볼 것인가? : 역시나 가설이 명확해야 한다
고객과 사용자는 모두 다르다. 어떤 부분에선 똑같을 수도 있지만, 다른 어떤 부분에선 전혀 다른 유형의 반응 혹은 행동을 보일 수도 있다. 그러므로 테스트하기로 한 항목이 정해지면, 이를 누구에게 물어볼 것인지가 명확해야 한다. 가령 여성 화장품의 지속력과 발림력, 피부 트러블 정도를 70대 할아버지 혹은 6살 꼬마 아이에게 물어볼 순 없는 노릇이니까.
그럼 대체 누구에게 물어봐야 할까? 이는 사실 가설과 기획 의도로 돌아가면 답이 이미 정해져 있다. 모든 가설에는 그 가설에 해당하는 주체가 정해져 있다. "A가 B의 상황에서 C를 D회 할 것이다." 혹은 정직하게 6하 원칙을 따라 " 누가 / 언제 / 어디서 / 무엇을 / 어떻게 / 왜 할 것이다. "라는 형태로든.
테스트를 통해 확인하고 싶은 것이 'B의 상황에서 C를 D회 할 것이다"라면, 이는 A에게 물어보면 된다. 테스트를 통해 확인하고 싶은 것이 "언제, 어디서, 무엇을, 어떻게 할 것이다"라면, 이는 "누가"에게 물어보면 된다.
결국 질문 설계 과정과 테스터 선정 과정에서 제일 그리고 항상 중요한 건 가설과 기획 의도다.
결국 질문 설계 과정과 테스터 선정 과정에서
제일 그리고 항상 중요한 건 가설과 기획 의도다.
3. 공급자로서의 경험이 있는 테스터는 글쎄...
다만 우리의 가설, 그리고 기획 의도와 부합하더라도 어디에선가 기존에 서비스를 기획, 디자인, 개발하는 등 '공급자'로써의 경험을 가진 이는 다소 꺼려지게 된다. 이들은 의도치 않게, 흔히 '직업병'에 의해서 모든 것들을 공급자의 시선으로 바라본다. 질문 뒤에 숨은 가설과 의도를 파헤쳐보려 하고, 테스트 항목과 상관없는 디테일을 발견하는데 능하다.
물론 이는 UT 과정 자체에 큰 영향을 주진 않을 수 있지만, 질문의 의도를 파악해 일부 왜곡되거나 오염된 답변을 하거나, 혹은 테스트와 상관없는 사항에 대한 의견, 아쉬운 점, 질문 등을 쏟아내며 담당자를 피로하게 만들 수도 있다.
시행 과정에 대한 깨달음
1. 예상 소요 시간은 넉넉하게!
우리가 준비한 질문은 5개였고, 5명을 만나기로 했으니 기껏해야 1시간 내외면 모두 완료할 수 있을 거라 생각했다. 그러나 이는 큰 착각이었다. 나의 경우 결과적으로 4시간 남짓한 시간을 할애하게 되었는데, UT가 단순히 '사람을 만나 질문을 한다'가 아니라, 구체적으로는 아래의 과정으로 진행되기 때문이었다.
- 인사 및 테스트 설명
- 테스트 수행 (안내-관찰-질문)
- 수행 및 관찰 결과 정리
- 다음 테스터 대기
- 위 과정 n회 반복
- 테스트 전체 종료 후 결과 정리, 분석
2. 질문 순서도 중요하다
가령 두 개의 테스트 항목이 모두 한 화면에서 이루어지거나, 두 항목의 진행 프로세스 중 일부가 겹치는 경우, 테스터는 앞선 테스트를 진행하는 과정에서 뒤의 테스트와 관련된 기능을 미리 인지, 학습하거나 답변을 발견할 수도 있다. 만약 특정 기능을 잘 인지 및 발견하여 도달하는지 확인하고 싶은 게 테스트의 의도라면, 이 경우 테스트는 의미가 없어질 수도 있다.
그래서 테스트 항목이 서로 상호 배타적인지, 혹은 교집합이나 의존성이 있다면 이를 최대한 서로 의존성이 발현되지 않을 순서로 배치하는 게 필요하다.
3. 테스터가 머뭇거려도 개입하지 말고 끝까지 수행하게 하자. 오답의 배경과 맥락을 배울 수 있다.
UT의 테스터가 문제 풀이 시간의 학생과 다른 점은, 오답을 내도 전혀 상관없다는 점이다. 왜냐하면 테스터의 오답 혹은 오답 풀이 과정 자체가 UT의 담당자에겐 의미 있는 학습 포인트가 되기 때문이다. 왜 이 부분에서 의도와 다르게 사용했을까? 혹은 왜 어려워했을까? 를 파악하면 된다.
그러나 이런 과정 자체가 낯설거나 기획에 대해 자신이 없는 담당자의 경우, 테스터가 버벅거리거나 의도와 다른 경로/메뉴에 진입했을 때 초조해하거나 개입을 하고 싶어 할 수도 있는데, 이 경우 오히려 오답 풀이를 충분히 발견하지 못하게 된다. 그러니 테스터가 버벅거려도 개입하지 말고, 테스터가 생각하는 대로 끝까지 수행하게 놔둬보자.
테스터의 오답 혹은 오답 풀이 과정 자체가
UT의 담당자에겐 의미 있는 학습 포인트다.
왜 이 부분에서 의도와 다르게 사용했을까? 혹은 왜 어려워했을까? 를
파악하면 된다.
4. 2인 1조로 수행하자
단순히 질문하고 답변만 얻는 과정으로 생각하여 담당자 홀로 테스트를 진행하게 되면 많은 부분을 놓칠 수 있다. (무엇보다 정신이 없다...) 2인 1조로 구성하여 한 명은 테스터에게 질문을 던지고, 나머지 1명은 과정 전반을 관찰하고, 기록하는 역할을 하자.
