NEW 기획 디자인 개발 프로덕트 아웃소싱 프리랜싱

기획

UX 리서처에게 필요한 역량, 반복하는 실수 (下)

 

사용성 테스트는 리서처가 UX 리서치에서 가장 대중적으로 사용하는 방법입니다. 팬데믹 이후 오프라인 미러룸에서 원격 화상회의 솔루션으로 사용성 테스트 방식은 달라졌지만 그 목적은 동일합니다. 사용자가 제품을 사용하면서 겪을 수 있는 여러 종류의 사용성 이슈를 겪는지 확인하고 이를 개선하는 것이죠. 핵심은 ‘확인’과 ‘개선’입니다. 최근 업계에서는 리서처의 역할이 중요해지는 동시에 디자이너나 PM이 직접 리서치를 하는 경우도 빈번한데요. 진단은 쉽게 내릴 수 있지만 처방을 내리기는 어렵습니다.

 

사용성 이슈를 겪는 것을 알아차리는 것은 겉으로 드러나기 때문에 쉽게 발견이 되는데, 어떻게 해결할지 ‘솔루션’을 제안할 때에는 여러 가지 선택의 길이 있습니다. 사용성 문제를 겪을 때 덜 헤매려면 역설적이지만 진단을 정확히 내려야 합니다. ‘아프다’를 ‘배가 아프다’로, ‘배가 아프다’를 ‘점심을 먹고 나서 배가 아프다’로, 한발 더 나아가 ‘점심에 어제 새벽배송으로 시킨 마감세일 제품 중 오렌지주스를 마시고 배가 살살 아프기 시작했다’로 집요하게 파고들어야 합니다. ‘아프다’는 ‘진통제’나 ‘소화제’를 처방하는 솔루션에 그칠 수 있지만, 집요하게 파고든 이후에는 동일한 문제가 아침, 저녁에 발생하지 않도록 예방할 수 있기 때문이죠.

 

이번 하편에서는 사용성 테스트에서 리서처가 흔히 저지르는 5가지 실수에 대해 구체적으로 말씀드리겠습니다. 먼저 상편에서 살펴봤던 리서처에게 요구되는 역량 중 필수 역량을 톺아보겠습니다. 업종과 비즈니스 성숙 단계에 따라서 UX 리서처에게 요구하는 책임과 자격요건에는 차이가 있습니다. UX 리서처에게 공통적으로 요구하는 상황과 역량은 6가지입니다.

 

[필수 역량]

  1. 비즈니스 목표에 맞게 리서치 계획(질문, 가설, 방법론)을 설계할 수 있습니다.
  2. 프로젝트 상황에 따라 정성적 조사와 정량적 조사를 병행할 수 있습니다.
  3. 리서치 결과를 분석해서 필요한 과업의 우선순위를 제안할 수 있습니다.
  4. 가장 효과적인 방법으로 이해관계자에게 커뮤니케이션할 수 있습니다.
  5. 업데이트 기능이 사용자 경험을 손상할 때 반대할 수 있습니다.
  6. 사용성 테스트(UT), 인터뷰, 서베이를 혼자서 진행할 수 있습니다.

 

사용성 테스트는 프로토타입을 사용자가 어떻게 이용하는지 관찰하면서 심각한 사용성 문제를 확인하고 이를 개선해가는 일련의 과정입니다. 과거에는 실험실 또는 UT룸, 미러룸이라고 부르는 오프라인 공간에 참여자를 초대해서 진행했지만 팬데믹 이후에는 화상회의 솔루션을 통해 참가자가 화면을 공유하고 사용하는 과정을 기록하면서 진행하는 경우가 많습니다. 사용성 테스트는 UX 리서처의 기본 과업입니다. 사용성 테스트는 누구라도 진행할 수 있지만, 의식하지 못하고 반복하는 실수가 있습니다.

 

 

UX 리서처가 사용성 테스트(UT)에서 저지르는 5가지 실수

 

1. 말을 너무 많이 합니다

사용성 테스트에서 가장 기본이 되는 기법은 ‘생각을 말하기(Think aloud)’입니다. 사용자를 편안하게 하려고 리서처가 너무 많은 말을 하거나 침묵을 견디지 못하고 개입하는 경우가 많습니다. 침묵의 시간을 가져야 사용성 테스트를 의도대로 할 수 있습니다.

 

리서처가 사용성 테스트를 진행할 때에는 디자이너, 마케터, PM 등 업무를 함께 하는 동료들이 참관할 때가 많습니다. 고객의 목소리를 직접 듣기 위해서인데요. 참관을 통해 가공, 정제되지 않은 목소리를 청취할 수 있고 필요한 경우 리서처에게 추가 질문을 요청하기도 하죠. 리서처는 여러 참관자가 함께 듣고 있는 사용성 테스트에서 침묵을 견디기 불편해합니다. 많은 사람의 소중한 시간을 할애해서 사용성 테스트를 진행하는 만큼, 사용성 테스트에서 최대한의 결과를 얻어내려는 부담감이 생기기 때문이죠. 그래서 5초 이상의 정적을 견디지 못하고 고객에게 묻거나 고객의 이야기를 정리하곤 합니다. 특히, 고객이 적극적으로 “어디를 보고 있는지”, “어떤 부분이 잘 이해가 안 되는지” 자신의 생각을 말하다가 불쑥 찾아온 정적에 침묵을 지키기 어려워하죠. 요약하면 리서처는 참관하는 동료들을 만족시켜야 한다는 부담감, 불규칙적으로 찾아오는 참가자의 침묵에 불필요한 말을 꺼냅니다.

 

리서처에게 필요한 태도는 침묵을 허락하는 겁니다. 참가자를 관찰하고 그 관찰을 통해서 사용성 문제를 진단하는 것이 목적이기 때문에 침묵 또한 참가자의 행동으로 봐야 합니다. 침묵을 받아들이고 그 침묵이 어떤 순간에 발생했는지 참가자가 다시 말을 할 때 확인할 수 있습니다. 만약 참가자가 10초 이상 긴 정적을 반복적으로 보인다면 ‘생각을 말하기’ 기법을 다시 알려주면서 생각을 말할 수 있도록 요청하는 것이 좋습니다.

 

 

2. 디자인에 대해 설명합니다

디자인에 대한 의도를 설명하는 실수를 종종 범하게 됩니다. 어떤 의도로 이런 부분을 만들었는지, 사용자가 이야기한 불편에 대해 디자이너, 개발자, 기획자를 대변하는 경우입니다. 참가자가 태스크를 수행하는 과정에서 메뉴를 찾지 못하거나, 페이지를 이탈하려고 하는 경우 “적절한” 사용방법을 설명해주기 위해 빈번하게 나타나는 실수인데요. 리서처가 사용성 테스트에서 디자인에 대해 설명을 하면 두 가지 문제가 발생합니다.

 

첫째, 디자인을 처음 접한 사용자가 어떻게 행동하는지 더 이상 확인할 수 없습니다. 리서처가 요약해서 전달하는 정보는 참가자에게 ‘해석하고 따라야만 하는 가이드라인’으로 작용하기 때문에 순식간에 관찰자 효과가 증폭되기 때문입니다. 처음 제품을 사용하는 참가자를 리크루팅한 후에 배경 정보를 전달함으로써 전혀 다른 사용자를 리크루팅 한 결과를 보여주게 되는 거죠.

 

둘째, 참가자가 리서처에게 사용성 테스트 과정에서 전달받는 정보는 ‘설명’이라기보다는 ‘반론’에 가깝습니다. 이 순간 리서처는 중립적인 ‘판사’로 인식되기보다는 기업, 서비스를 대변하는 ‘변호인’으로 보이기 때문에 참가자가 ‘생각을 말하기’ 할 때 ‘변호인’을 불편하게 할 수 있는 말을 스스로 검열하게 됩니다. 좋은 테스트는 문제를 정확하게 발견하는 것이지, 문제를 드러나지 않게 만드는 것이 아닙니다.

 

 

3. 사용자 질문에 답변을 합니다

사용자가 질문을 할 수 있습니다. 리서처는 답변을 바로 하지 않는 것이 좋습니다. 질문을 받으면 당연히 답을 해야 한다고 생각하기 때문에 의식하지 않으면 참가자에게 리서처가 대답을 하게 되죠. 사용성 테스트는 사용자가 혼자서 서비스를 이용할 때의 모습을 관찰하는 것이 목적입니다.

 

참가자가 질문을 하면 질문에 답을 하려는 리서처의 행동은 사용성 테스트에서 관찰자 역할보다 진행자 역할을 수행하려고 할 때 나타납니다. 질문에 대해 답을 하려는 것은 침묵을 견디지 못하는 것과 유사한데요. 일반적인 대화라면 상대방의 질문에 답을 하지 않는 것이 무례하다고 볼 수 있지만, 사용성 테스트는 다릅니다. 리서처는 사용성 테스트를 시작하기 전에 진행자 역할을 충분히 수행하고, 사용성 테스트를 시작한 이후에는 본연의 역할인 ‘관찰자’, ‘기록자’ 역할에 충실해야 합니다. 참가자에게 사용성 테스트를 시작하기 전에 “질문을 할 수 있지만 참가자 행동에 영향을 줄 수 있으므로 사용성 테스트를 마치고 답변해드릴 수도 있습니다”라고 반드시 안내를 해야 합니다. “혼자 사용한다고 생각하고 행동해주세요”라고 질문에 답변을 할 수도 있습니다. 마지막으로는 질문에 질문으로 답하는 방식으로 개입을 최소화하고 참가자를 관찰할 수도 있습니다. “고객 님께서는 어떻게 생각하셨어요?”와 같이 ‘부메랑’ 질문을 던져서 참가자가 생각했던 내용을 말로 전달하게 할 수 있습니다.

 

 

4. 테스트를 하기보다는 인터뷰를 합니다

사람, 창문, 실내, 스포츠이(가) 표시된 사진

자동 생성된 설명

 

때로는 사용자를 리크루팅 하는 것이 어렵기 때문에 사용성 테스트를 하면서 동시에 인터뷰나 서베이를 병행하려는 생각이 들 수 있습니다. 참가자는 인터뷰를 하면서 사용성 테스트를 할 때 전혀 다른 태도를 보일 수 있습니다. 관찰을 당하고 있다는 느낌에 답을 잘해야만 한다는 부담까지 더해질 수 있기 때문입니다.

 

인하우스 UX 디자이너, UX 리서처는 동시에 여러 프로젝트를 진행합니다. 따라서 사용성 테스트를 진행하기 위해 리크루팅 한 참가자에게 가능한 여러 리서치 질문을 던져서 답을 구하고 싶어 하죠. 문제는 많은데 해결할 시간이 없으니 한 번에 두 개의 문제를 묶어서 풀어내고 싶은 욕심이 나는 겁니다. 문제는 사용성 테스트에서 리서처의 역할이 ‘관찰자’에 한정된다는 겁니다. 대담을 진행하거나 인터뷰를 진행할 때에는 ‘관찰자’가 아니라 ‘진행자’, ‘대담자’에 가깝기 때문에 ‘관찰자’의 역할과 양립할 수 없죠. 특히 참관자들이 “이런 것도 확인할 수 있을까요?”라고 물을 때 ‘좋은 게 좋은 거지’라는 생각으로 관찰자 역할을 벗어나는 실수를 자주 범합니다. 가장 좋은 방법은 사용성 테스트와 인터뷰를 완전히 분리하는 것입니다. 시간을 줄여서도라도 사용성 테스트와 인터뷰는 다른 참가자를 대상으로 진행하는 것이 리서치 질문에 대한 답을 얻는데 효과적입니다.

 

 

5. 의견이나 의향, 선호도를 간청합니다

사용성 테스트에서 관찰자 효과가 개입되는 순간 참가자는 자기 검열을 시작합니다. 즉, “우리가 이렇게 고민을 많이 해서 만들었고요”, “그건 다른 페이지에 있기 때문에 여기서는 이용할 수 없고요”와 같이 부정적인 의견을 제시하려고 할 때마다 벽이 서있는 느낌을 받고 생각해서 말을 합니다. 사용성 테스트를 통해서 호불호나 선호에 대해 발견할 수 없습니다. 참가자는 리서처가 한 걸음 떨어져서 자신의 행동을 관찰할 때와 의견을 물을 때 다른 자아로 세션에 참여하기 때문입니다. 대부분의 경우 세션에 참여하는 고객은 참여시간, 장소, 방법에 따라 사례를 받기 때문에 ‘돈을 받는 값을 해야 한다’라는 인식과 ‘거짓을 말해도 모른다’, ‘일회성 피드백이다’라는 생각을 조합해 선호를 물을 때 상대가 듣고 싶은 말을 꺼냅니다.

 

즉, 사용성 테스트는 “앞으로 사용할 것 같으세요?”라는 질문에 대한 답을 얻는 방법이 아닙니다. 원하는 과업을 혼자서 얼마나 쉽고 빠르게 완결하는지, 그 과정에 어떤 이해와 피로도가 발생했는지 확인하는 일이죠. 사용성 테스트에서 “정말 좋은 기능이네요!”라고 말한 참가자가 기능이 출시되었을 때 사용하지 않을 가능성은 50%라고 봐야 합니다.