스티브 크룩의 사용성 평가에 대해~

스티브 크룩의 "사용자를 생각하게 하지 마! (Don't Make Me Think)"에 보면 사용성 평가에 대한 이야기를 하고 있다. 

우리는 뭔가 고객 대상으로 평가를 하고 설문을 받아야 한다면 거창한 것을 생각하는데

스티브 크룩이 말하는 사용성 평가는 저렴한 비용으로 효과적으로 자주 수행할 수 있는 방법인 듯 하다. 

"Rocket Surgery Made Easy" 사이트에 보면 사용성 평가와 관련된 많은 내용을 확인할 수 있다. 

여기에서는 스티브 크룩의 핵심 내용만 정리해서 공유하도록 한다. 

웹 디자인 만평

먼저 누구나 공감할 만한 웹 디자인 만평을 살펴보자. 

"2주 후..."에도 동일한 논쟁을 하고 있는 것을 보면 남의 일 같지 않을 것이다. ^^

이런 상황을 스티브 크룩은 해답이 없는 "종교적 논쟁"이라고 표현한다. 

그리고 종교적 논쟁을 해결할 수 있는 방법은 "평가"하는 것이다. 

사용성 평가의 중요성

그래서 사용성 평가가 중요하다고 한다. 

물론 전문 업체에 의뢰해서 사용성 평가를 할 수 있지만

적은 비용으로 프로젝트 초기부터 자주 사용성 평가를 하는 것이 더 바람직하다고 이야기 하고 있다. 

사용성 평가 주기와 참가자 수

그럼.. 스티브 크룩이 직접 사용성 평가를 진행하는 방법을 정리해 보기로 한다. 

평가 주기는 한달에 한번 오전 시간이 좋다.

오전 시간에 하는 이유는 사용성 평가를 관찰할 팀원들의 참여율을 높일 수 있기 때문이다.

사용성 평가할 사용자의 수는 1회 평가시 3명 정도가 적절하다.

한번 평가에서 모든 문제를 찾을 필요가 없으며 3명 정도 테스트하면 수정해야 할 분량은 충분하다.

참가자 선정과 진행 방법

참가자는 해당 분야에 맞는 사람을 찾기보다는 일반인들과 같은 해당 분야의 초보자를 선정하는게 좋다. 

평가는 책상 하나, 의자 두 개가 있는 조용한 장소가 적합하다. 

팀원이나 이해관계자는 다른 방에서 사용자의 테스트를 지켜 보는 것이 좋다. 

이를 위해서 고투미팅(GoToMeeting)이나 웹엑스(WebEx)와 같은 화면 공유 소프트웨어로 화면을 함께 보고 

캠타시아(Camtasia)와 같은 화면 녹화 소프트웨어를 사용해서 녹화하는 것도 필요하다. 

사용자와 함께 할 진행자는 차분하고 다른 사람의 감정에 잘 공감하며 이야기를 들어주는 사람을 선택하면 된다. 

진행자는 참가자가 편안하게 본인의 임무에 집중하게 해야 할 뿐 아니라 

생각하고 있는 내용을 최대한 많이 소리내어 말하게 해야 한다. 

사용자 평가 구성

평가할 과제는 평가 당시 평가할 만한 내용이 얼마나 만들어졌는냐에 영향을 받는다. 

평가 시간을 1시간으로 설정했다면 과제는 35분 정도로 채우면 적당하다. 

1시간 평가는 일반적으로 다음과 같이 구성한다. 

• 인사(4분): 참가자가 진행 과정을 이해한 상태에서 평가에 임할 수 있도록 진행 방법을 설명한다.  
• 배경 질문(2분): 참가자에 대해 몇 가지 질문을 던진다. 참가자의 긴장을 풀어주는 동시에 그들의 컴퓨터나 웹 관련 지식 수준이 어느 정도인지 가늠하는 데 도움이 된다. 
• 홈페이지 둘러보기(3분): 평가할 사이트의 홈페이지를 열어서 둘러보고 그 사이트에서 무엇을 할 수 있을 거라 생각하는지 참가자에게 물어보라. 
• 과제(35분): 참가자가 일련의 과제를 수행하는 모습을 관찰하는 사용성 평가의 핵심이다. 
• 심층 질문(5분): 참가자에게 평가 중에 일어났던 일에 대해 묻거나 관찰실에 있던 이들이 묻고 싶었던 질문을 던질 수 있다. 
• 마무리(5분): 도와주어 고맙다는 인사를 하고 수고비를 지급한 후에 나가는 문을 안내한다. 

스티브 크룩은 사용성 평가를 진행할 때 미리 준비한 대본을 그대로 읽는다고 한다. 

이때 사용하는 대본은 "Rocket Surgery Made Easy"에서 받을 수 있다. 

test-script.pdf

평가 후 브리핑

사용성 평가 후 내부 회의를 통해 고칠 내용을 정하는 것도 중요하다.

너무 많은 문제를 해결하려고 하지 말고 가장 중요한 문제를 먼저 고치는 데 집중해야 한다. 

• 공동 목록을 만들어라
• 가장 심각한 문제 10가지를 고른다. 
• 순위를 매겨라
• 목록을 정돈하라
• 매우 쉽게 고칠 수 있는 문제는 따로 목록을 만들어라
• 새로운 문제를 더하려는 충동을 자제하라
• 새로운 기능에 대한 요청은 가려서 들어라
• 일시적으로 길을 잃었다가 아무 도움없이 정상 궤도로 돌아오는 경우는 문제가 아니다.

프로젝트를 진행하면서 완료된 이후에 나타나는 사용성 문제들을 예방하기 위해서 한번쯤 진행해 볼 만한 가치는 있는 것 같다.