스타트업은 '게릴라 테스트'로 무장하세요. (part 2/2)

스타트업이 초기 UX검증을 위한 게릴라테스트를 해야만 하는가에 대한

5가지 이유를 설명합니다.

들어가며

지난번 글에서는 게릴라테스트는 무엇이고 어떤 특성이 있으며, 어떤 상황에서 어떻게 진행을 하는 것이 좋은지에 대해서 알아보았습니다. 이번 글은 좀더 실용적인 면에서 접근해 볼까 합니다. ‘왜 게릴라 테스트를 사용해야 하는가?’ ‘어떤 이점이 있는가?’ 라는 질문에 대답하려 합니다. 단순히 비용이 매우 적게 들고, 시간이 짧게 걸린다는 대표적인 장점이 있긴 하지만, 다른 한편으론 비공식적이고 충실도가 매우 낮으며low-fidelity, 전체가 아닌 매우 구체적인 테스트 목표 항목만이 실행 가능한 이 게릴라테스트의 유용성에 대해 의구심이 듭니다. 또한 심화테스트의 품질과는 큰 차이가 있을 수 있는 상황에서 과연 어떤 실제 이점과 혜택이 있는지 하나 하나 이야기해 보았으면 합니다.

게릴라 테스트를 사용해야만 하는 5가지 이유

1) 빠르고도 밀도 있게, Quick but not Dirty

일반적인 게릴라 테스트는 ‘Quick and Dirty’ 라고 알려져 있습니다. 빠르게 Quick이라는부분이야 쉽게 이해가 됩니다. 준비도 심화테스트에 비하면 얼마 안 걸리고, 비용결제에도 시간이 짧게 걸릴 것이고, 실 테스트 역시 단독 기능이나 UX테스트 정도이지, 어떤 시나리오를 갖고 진행하는 것이 아니기에 10-15분 정도면 충분합니다. 우리가 중점적으로 봐야할 부분은 일반적으로 ‘Dirty’라고 말하는 부분을 그냥 그 자조적인 상태 ‘Dirty’에 두지 말고 ‘Quick and Clean’으로 개선을 할 방법을 찾아야 한다는 것입니다.

먼저 왜 ‘Dirty’라고 하는지에 대한 원인에 집중해야 합니다. 그 원인의 대부분은 게릴라 테스트 대상이 실제 프로덕트/서비스가 출시되었을 때 사용하게 될 사용자의 프로필과 매우 다를 수 있기에 ‘의미 있는 데이터를 제공하지 못한다’ 면이 부각되어 있기 때문입니다. 매번 의미 없고, 일회성, 단면적인 데이터이기에 ‘Dirty’라고 칭할 수 있는데, 그 부분이 ‘의미’를 만들기 위해선, 그 데이터들의 수집이 매우 전략적이어야 합니다.

첫째, 카페에서 테스트 대상을 고를 때 실제 사용자 군과 비슷할 수 있는 테스트 대상을 고르려 노력해야 하고, 그들을 통해서 지인, 친구들과 같은 비슷한 테스트대상을 소개받아 테스트할 수 있는 환경을 조성해야 합니다.

​
둘째는, 여러 개를 너무 무작위로 테스트하기 보다는 집중적으로 테스트할 수 있는 4-5개의 항목으로만 줄여 접근을 하면 훨씬 더 밀도 있는 테스트 데이터 확보가 가능합니다.

​
세 번째는 가장 중요하고 실제 게릴라 테스터에게 의존하는 부분이 아닌, 테스트를 진행하는 디자이너나 사용자 리서처에 의해서 획기적으로 개선될 수 있는 부분입니다. 질문이나 테스트 진행에서 ‘편향 bias’을 줄이겠다는 노력을 의도적일지라도 열심히 해야 합니다. 그러면 훨씬 양질의 테스트 데이터를 얻을 수 있습니다.

사용자에게 어떤 유도 질문이나 설명을 피하고, 그들에게 충분한 테스트 자유를 주는 최소한의 질문과 설명을 해야 합니다. “사용자는 이런 이런 것을 하고 싶습니다. 그런데, 지금 상황이 이렇게 되니 이렇지 않을까요? 그러면 이런 상황에 우리는 어떻게 하는게 맞을까요?” 이런 질문이나 설명은 벌써 “이런 상황이라니 난 이렇게 해야 하나 보네.” 라는 상황의 제한을 테스터에게 주입하게 되어 올바른 테스트를 기대하기는 힘들게 됩니다. 또한 테스트 도중 동감을 표현하는 반응이나, 얼굴의 인상을 남김으로 편향을 유도해도 안됩니다.

내가 얻고자 하는 데이터를 확인하는 과정이 아니라, 테스트를 통해 내가 지금까지 프로덕트/서비스에 대해서 인식하고 있는 모든 사전 지식이 잘못 되었을 수 있다 라는 생각으로 임해야 합니다. 이 세가지를 잘 지켜주는 것 만으로도 충분히 ‘Clean’하고 품질이 좋은 데이터를 얻을 수 있으며 다음 게릴라 테스트를 위한 베스트프랙티스라는 자산을 만들어 줍니다.

2) 사내 분위기를 활기 있게 하고 의미 있는 데이터를 생성합니다.

아무리 규모가 작은 스타트업이라고 해도 각자 옆의 내 동료가 하는 일을 속속들이 다 알 수는 없습니다. 스타트업에서 일하는 분들은 대기업이라면 몇 명의 전문가들이 나눠서 하는 일을 혼자서 해내는 경우도 허다합니다. 특히나 디자이너가 하는 일을 개발자가 다 알 수도 없을뿐더러, 별로 알려고 하지 않은 것 역시 관심의 부족이라고 하기 보다는 나에게 할당된 업무가 과다함에서 오는 시간의 부족인 경우가 많이 있습니다.

하지만 잊지 말아야 하는 절대절명의 중요한 사실은 “모든 구성원이 하나의 목표와 운명을 가진 한 팀”이라는 사실입니다. 누가 잘하는 것이 중요한 것이 아니라 모두 잘해야 그 프로덕트/서비스의 성공 확률이 높아집니다. 외부에서 제 3자와 진행하는 게릴라 테스트를 사내에서도 똑같은 방법으로 진행하십시오.

동일목표를 갖고 있는 한팀이라는 사실을 기억해 내는데 오랜 시간이 걸리지 않습니다. 일반적으로는 모든 멤버들이 연결되고 서로가 도움이 되기를 원합니다. 그럴 기회가 없었을 뿐인데 특히 그런 기회의 진입 장벽이 게릴라테스트와 같이 형식이나 사전지식이 별로 없어도 되는 상황에선 의견을 말하고 기여하는 것에 대해서 즐거워합니다. 외부 워크샵이나 단합대회, 회식을 통해서 얻을 수 있는 것보다도 더 많은 것을 얻을 수도 있습니다.

지금까지 바쁘다는 핑계로 쌓였던 필요 없는 오해를 해소할 수 있을 뿐만 아니라, 각 멤버들에게 인사이트를 나눌 수 있는 좋은 기회가 됩니다. 또한 이렇게 모인 데이터를 갖고 외부에서 게릴라테스트로 얻어진 데이터와 어떤 부분에서 공통점이 발견되었고, 또 다른 지에 대해서 그 결과를 나누십시오. 프로덕트/서비스에 대한 객관적인 관점을 얻는데 이것보다 빠르고 저렴한 방법을 생각하기 어렵습니다.

3) 기업 문화 개선에 기여한다.

초기 형태의 스타트업을 지나면 리더십팀 역시 모든 팀 멤버의 업무를 상세하게 알 수 없습니다. 위의 2)번에서 행한 회사내부에서의 게릴라 테스트는 디자인팀에 대한 이해도를 높였을 것이 분명합니다. 일반적인 팀 소개 슬라이드로 각각의 역할을 소개하는 것이 아닌 실제 테스팅에 모든 사원들을 참여시킴으로써, 이런 종류의 테스트가 얼마나 중요한 것이고, 사용자 리서치를 통해 어떤 가치를 발견할 수 있는지를 알릴 수 있습니다.

또한 투자자나 리더십팀에 디자이너의 역할이 단순히 예쁜 그림을 뽑아내는 일이 아니라는 것을 보여주고 추후에 게릴라테스트를 준비할 때 조금 더 높은 이해도로 지원을 받을 수 있습니다. 이 부분은 단순히 재정적지원만을 이야기하는 것이 아닌 기업의 문화를 만드는 면에서 매우 중요한 강조점이 있습니다. 사용자 피드백을 받는 것이 어떤 프로세스 보다 중요하고, 그 프로세스는 실제 개발 전 프로덕트 디자인 단계에서 행해야 하며, 비용에 여유와 준비가 된다면 게릴라테스트 보다는 좀더 전략적인 테스트 방법을 생각해야 한다는 관점을 만들어 줍니다.

이것은 단순히 한두번의 사내 게릴라 테스트로는 부족할 수 있으나, 완벽할 필요는 없지만 이 프로세스를 문서화하고, 캡쳐 되고 분석된 데이터는 모두에게 공유하고 거기에 디자인팀의 인사이트를 첨가한 의견을 제공할 수 있어야 합니다. 실제 스타트업에서 가장 부족한 부분이 테스트부분이라 할 수 있는데, 컨셉을 만들 때와 디자인 단계에서의 검증테스트에서 걸러내지 못하는 문제는 실제 개발과 릴리즈 시기에 발견하게 되면 100배 이상의 비용이 발생하게 됩니다.

4) 편향이 최소화된 데이터를 얻을 수 있다.

위의 1)번에서 ‘clean’한 데이터를 얻기 위해서 ‘편향’을 최소화하기 위한 노력을 해야 한다고 했습니다. 노력에 의해서 편향이 최소화된 ‘clean’한 데이터의 품질을 올릴 수는 있겠지만, 게릴라테스트는 태생적으로 매우 편향이 적은 데이터를 얻을 수 있는 조건을 환경적으로 갖고 있습니다. 테스터들이 느끼는 상대적인 익명성과 자유감 때문입니다.

일반적으로 테스트와 관련된 공식적인 환경을 없애고 단순히 사무실 카페테리아 나 커피 숍에 있는 사람들에게 접근하면 갑자기 다른 방식으로 사람들의 반응이 열립니다. 사람들은 이런 환경에서 더 솔직 해집니다. 지난 글에서도 강조했지만, 메모를 작성하지 않는 테스트 의뢰자(주로 디자이너나 사용자리서처)의 모습에 테스터는 자신의 생각과 행동이 활발하게 기록되고 있다는 사실을 잊습니다.

자세한 사전지식이나 맥락을 이해하지 않아도 되기에 테스터는 의뢰자의 감정을 상하게 하거나 테스트프로세스를 탈선시키는 것에 대해 걱정하지 않게 되고 비공식적인 환경과 순간적인 질문에 테스터가 더 솔직하게 답변합니다. 테스터로서 해방감을 주는 경험이기도 합니다. 즉석에서 테스터에게 작업을 의뢰할 때는 접근 방식에서도 종종 창의력이 요구되기도 합니다. 하지만 상황에 당황하지 않고, 즉흥적으로 적응하는 것도 매우 중요합니다. 종이 프로토 타입, 손으로 그린 ​​와이어 프레임과 같은 충실도가 매우 낮은low-fidelity 솔루션을 통해 매우 자유로운 경험 하에서 편향을 최소화 시킬 수 있는 장점이 있습니다.

이 부분은 경험 많은 디자이너와 사용자리서처의 역할이 매우 중요합니다. 균형감 있는 질문과 시나리오에 즉흥상황에도 적절하게 반응하는 것이 가장 좋은 사용자 데이터를 얻는 방법이기 때문입니다.

​5) 개인정보보호 및 제품 기능 누설 문제를 최소화할 수 있다.

개인 정보 보호는 모든 프로덕트/서비스에서의 지속적인 관심사이지만 기업 환경 스타트업에서도 큰 주제가 됩니다. 게릴라 테스트는 자유로운 형태의 테스트라는 특성으로 실제로 주요 개인 정보 보호를 강하게 요구하지도 않고, 저장도 하지 않음으로써 이 주제에서 유리할 수 있습니다.

또한 이 부분은 스타트업 기업에도 큰 장점이 되는데, 전체 프로덕트의 작은 조각을 가져와 최소한의 컨텍스트로 테스트를 진행하기에 심화 테스팅을 외부에서 행할 때 반드시 필요한 NDA(Non-Disclosure Agreement)와 같은 제품에 관한 기밀 누설을 걱정하지 않아도 됩니다. 그 작은 부분만을 보여주고 테스트를 진행함으로써 무엇을 만들고 있는지 설명할 필요가 없습니다.

마무리

2회에 걸쳐서 게릴라 테스트의 개념, 특성과 진행방법, 그리고 꼭 사용해야 하는 이유에 대해서 설명을 드렸습니다. 저는 이 게릴라 테스트를 옹호하기 위해 좀더 엄격하고 디테일한 심화 테스트에 대한 필요성에 의문을 말하는 것이 아닙니다. 두말할 것도 없이 심화테스트 역시 꼭 거쳐야 하는 과정입니다. 그것도 매우 집중적이고 광범위하게 이루어져야 합니다. 게릴라 테스트의 장점은 프로덕트/서비스의 초기 단계에 매우 빠르고 저렴하게 그 방향성을 확인하고 검증할 수 있는 방법입니다. 그리고 이해관계자의 동의를 어렵지 않게 얻어낼 수 있지요.

하지만 게릴라 테스트를 통하여 얻을 수 있는 많은 인사이트와 피드백은 빠르고 저렴한 준비과정으로는 얻을 수 없습니다. 테스트를 준비하는 과정은 전략적이고 경험적이어야 합니다. 그래야 그 테스트를 통하여 다음 단계를 실수 없이 준비할 수 있는 통찰력을 얻을 수 있습니다. 시간이 없고 비용이 없다고 그냥 넘어가지 마십시오. 아무리 보이는 상황이 어렵고 힘들고 타이트하다고 해도 그런 이유만으로 여러분의 프로덕트/서비스에게 실패할 기회를 허락하지 않으셨으면 합니다.

여러분들을 늘 응원합니다.
감사합니다.