사용성 테스트 오해 6가지
사용성 테스트 배우기 #15
사용성 테스트 오해 6가지
사용성 테스트 오해 6가지에 대해 얘기하고자 합니다.
Jess Hutton의 원문을 번역했습니다.
지금까지 만들어진 모든 디자인에는 유저가 있습니다. 하지만 모든 경험이 유저를 염두에 두고 만들어지진 않았습니다. 때론 디자이너들이 유저에 대해 충분히 알지 못했기 때문에, 때로는 다른 일을 하기에 기한이 너무 촉박한 거죠. 하지만 결국, 디자인과 매일 상호작용하는 것은 유저이고, 디자인을 더 낫게 만들 수 있는 것도 유저입니다.
사용성 테스팅은 제품이 아직 디자인 단계에 있을 때, 불쾌한 사용자 문제를 잡아내 줍니다. 그런데 왜 그렇게 많은 조직에서 사용성 테스팅 시작하기를 망설일까요? 제 경험을 들어 말하자면, 모든 UX 담당자들이 다음과 같이 얘기하는 상사와 팀 리더에 대한 스토리를 하나씩, 또는 십여 개 씩 가지고 있는 것 같더라고요.
“우리는 사용성 테스트를 할 수 없어. 왜냐면…”
너무 비싸잖아
시간과 자원의 낭비라고
편파적이고 인위적이야
충분한 수의 유저에게 테스트하는 것은 불가능해
불필요해. 유저는 전문가가 아니잖아.
"쓸모없어. 마켓 리서치랑 경쟁사 분석했잖아”
이번 글에서는 이 모든 이의제기에 답해보고, UX 담당자들에게 사실 사용성 테스팅은 모든 프로젝트에 있어서 옳은 일임을 의심하는 사람들을 확신시키는데 필요한 탄약을 드리도록 하겠습니다.
이의제기#1. 유저 테스팅은 너무 비싸다
제한 없이 유저 테스팅을 하고 싶긴 하지만, 우리는 프로젝트에 제한 상황이 있다는 것을 인지해야 하며 예산은 보통 큰 문제가 됩니다. 때때로, “사용성 테스팅은 우리가 아무도 원하지 않는 제품을 만들 확률에서 구해줄 거야.”라고 말하는 것으로 충분할 수 있지만, 예산을 절대 늘릴 수 없는 상황이라도, 괜찮습니다.
일부 유저 테스팅 플랫폼은 엄청 비싸긴 하지만, 그게 유일한 옵션은 아닙니다. UserTesting.com과 같은 플랫폼은 우리가 테스트하는 사람들의 인구통계적 정보를 포함해 테스트의 모든 상세 내역을 각 상황에 맞게 맞춤 조정할 수 있어 비쌉니다. 굉장히 독특한 제품 또는 서비스라면, 유저 필드를 좁히는 것 완벽한 선택입니다. 이혼 변호사는 자기 홈페이지에 대해 행복하게 결혼생활을 하는 사람들이 가지고 있는 의견에는 관심이 없겠죠. 하지만, 커피 배달 서비스를 하려는 로컬 커피 회사의 경우, 고객 베이스의 범위는 새로운 것을 좋아하는 20대 힙스터에서부터 장 보러 나갈 수 없는 집에 있는 은퇴자까지 다양할 것입니다.
유저의 인구통계적 특징이 다양하다고 가정해보면, 싸고, DIY인 유저 테스트를 일찍, 자주 할 수 있습니다. 이런 즉흥 테스트를 게릴라 테스팅이라고 하는데, 그 이름이 보여주는 대로, 야생에서 무작위로 선택한 유저에게 테스트하는 것입니다. 유저가 나중에 원하지 않을 무언가를 만드는 일에 너무 낳은 시간과 돈을 쏟기 전에 프로젝트의 사각지대를 들춰내 줄 것입니다.
여기서 오직 필요한 것은 짧은 커피숍 세션으로, 팀 멤버 한 명이 가서 다양한 커피숍 손님들에게 커피 한 잔 사주는 대신 웹사이트에 대한 생각을 얘기해줄 수 있는지 물어보는 것입니다.
디지털로만 일을 하는 팀의 경우에는, 게릴라 테스팅을 하는 것이 어려울 수 있습니다. 하지만 여전히 저렴한 테스팅을 할 수 있죠. 지금 사이트를 방문한 방문자로부터 의견을 구할 수 있는 서베이나 설문지 이용할 수 있게 해주는 Qualaroo와 같은 적절한 가격의 프로그램도 있습니다. 그리고 UsabilityHub는 합리적인 가격에 빠르게 할 수 있는 첫인상, 선호도 테스트 및 내비게이션 테스트를 제공합니다.
이의제기 #2. 유저 테스팅은 시간과 자원의 낭비이다
정말요? 그들은 유저 테스팅이 유저가 원하지도 않고 유용하지도 않은 프로젝트 론칭을 예방할 수도 있다고 했던 말을 못 들었나요?
테스트가 성공하건 실패하건 간에, 만일 팀이 웹사이트, 앱, 비즈니스, 제품 등 개선할 수 있는 방법을 배울 수 있다면, 결국에는 이득을 얻게 될 것입니다. 물론, 테스팅을 안 하는 것으로 약간의 돈과 시간을 절약할 수는 있지만, 그렇게 안 하면 우리가 제공하는 것을 유저가 좋아할지 안 좋아할지 어떻게 알 수 있을까요?
실제 소비자 3명에게만이라도 제품을 이용해 보게 하면 팀원들이 인지하지 못했던 장애물을 발견하게 될 것입니다.
예를 들면, Digital Loom의 개발자인 Drupal은 New EnglandFoundation for the Arts (NEFA)의 웹사이트를 다시 만드는 업무를 맡았었는데, 유저 테스팅에 대해 애매한 태도를 취했었습니다. NEFA의 웹사이트가 가진 주요 목적 중 하나는 이 기관을 위한 기부금을 모으는 것이었습니다. 몇 번의 유저 테스팅을 한 후에, 사람들이 ‘기부하기’라는 버튼을 예전보다 더 찾는다는 것을 빠르게 찾을 수 있었습니다. 유저에게 주어졌던 태스크는 단지 ‘기부하라’는 것이 전부였는데도 말이죠. 만일 Digital Loom가 소수의 유저가 사이트를 이용하는 것을 관찰하기를 애쓰지 않았다면, 그들은 절대 버튼이 보이지 않는다는 점을 발견하지 못해 NEFA의 기부를 잃었을 것입니다.
이의제기 #3. 유저 테스팅은 객관적이지 않아서 결과가 현실적이지 않다.
유저가 부자연스럽다고 느끼는 상황에서 유저 테스트가 많이 진행된다는 것을 알고 있으며, 모더레이터는 테스트 프로젝트를 계획하는 역할을 한다는 점에 서 봤을 때 공정한 관찰자가 아닐 수 있습니다. 게다가 테스트 질문은 우리가 거기에 얼마나 많은 시간을 쏟았건 상관없이 절대 완벽히 중립적일 수 없습니다. 하지만 괜찮습니다!
MeasuringU의 설립자 Jeff Sauro가 말했듯이, 사용성 테스팅은 인공적입니다.
"우리가 관찰하거나 기록하는 동안, 실제 유저가 그 소프트웨어를 가지고 할 만한 행동에 최대한 가깝게 모의시험하기 위해 최선을 다합니다. 하지만, 아무리 태스크, 데이터, 소프트웨어 또는 환경에 현실성이 있다고 해도, 그 모든 것이 부자연스럽다는 사실을 바꿀 수는 없습니다. 이것이 테스트를 할 만한 가치가 없다는 뜻은 아닙니다.”
일반적인 모더레이팅 편향을 극복할 수 있도록 도와주는 자원과 그것을 피하는 간단한 전략은 많이 있습니다. Sauro는 사용자 테스팅에서 가장 흔한 편향 9가지를 전하며, UX Agony Aunt는 테스트 질문에서 그런 편향을 피하는 걸 도와주는 카피라이팅 팁을 강조합니다. 요점은 모든 테스트가 흠이 있다고 해서 포기하면 안 된다는 것입니다. 잠깐 동안만 완벽주의 성향을 던져버리고 객관성을 높일 수 있는 방법에 집중하세요.
이의제기 #4. 통계적 유의도에 도달할 수 있을 만큼 충분한 유저에게 절대 테스트할 수 없을 것이다.
우리가 사용성 이슈를 이해하기 위해서 수백 명의 유저를 테스트해야 한다는 생각은 근거 없는 믿음입니다. 유저 테스팅과 시장조사를 비교하다 보니 나온 말인데, 시장 조사는 선호도와 팩트를 찾아내기 때문에 지배적인 패턴을 찾아내기 위해 엄청 많은 사람들과 얘기할 필요가 있습니다. 하지만, 유저 테스팅은 사용성 문제를 발견하기 위한 것입니다.
Nielsen Norman group은 실제 우리가 사용성 문제를 찾아내기 위해서는 5명 이상을 테스트할 필요가 없다는 점을 발견했습니다. 이쯤 되면, 주요 디자인 문제가 반복적으로 나타나기 시작하는 것이죠.
만일 3명의 유저에게 테스트한다면, 즉시 가장 주요한 문제를 찾을 수 있을 것입니다. 만일 5명이나 그 이상 한다면, 주요 문제가 반복될 것이고 새롭게 배우는 것을 아무것도 없을 것입니다.
Photo source: Children’sMinistry병 속에 들어가 있는 돌멩이와 자갈돌과 모래 이야기를 생각해보세요. 만일 여러분이 모래를 먼저 넣는 다면 돌은 들어갈 자리가 없을 것입니다. 하지만 돌을 먼저 넣으면, 모래가 들어갈 자리가 많이 남을 것입니다. 이는 테스팅 우선순위에도 적용할 수 있습니다. 유저 테스팅은 돌 넘어가는데 장애물이 되는 것, 누락된 정보, 이해할 수 없는 양식을 뜻하며, 유저가 그 웹사이트나 제품을 이용할 때 마주칠 수 있는 가장 큰 문제들입니다. 조약돌과 모래는 제품이 출시된 후에 수행할 문구 개선, FAQ 글, AB테스트입니다. 그런 것들은 나중에 조정할 시간이 있습니다만, 사용성 테스팅은 돌멩이, 그러니까 당장 손을 봐야 하는 부분을 밝혀내는 것이죠.
이의제기 #5. 유저는 전문가가 아니다. 왜 그들의 의견이 필요한가?
이건 제가 가장 좋아하는 이의제기입니다. 저는 수백만의 성격, 선호, 패턴을 제 스스로에게 흡수하려고 관리를 해왔고, 웹사이트나 제품을 그 모든 렌즈를 통해 바라볼 수 있습니다. 많은 리서치 경험이 있고, 스스로도 많은 테스트를 해보았습니다. 하지만 이 모든 것이 제게 가르쳐 준 것은 어떤 유저 테스트도 완전히 같은 테스트는 없다는 것입니다.
자, 잠깐 확실하게 해두고 넘어갑시다. 유저 테스팅은 본질적으로 편향되어 있습니다. 이것은 한 명의 감정적이고 예측 불가능한 인간이 다른 감정적이고 예측 불가능한 인간에게 의견을 묻는 것입니다. 하지만 우린 이 인간성을 이용할 수 있습니다. 우리의 목표는 유저 편향을 밝혀내는 것이며, 감정적이고 예측 불가능한 인간 양상을 설명해야 하는 분을 찾아내는 것입니다.
더욱이, 유저가 디자인을 다루는 것을 관찰함으로, 파묻혔거나 숨겨진 콘텐츠, 극복할 수 없는 장애물을 찾기 위해 만들어간 지름길을 배울 수 있을 뿐만 아니라 목표, 페인 포인트, 누락 정보에 대해서도 알아낼 수 있습니다. 우리는 전문가로부터 조언을 받고 싶지 않습니다. 코드나 디자인에 대해선 아무것도 모르지만 웹사이트를 매일 사용해야만 하는 사람들에게서 조언을 받고 싶은 것이죠.
제품이나 웹사이트를 제작하는 것과 밀접하게 일하다 보면, 제가 소위 말하는 “website blindness”을 만들게 되는 경향이 있습니다. 백엔드 기능성, 디테일, 다른 누구보다 길을 잘 찾게 해줄 레이아웃에 너무 몰입하게 되는 거죠. 여러분의 집에 대해 생각해보세요.
몇 년 동안 한 집에 살다 보면, 어둠 속에서도 발을 찧거나 불을 켜지 않고도 돌아다닐 수 있게 됩니다. 여러분의 웹사이트도 마치 집과 같습니다. 여러분은 어떻게 작동하는 것인지 어떻게 찾아가면 되는지 너무 잘 아는데, 여러분의 유저는 완전한 어둠 속에 있는 것이죠. 유저 테스팅은 사람들이 어디서 발가락을 찧는지, 어디에 전기 스위치를 둬야 하는지 알려줄 것입니다.
이의제기 #6. 시장 조사나 경쟁사 분석을 그냥 쓰면 안 되는 이유가 무엇인가?
앞서 언급했듯이, 유저 테스팅은 시장조사와 다릅니다. 시장조사는 소비자가 해당 브랜드나 제품에 대해 어떻게 느끼는지 측정하는 것이 가장 큰 부분을 차지합니다. 때문에 여러분이 일 년에 한 번씩 쇼핑 습관에 대한 서베이 메일을 받는 것처럼, 엄청난 표본 집단이 필요한 것이죠. 유저 리서치는 시장 조사와 결합될 수는 있지만, 완전히 다른 목표를 가지고 있습니다. 유저 리서치는 행동을 봅니다. 포커스 그룹, 이메일 서베이, 폰 퀴즈 이 모든 것들은 유저에게 무엇을 원하는지(이의제기 #4를 보세요) 물어보지만 유저 리서치는 실시간으로 그들이 어떻게 행동하는지 관찰하고 그 정보를 기반으로 의사결정을 내립니다.
대부분 사람들이 알고 있는 사례가 바로 애플입니다. 애플은 마켓 리서치를 사용하지 않는 것으로 유명합니다. 잡스도 물론이고요. 하지만 이것이 아이폰이 어느 날 갑자기 한 번에 훌륭한 제품이 되었다는 의미는 아닙니다. 애플은 유저에게 무엇을 원하는지 묻지 않기로 했지만, 유저에게 제품 디자인을 주고 어떻게 그 디자인을 이용하는지 관찰합니다.
이동식 컴퓨터의 사이즈와 무게를 모의시험하기 위해 피자 상자에 돌을 넣어 포장하고, 유저를 따라다니며 “컴퓨터”를 어떻게 이용하는지 관찰한 것은 이미 유명한 전설입니다. 프로토타입과 관찰 결과는 그들이 더 다루기 쉬운 사이즈의 제품을 개발할 수 있게 해 준 것이죠.
이걸 생각해보세요. 디자인 경험이나 기술적 가능성에 대한 이해가 없는 유저가 “스마트폰은 무엇을 할 줄 알아야 할까?”에 대한 질문에 도대체 뭐라고 답할 수 있겠습니까? 그 기기가 무엇을 해줬으면 좋겠는지에 대해 추측할 수 있는 능력조차 가지고 있지 않습니다. 하지만 75가지 기능이 있는 기기를 주고 그들이 어떤 태스크를 수행하는지, 어떤 앱은 절대 안 쓰는지 관찰했었다면, 기술에 대한 유저의 진정한 의도를 더 잘 이해할 수 있을 것입니다.
경쟁사도 리서치하세요. 그리고 준비가 되면, 여러분도 똑같이 훌륭하거나 특별히 더 나은 제품을 만들었다는 생각이 들면, 유저가 두 제품 모두를 테스트하는 것을 관찰해보세요.
