유저의 생각을 묻지 않고 아는 법

사용성 테스트에서는 카메라를 끕니다.

작은 조직에서는 최소한의 리소스로

모든 UT는 최대 30분으로 제한해요. 30분 이상이 되면, 참여자 모두의 집중력과 체력이 떨어져서 긴 시간을 진행한다고 해도 유의미한 인사이트가 나오지 않더라고요. 그런 의미에서 시나리오를 철저하게 준비하는 것도 무척이나 중요했어요. 테스트 환경 속에서 최대한 사용자의 실제 행동을 이끌어내고, 우리가 검증해야 하는 것들에 대한 답을 알아낼 수 있는 질문이 무엇인지 생각하는 과정에 많은 시간을 썼어요. 많은 시행착오를 겪기도 했고요. 아직까지 어려운 부분이기도 합니다.

가장 최근 진행한, Customer Job을 중심으로 계획한 시나리오 (꼭 확인해야 하는 것들을 적어둡니다.)

실제로 초반에 진행했던 UT에서 개선 전, 개선 후 제품 이미지를 보여드리면서 ‘무엇이 더 나은가요?’라는 질문을 하기도 했어요. 이때 알게 된 점은, 사용자는 ‘개선’이라는 용어로 인해 실제 자신이 느끼는 효용과 관계없이 ‘개선이 되었으니 더 좋다’는 생각을 무의식적으로 하게 된다는 점이었어요. 답을 유도할 수도 있는 편협한 질문이었던 거죠.

좋지 않은 예시. 2022년 3월에 진행했던 내부 사용성 테스트 시나리오

또 사실과 경험에 기반해 답할 수 있는 질문이 아닌, ‘~면 어떠실 것 같나요? 저희 제품을 쓰실 것 같나요?’등의 미래지향 질문으로 명확하지 않은 인사이트를 묻는 실수도 많이 했었네요.

참여자는 UT를 진행할 모더레이터 한 명과 모든 행동과 말을 관찰하고 기록할 옵저버 한 명으로 구성하여 진행하고 있어요. 모더레이터는 사용자의 행동에 따라, 우리가 얻고자 하는 인사이트를 최대한 얻어낼 수 있는 적합한 질문으로 답을 이끌어낼 수 있는 진행력과 판단력이 있어야 해요. 전체적인 분위기를 읽어내며 사용자분의 답변에 따라 우리가 확인해야 하는 가설들을 최대한 많이, 확실하게 검증할 수 있도록 방향을 이끄는 중요한 임무를 합니다. 옵저버는 사용자와 교류에 집중한 모더레이터가 놓칠 수 있는 사소한 부분들을(사용자의 행동, 언어와 표현 등) 캐치하여 기록을 하는 역할을 해요.

한 명이 진행하는 경우는 되도록이면 지양하고 있어요. 사용자 모수가 많지 않은 초기 제품, 작은 조직에서는 사용자 한 분과 만나는 30분이란 시간이 매우 소중하거든요. 한정된 시간에 우리에게 의미 있는 것들을 건져내는 것이 무척 중요해요.

사용자의 생각을 묻지않고 아는 법

보통 저희 팀은 온라인 UT를 가장 많이 진행하였는데요. 몇 가지 요령을 공유하자면, 우선 카메라는 쌍방으로 끄고 진행하는 것이 좋아요. 테스크를 드리는 UT를 하다 보면 사용자분이 저희의 표정과 반응 등을 통해 학습을 하시더라고요. 이렇게 하면 내가 ‘잘’하는 것이구나! 하고요. 그럼 유효한 인사이트를 얻어내기가 힘들어져요. 그래서 테스트에 대해 말씀드린 후, 시작 전 카메라를 끄고 진행하실 수 있도록 안내드립니다.

온라인으로 진행된 실제 UT 진행 모습

카메라를 끄면 우리가 볼 수 있는 건 사용자분이 화면으로 공유 해주신 프로토타입 혹은 제품 이미지이기 때문에, 마우스나 트랙패드를 사용하여 시선 이동에 따라 함께 움직여달라고 요청을 드려요. 그럼 사용자분의 공유된 화면 속 마우스 커서의 이동에 따라 우리도 ‘관찰’에만 집중할 수가 있어요. 주의할 점은 우리가 마우스 커서에 집중하고 있을 것을 알고 있는 사용자의 행동에 보정이 일어나는 것인데요. 즉 자연스러운 사용성을 보기가 어려워진다는 의미로, 미리 방지하기 위해 어디를 보고 있는지 소리 내어 말씀해달라고 하는 것도 도움이 되더라고요.

앞서 언급된 Root cause를 알아내는 팁으로는, 사용자의 의견에 대한 꼬리질문을 하는 것인데요. 그렇게 말한, 행동한 근본적인 이유를 알기 위해선 끝없이 집요한 질문을 던져야 합니다. 포인트는 인터뷰이의 말하는 습관과 언어 그대로 앵무새처럼 따라하는거예요. ‘방금 ~하셔서 ~하다고 말씀해주셨는데, 혹시 그 이유가 뭘까요?’ 처럼요!

테스트를 진행했으면 이제 더 중요한 것을 해봅시다

주관적인 판단이 최대한 배제된 결과만을 팀원들에게 가장 효과적으로 전달할 수 있는 방법에 대해서는 저희도 아직 많은 고민을 하고 있어요. 사실 내가 한 디자인과 함께 고민한 기획이 잘못되었다는 것을 인정하는 것은 쉽지 않은 일이에요. 좋지 않은 사용성을 사용자의 환경 혹은 여러 가지 탓으로 돌리며 합리화하는 것이 가장 쉽죠. 하지만 앞서 말한 것처럼, 테스트의 목적 자체가 제품의 방향성을 찾거나, 확인의 목적이 되어서는 안됩니다. 우린 항상 의심하고, 검증하기 위해 프로덕트를 더 나은 방향으로 개선하기 위한 근거 자체에 귀를 기울여야 해요.

실제로 입사 초반에는 ‘실제 제품이 아니여서, 우리의 ICP가 아니여서, 설명을 잘 읽지 않아서, 내부인원이여서’ 등 여러가지 이유로 제품에서 일어나는 문제를 합리화하려고 했던 적도 있었던 것 같아요. 그렇기 때문에 제대로된 인사이트를 얻지 못하고, 제품을 개선시킬 수도 없었어요. ‘역시 내 생각이 맞았어!’를 확인받기 위한 목적의 UT를 진행했던거죠.

UT 이후, 팀원들에게 공유하기 위한 인사이트 노트

많은 시행착오를 겪은 후, 현재는 우리가 발견한 문제점, 예상과 달랐던 점, 사용성 문제에 대한 근본적인 원인을 최대한 ‘N명 중 N명’이 ~인지, 이해 혹은 작동함’과 같은 건조한 인사이트로 도출해내려고 노력하고 있어요. 이 과정 중에서 사용성 문제의 근본적인 원인 즉, Root Cause을 찾아내는 것은 아직까지도 쉽지 않은 것 같아요. 결국에는 사용자분에게 직접 이유를 묻지 않고 ‘관찰’과 ‘정성적인 데이터’를 통해 진짜 이유를 찾아내는 것 또한 저희의 역량이죠.

콜라보(callabo)를 이용해 사용자의 언어를 기록하고 녹화본도 전달합니다.

UT 이후 인사이트를 ‘잘’ 전달하는 것도 중요해요. 팀원들에게 결과를 전달할 때도 최대한 인터뷰이의 말투 그대로 전달하는 것이 효과적이에요. 내부 인원의 언어로 희석되어버리면 팀원들에게 깊이 있게 다가가지 않는 것 같더라고요. 그 당시 말을 한 시점의 이미지나 영상 등을 녹화하여 공유하는 것도 좋은 방법입니다.

그래서, 제품을 만드는데 도움이 되었냐구요?

물론이죠. 솔직하게, 1년이 넘는 시간 동안 완벽한 UT를 진행한 횟수는 손에 꼽을 수도 있을 것 같아요. 그만큼 사용자 리서치는 이론을 아는 것도 중요하고 상당히 체계적으로 준비를 해 임해야 하는 영역이라는 걸 몸소 느낄 수 있었어요. 대충 물어본 질문에는 대충 생각해낸 답변밖에 들을 수 없었죠. 우리가 제품을 만들어가면서 가장 핵심이 무엇인지, 그 안에서 무엇을 꼭 알아야 하는지 우선순위화하고 목적에 맞는 리서치를 진행하는 것이 중요한 것 같아요. 목적이 있으면 방법을 구체화하기 쉬워지고 그저 실행만 하면 되니까요.

‘사용자는 이렇게 생각하지 않을까?, 이렇게 행동하지 않을까?’와 같은 뜬구름 같은 물음표를 확실한 마침표로 알아내고 제품에 녹여내니, 우리가 만들고 있는 것이 좀 더 선명해지고 단단해지는 느낌이 들었어요. 꼭 사용성 검증을 위한 테스트뿐만 아니라, 그냥 무작정 사용자들을 만나보는 것도 추천해요. 간단한 커피챗도 좋고, 가능하다면 고객사를 만나는 팀 외부 미팅에 참여 해보는 것도 좋아요. 내가 만드는 제품을 쓸 사람들이 어떤 사람인지, 뭘 좋아하는지, 어떤 걸 싫어하고 불편해하는지, 어떤 습관들을 가지고 있는지 머릿속에 그려놓고 디자인을 하는 일은 흐릿한 가설로만으로는 나올 수 없는 선명한 결과물을 만들어낼 수 있더라고요. 내가 알기 힘든 것들을 잘 알고 있는 사람들을 찾아 이야기를 들어보세요! 아마도 찾아 헤매던 마침표가 거기에 있을 거예요.