[도서 정리] 사용자를 생각하게 하지마 - 적은 비용으로 사용성 평가하기, 여러 번 해도 부담 없는 간단한 사용성 평가 방법 |
-
"사용자를 생각하게 하지마” 라는 책의 핵심 내용 정리 내용입니다. 구체적 내용과 예시 등은 책을 구매해서 보세요~
-
포커스 그룹 테스트
5~10명 정도의 인원이 함께 둘러앉아서 특정 제품에 대한 대화를 나눈다.
대화 주제는 그 제품과 관련된 자신의 과거 경험이나 새로운 컨셉에 대한 의견이 주를 이룬다.
포커스 그룹 테스트는 물건에 대한 사용자의 감정이나 의견 표본을 빠르게 추출해야 할 때 유용하다.
사용성 평가
한 사람이 어떤 물건을 가지고 일반적인 과제를 수행하는 과정을 지켜보는 것.
대상은 웹 사이트, 제품 프로토타입, 새 다지안을 담은 스케치 등이 될 수 있다.
그 과정에서 사용자가 혼란스럽다거나 답답하다는 느낌이 드는 지점을 찾아서 고치는 것이 사용성 평가의 목표.
-
포커스 그룹은 사용자가 원하는 것, 필요로 하는 것, 좋아하는 것이 무엇인지 추상적으로 알아내고자 할 때 활용하기 좋은 방법이다.
사이트의 근간을 이루는 아이디어가 타당한지, 사이트가 제공하는 가치에 매력이 있는지 확인하기 좋다.
포커스 그룹은 여러분이 만든 사이트의 작동 여부나 개선 방법을 알려주지 못한다.
포커스 그룹을 통해 배우는 내용은 디자인이나 제작 이전에 알고 있어야 하는 사항이므로 프로젝트 기획 단계에서 수행해야 가장 유용한 결과를 얻는다.
반면 사용성 평가는 제작 프로세스 전반에 걸쳐 유용하게 사용된다.
-
사용성 평가에 대한 몇 가지 진실
훌륭한 사이트를 만들려면 반드시 평가해야 한다.
사이트 제작에 참여한 사람은 제작에 착수한 지 몇 주만 지나도 그 사이트를 새로운 관점으로 보지 못한다.
이미 너무 많은 것을 알고 있기 때문이다.
실제 잘 작동하는지 확인하는 유일한 방법은 다른 사람들이 사용하는 모습을 관찰하는 것이다.
평가를 해보면 사람들이 여러분과 다른 방식으로 사고한다는 사실을 깨닫게 된다.
여러분이 아는 내용을 누구나 알고 있지 않고 웹 사용방식도 모두 다르다.
평가 참가자가 한 명뿐이어도 좋다. 그렇게라도 평가를 하는 편이 아예 하지 않는 것보다 100% 낫다
평가는 항상 도움이 된다.
프로젝트 초기에 진행한 평가가 프로젝트 후반에 진행한 평가보다 낫다. 설사 초기 평가 대상자가 1명뿐이고 후기 평가 대상자가 50명이 된다고 하더라도 말이다.
프로젝트 초기에 평가를 진행하면 평가에서 배운 내용을 적용할 시간적 여유가 많다.
그러므로 초기의 간단한 평가가 프로젝트 후반의 복잡한 평가보다 더 가치 있는 경우가 많다.
웹에 올린 내용은 나중에 수정하기 쉽다는 것이 웹 개발에 대한 사회적 통념 중 하나다.
하지만 사용 중인 사이트 수정은 생각처럼 녹록지 않다.
특히 중요한 부분을 바꿀 때는 더욱 그렇다.
변화를 달가워하지 않는 사용자도 있기 마련이고, 단순한 변화가 거대한 나비효과를 일으키는 일도 있기 때문이다.
프로세스 초반에 바로 잡은 작은 실수가 나중에 발생할 문제를 줄여준다.
-
평가 주기
웹 개발팀이라면 한 달에 한 번 오전 시간을 들여서 하는 게 좋다.
오전 시간을 할애하면 사용자 3명을 대상으로 평가를 진행하고 점심시간에 브리핑할 수 있다.
그 정도면 충분하다.
브리핑을 마칠 즈음에는 다음 평가 진행 전에 고칠 부분을 결정한다.
왜 한 달에 한번, 오전 시간으로 하는가?
단순하므로 지키기 쉽다.
그 정도면 필요한 내용을 얻을 수 있다.
언제 평가할지 결정하는 수고를 덜어준다.
사람들의 참석률이 높아질 확률이 높다.
-
사용자는 몇 명이 필요한가?
DIY 평가 1회에 필요한 적정 참가자 수는 3명.
이러한 평가의 목적은 무언가 증명하는 게 아니다.
무언가 증명하려면 정량적인 평가가 필요하다.
DIY 평가는 정성적인 방법을 사용한다.
본인들이 만드는 것을 개선하기 위해 사용성 문제를 찾고 고치는 것이 평가의 목표다.
모든 문제를 찾을 필요는 없다.
사실 평가를 통해 모든 문제를 찾는 것은 불가능한 일이다.
한나절 동안 찾은 내용만으로도 한 달 작업량을 채우고 남는다.
따라서 우선순위를 정해서 문제에 집중하는 것이 매우 중요하다.
-
참가자는 어떻게 선택하는가?
여러분이 만든 사이트를 사용할 만한 사용자를 대상으로 평가를 진행했을 때 얻는 장점도 분명히 있다.
하지만 생각만큼 중요하지는 않다.
보통은 아무 사용자나 참가자로 모집해도 문제가 없다.
특히 평가를 시작한 초기라면 누구나 발견할 만한 사용성 결함이 많을 것이다.
-
참가자 모집에 너무 많은 에너지를 쏟지 말고 상대평가하라.
참가자 중 한 사람이 문제가 있다고 할 때 이렇게 자문해보라.
“실제 사용자도 경험하게 될 문제일까? 아니면 참가자가 우리 사용자라면 알 만한 사전 지식이 없어서 발생하는 문제일까?”
-
다음 세 가지 이유로 평가에 대상 사용자가 아닌 참가자가 포함되는 편이 더 좋다.
대상 사용자만 쓸 수 있는 사이트로 만들겠다는 건 그다지 좋은 생각이 아니다.
우리는 알고 보면 누구나 초보자다.
초보자도 알아보기 쉬운 수준으로 만들었다고 해서 전문가가 모욕감을 느끼지는 않는다.
-
참가자는 어떻게 찾는가?
평가 참가자를 모집할 장소나 방법은 많다.
사용자 그룹, 박람회, 크레이그리스트(Craiglist), 페이스북, 트위터, 사용자 포럼, 사이트 팝업을 활용하거나 친구나 지인들에게 부탁해도 된다.
-
1시간짜리 평가에 참여한 평균 웹 사용자에게는 통상 $50~$100 수준의 금액을 지급한다.
현행 시세보다 약간 더 높은 금액을 주는 걸 선호된다.
참가자가 내준 시간을 가치 있게 생각한다는 점을 명확히 전달하는 동시에 참석률도 높일 수 있는 방법이기 때문이다.
평가는 1시간 안에 끝난다고 해도 오고 가는 시간 때문에 참가자가 쓰는 시간은 이보다 많은 수밖에 없다는 사실을 기억하라.
-
평가는 어디에서?
평가 장소로는 방해 요소가 없고 탁자 혹은 책상 하나와 의자 두 개가 있는 조용한 장소가 적합하다.
흔히 사무실이나 회의실을 사용.
-
고투미팅(GoToMetting)이나 웹엑스(WebEx) 같은 화면 공유 소프트웨어를 사용하고,
테크스미스(Techsmith)의 캠타시아(Camtasia) 같은 화면 녹화 소프트웨어를 사용해서 화면이나 진행자, 참가자가 말하는 내용을 녹화하라.
-
누가 진행하는게 좋은가?
사용성 평가는 누구나 진행할 수 있다.
-
누가 관찰하는가?
최대한 많은 인원이 하면 좋다!
팀원, 이해관계자, 관리자, 경영진까지 최대한 많은 사람이 관찰에 참여하게 할 수 있는 일이라면 무엇이든 하라.
사실 평가에 할당된 자금에 여유가 있다면 맛있는 간식을 준비해서 사람들이 최대한 많이 오도록 유인하라고 권하고 싶다.
-
모든 관찰자는 평가를 마친 후 쉬는 시간마다 각자 자신이 발견한 가장 심각한 사용성 문제 세개를 적어두어야 한다.
이 때 메모한 내용은 브리핑 시간에 공유하라.
-
무엇을, 언제 평가하는가?
사용성 전문가들은 평가 시작 시점이 프로젝트 초반에 가까울수록 좋고, 평가 주기는 짧을수록 좋다고 입을 모아 이야기한다.
사실 평가를 하기에 너무 이른 시점은 없다.
심지어 사이트 디자인을 시작하기 전에도 여러분이 만들 사이트와 경쟁 관계에 있는 사이트를 평가해도 좋기 때문이다.
-
평가할 과제는 어떻게 선택하는가?
참가자에게 보여줄 내용이 많다면 우선 그 상태에서 사용자가 할 수 있는 일의 목록부터 만들라.
만약 로그인 프로세스 프로토타입을 평가하는 중이라면 다음과 같은 과제 목록이 완성된다.
계정 만들기
기존 ID 와 비밀번호로 로그인하기
비밀번호 찾기
ID 찾기
보안 질문 답변 바꾸기
-
평가 시간을 다 채울 수 있을 만큼 넉넉한 양의 과제를 준비하라.
1시간짜리 평가라면 과제로 35분 정도를 채우면 적당하다.
여러분의 예상보다 빠르게 작업을 완료하는 사람들도 있다는 사실을 염두에 두라.
-
참가자가 정확히 이해할 수 있도록 과제 설명은 단어를 신중하게 골라서 작성하라.
그리고 참가자에게 꼭 필요하지만, 그들이 준비할 수 없는 정보를 빠뜨리지 않도록 주의하라.
-
과제 세부사항 일부를 참가자 스스로 선택하게 했을 때 흥미로운 결과가 많이 도출되는 경향이 있다.
‘14달러 미만의 요리책을 찾으시오’ 라는 과제보다 ‘구매하고 싶은 책이나 최근에 구매한 책을 찾으시오’ 라고 하는 과제가 더 낫다는 이야기다.
-
평가 중에 어떤 일이 일어나는가?
평가에 사용하는 대본은 rocketsurgerymadeeasy.com 에서 다운가능하다.
인사 ( 4분 )
배경 질문 ( 2분 )
홈페이지 둘러보기 ( 3분 )
평가할 사이트의 홈페이지를 열어서 둘러보고 그 사이트에서 무엇을 할 수 있을 거라 생각하는지 참가자에게 물어보라.
과제 ( 35분 )
참가자가 과제에 집중하되 본인이 생각하는 내용을 소리 내어 말하게 해야 한다.
참가자가 본인의 생각을 말하지 않고 있을 때는 그들이 소리 내어 말하도록 유도하라.
참가자 스스로 과제를 수행하게 하는 것이 중요하다.
그들에게 영향을 줄 만한 말이나 행동을 하지 마라.
유도신문도 하지 말고 그들의 작업이 완벽히 막혔거나 극도의 답답함에 시달리고 있는 게 아니라면 힌트나 도움을 주어서도 안 된다.
참가자가 도움을 요청한다면 “제가 없었다면 어떻게 하셨을 것 같나요?” 같은 말로 답하라.
심층 질문 ( 5분 )
마무리 ( 5분 )
-
일반적으로 발생하는 문제들
사용자가 컨셉을 이해하지 못한다.
사용자가 찾는 단어가 거기에 없다.
너무 많은 애용이 들어 있다.
-
브리핑
평가를 마치고 난 후에는 팀원이 모여서 각자가 관찰한 내용을 공유하고 고칠 문제와 고칠 방법을 정할 자리를 가능한 한 빨리 만들어야 한다.
관찰자가 모든 내용을 아직 선명하게 기억할 때 말이다.
-
심각한 문제 하나를 수정할지 단순한 문제 여러 개를 수정할지 둘 중 하나를 골라야 하는 상황에서는 가장 중요한 문제를 먼저 고치는 데 가차 없이 집중하라.
-
목표를 완수하기 위한 방법은 아래와 같다.
공동 목록을 만들어라.
본인이 관찰한 문제 중 가장 심각한 것을 세 가지씩 말할 기회를 준다.
가장 심각한 문제 10가지를 고른다.
순위를 매겨라.
목록을 정돈하라.
다음 달에 쓸 수 있는 시간과 자원이 사용성 문제 수정에 전부 할당되고 있다는 느낌이 들기 전에 멈춰라.
매우 쉽게 고칠 수 있는 문제는 따로 목록을 만들어라.
매우 쉬운 문제인지는 브리핑에 참석하지 않은 사람의 허가를 받지 않아도 되는지, 한 사람이 한 시간 이하의 시간을 들여서 고칠 수 있는지 보면 알 수 있다.
새로운 문제를 더하려는 충동을 자제하라.
평가에서 사용자가 이해하지 못하는 내용이 있다는 사실을 알게 되면 설명이나 안내처럼 우언가를 일단 더하려고 한다.
하지만 무언가를 더해서 주의를 흩뜨리는 것보다 의미를 흐리고 있는 무언가를 뺐을 때 문제가 해결되는 경우가 많다.
‘새로운 기능’ 에 대한 요청은 가려서 들어라.
‘카약’ 문제를 무시하라.
참가자가 일시적으로 길을 잃었다가 아무 도움 없이 곧바로 정상궤도로 돌아오는 때가 있다.
카약을 탈 때 사용되는 롤링 오버 기술과 비슷한 것이다.
정상 상태로 빠르게 돌아올 수 있기만 하다면 사용자는 이런 과정을 즐거운 경험의 일부로 여긴다.
아래 조건을 만족하면 무시해도 되는 문제다.
(a) 문제를 경험한 모든 사람이 뭔가 잘못되었다는 사실을 빠르게 깨닫고
(b) 아무 도움 없어도 바로 회복했으며
(c) 당황하는 기색도 없었다면
-
대안적 평가 방식
원격 평가
진행자 없이 진행하는 원격 평가
-
웹 사이트 평가를 미룰 때 내세우는 그럴싸한 변명 TOP 5
시간이 없어요.
예산이 없어요.
전문 지식이 부족해요.
사용성 연구실이 없어요.
어차피 결과를 어떻게 반영해야 할지도 모를거에요.
댓글