brunch

You can make anything
by writing

C.S.Lewis

by 플래터 Mar 02. 2022

프로덕트 팀의 첫 UT 진행 후기 (2)

테스트 결과를 정리, 분석하는 과정에 대한 깨달음 


앞선 두 편의 글에선, UT에 관한 간략한 정리와, 새로 편성된 프로덕트 팀의 첫 프로젝트에 UT를 도입하며 사용한 프레임워크, 그리고 UT를 준비하는 과정과 시행하는 과정에서의 깨달음에 대해 공유했다.


이어지는 아래의 내용은 UT의 결과를 정리, 분석하는 과정에서  깨닫거나 배운 점이다.




정리 및 분석 과정에 대한 깨달음 



1. 무엇을 상상했던, 현실은 다르다. 고객은 역시 직접 만나봐야 한다. 

기획과 디자인을 하고, 테스트 항목을 선정하는 과정에서, 어떤 점이 문제이거나 어떤 대답이 나올 거라는 상상 혹은 기대를 은연중에 하게 된다. 그러나 테스트 과정에서 발견한 이슈 혹은 돌아온 대답은 예상과 전혀 다르기도 하다. 결국 가설은 어디까지나 가설일 뿐이었다. 고객은 역시 직접 만나봐야 안다.


가설은 어디까지나 가설일 뿐이었다. 고객은 역시 직접 만나봐야 안다.



2. 숫자가 적어도 의미는 발견할 수 있다.

A/B 테스트 등 정량적 방법론에서는 "통계적으로 유의미한가?"라는 질문을 하게 된다. 여기에는 p-value, 외부요인 등 여러 의미가 있을 수 있겠지만, 이는 주로 "표본의 수가 충분한가?"라는 의미이다. 다시 말해, 테스터를 충분히 모집했는가?라는 의미인데, 그러나 UT는 정성적 방법론이다. 즉, 테스터의 숫자가 주요한 요소는 아니다.


가령 나의 경우 5명을 우선 만나보았는데, 놀랍게도 5명 모두 테스트 항목에 대해 유사하거나 동일한 반응을 보였다. 문제가 되는 부분은 5명 모두 문제가 되었고, 문제가 아닌 부분은 5명 모두 문제가 아니었다. 즉, 테스터의 숫자가 통계적으로 유의미할만큼 많지는 않지만, 확인하고 싶은 부분은 충분히 확인할 수 있었다. 


(이는 아마도 통상적인 기대치, 혹은 학습된 경험치와 습관 때문이었거라고 생각한다. 이례적인 서비스 혹은 큰 규모의 프로젝트나 프로덕트, 그리고 전문 ux 리서치를 병행하는 곳에서라면, 테스터의 규모도 다르지 않을까.)



3. 기억은 금방 소진된다. 복기, 정리, 분석은 바로바로 하자

테스터 한 명에 5개의 테스트를 진행했다. 테스터의 반응이 아무리 예상과 다른 점이 있다 한들, 그리 복잡한 프로덕트가 아니었고, 복잡한 테스트 항목이 아니었다. 거기에 테스터의 직접적인 반응과, 관찰자로서 관찰한 내용까지 기록까지 하고 있으니, 테스트 당시의 상황과 결과를 명확하고 정확하게 기억할 수 있다고 생각했다. 오산이었다.


기억은 금방 소진된다. 그리고 방금 테스트를 마쳤는데도, 진행자와 관찰자의 기억이 서로 다르기도 했다. 만약 녹화나 녹음을 하지 않는 상황이라면, 한 명의 테스트가 끝난 뒤에는 바로 복기, 정리, 분석 시간을 갖도록 하자. 



4. 관찰한 것과, 응답자가 말한 것 사이에도 차이가 있다

테스터가 직접적으로 의견 혹은 질문을 주거나 기타 반응을 보인 곳이 아니더라도, 테스트 과정 자체에서 몸짓과 눈빛 혹은 기타 신호로 반응을 보이는 경우가 있다. 말과 행동은 종종 괴리가 발생한다. 그건 사용자라고 해서 다르지 않다. 그래서 둘을 분리하여 적어두고, 분석/정리하는 과정에선 함께 참고하면 조금 더 깊게 이해할 수 있다. 

말과 행동은 종종 괴리가 발생한다. 그건 사용자라고 해서 다르지 않다. 



5. 테스터는 이런저런 피드백을 함께 곁들여준다 (단, 그걸 다 반영하는 게 목적이 아니다)

때에 따라 다르지만, 테스터로 선발된 이들은 이미 서비스를 경험해보았거나, 단순한 경험 너머 관심이 있는 이들이기도 하다. 그래서 제품 출시 전 UT를 진행하는 과정에서 접한 새로운(혹은 리뉴얼된) 프로덕트에 대해 여러 질문과 의견, 혹은 기존에 궁금하거나 아쉬웠던 점들을 쏟아낼 수도 있다.


물론 이는 프로덕트의 성장을 책임지는 프로덕트 담당자로써는 소중한 고객의 목소리이나, 다만 이는 UT를 통해 확인하려는 것과는 별개일 수 있다. UT는 어디까지나 가설과 기획의도에 대해 학습하려는 용도이다. 이와 전혀 무관한 부분에 휩쓸리면, 테스트의 인사이트와 향후 계획이 전혀 엉뚱한 곳으로 향하는 수가 있다.


테스트 항목에 대한 피드백과, 기타 피드백을 분리하고, 필요하다면 기타 피드백은 별개의 테스크나 프로젝트에 참고하면 된다. 



마치며..


총 세 편의 글을 통해 프로덕트 팀으로써의 첫 UT 도입기를 정리해보았다. 


프로덕트를 기획하고 개발하고 운영하는 세상의 수많은 조직과 팀이 이보다 훨씬 숙련된 경험과, 더욱 정밀하고 세련된 방법론으로 고객에 대해 학습하고 있을 테니, 내가 공유하는 내용은 어쩌면 너무 기초적이거나 당연한 내용일지도 모르겠다.


그러나 모든 배움은 결국 자기 자신의 배움이어야 의미가 있다고 생각한다. 어떤 크고 멋진 조직과 팀이 무엇을 어떻게 했든지 간에, 자기 자신의 경험과 깨달음이 아니라면 금방 휘발되고 만다. 


그리고 무엇보다도 모두에게는 다 때에 맞는 저마다의 시행착오와 학습이 있다고 믿는다.


서비스 기획, 프로덕트 매니저, 혹은 또 어떤 역할 혹은 직무가 되었든, 프로덕트를 기획하고 개발하며 고객을 만나야 하는 이들 혹은 이런 일을 준비하는 이들에게 조금이나마 참고 혹은 타산지석이 되기를 바란다. 



더 많은 지식과 경험, 노하우가 궁금하다면

홈페이지 방문하기

뉴스레터 구독하기

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari