적은 비용으로 사용성 평가하기

비싸게, 완벽하게, 가끔 하는 것보다 싸게, 대충, 자주 하는 게 훨씬 낫다. 크룩의 사용성 테스트 철학은 이 한 문장이야.

전통적인 사용성 테스트는 비싸잖아. 전문 시설, 전문 모더레이터, 대규모 참가자, 상세한 보고서. 한 번에 수천만 원이 들기도 하지. 그래서 대부분의 팀은 사용성 테스트를 **"해야 하지만 형편이 안 되는 것"**으로 분류해버려.

크룩은 이게 잘못됐다고 말해. 완벽한 테스트를 못 한다고 아예 안 하는 것보다, 아침에 한 시간짜리 간단한 테스트를 하는 게 백 배 낫거든.

크룩의 DIY 사용성 테스트 원칙:

• 참가자 3~4명이면 충분해. 대규모 테스트에서 나오는 인사이트의 80%는 첫 3명에게서 나온다는 게 크룩의 경험이야
• 특별한 시설이 필요 없어. 회의실 하나, 노트북 하나면 돼
• 전문가가 필요 없어. 기본적인 원칙만 알면 아무나 진행할 수 있어
• 일찍, 자주 해. 프로젝트 끝나고 한 번 하는 것보다, 개발 중에 여러 번 하는 게 나아

왜 3~4명이면 되냐면 — 큰 문제는 첫 번째 사용자에게서도 드러나고, 심각한 사용성 문제는 거의 모든 사용자에게서 나타나기 때문이야. 통계적으로 유의미한 데이터를 모으는 게 목적이 아니라, **"우리 사이트에서 사람들이 어디서 막히는지"**를 알아내는 게 목적이니까.

크룩의 DIY 테스트 기본 세팅:

• 장소: 조용한 회의실이면 충분
• 장비: 화면을 녹화할 수 있는 노트북. 팀원들이 다른 방에서 볼 수 있으면 더 좋아
• 역할: 진행자(facilitator) 한 명, 참가자 한 명. 나머지 팀원은 관찰
• 시간: 참가자당 한 시간이면 충분해. 하루에 3명 하면 오전에 끝나

진행 순서:

1. 참가자에게 사이트를 보여줘
2. 미리 준비한 과제를 수행하게 해
3. 참가자가 하는 말과 행동을 관찰해
4. 끝나면 짧은 디브리핑

핵심은 관찰이야. 참가자가 뭘 하는지, 어디서 멈추는지, 뭐라고 말하는지, 어떤 표정을 짓는지. 질문을 많이 하는 게 아니라 보는 것이 중요하지.

"우리 타겟 사용자를 정확히 대표하는 사람을 찾아야 해" — 이런 생각이 테스트를 미루게 만들어. 완벽한 참가자를 찾으려다 아무도 못 구하는 거야.

크룩의 입장: "거의 아무나 괜찮다."

왜냐면:

• 심각한 사용성 문제는 누구에게든 나타나거든. 타겟 사용자가 아니어도 "이 버튼이 안 보여요"는 발견할 수 있어
• 타겟 사용자만 잡으려다 테스트를 안 하는 것보다, 아무나라도 데려와서 테스트하는 게 백 배 나아
• 물론 타겟과 완전히 동떨어진 사람(예: 웹을 안 쓰는 어르신에게 개발자 도구를 테스트)은 피해야 하지만, 그 정도만 제외하면 대부분 괜찮아

참가자 보상은 소정의 사례비면 충분해. 사용성 테스트의 진입 장벽을 낮추는 게 크룩의 목표니까, "완벽한 참가자 + 높은 사례비"를 고집하면 취지에 어긋나지.

테스트 시작 전에 참가자에게 알려줘야 할 것들이 있어:

• "당신을 테스트하는 게 아니라, 사이트를 테스트하는 겁니다." 이 말 안 하면 참가자가 자기가 시험 받는 줄 알고 긴장하거든. 틀려도 괜찮다, 당신 잘못이 아니라 사이트 잘못이다
• "생각하는 걸 소리 내어 말해주세요." 사고 구술(think-aloud) 기법이야. 참가자가 뭘 보고 뭘 생각하는지 실시간으로 들을 수 있어
• "질문이 있어도 답을 안 드릴 수도 있습니다." 진행자가 힌트를 주면 테스트 의미가 없으니까

참가자에게 줄 과제를 미리 준비해. 과제는 두 종류야:

• "이 사이트가 뭐 하는 곳 같아요?" — 첫인상 평가. 홈페이지만 보고 대답하게 해
• 구체적 과제 — "이 사이트에서 30만 원짜리 호텔을 예약해보세요" 같은 실제 시나리오. 사용자가 실제로 하게 될 행동을 과제로 만들어야 해

진행할 때 주의할 점:

• 입을 다물어. 진행자의 가장 큰 실수는 너무 많이 말하는 거야. 참가자가 헤매면 도와주고 싶지만, 참아야 해
• 유도하지 마. "오른쪽 위에 있는 메뉴 보이세요?" 이런 건 힌트잖아. "어떻게 하시겠어요?"라고만 물어봐
• 왜 그렇게 했는지 물어봐. 참가자가 예상 밖의 행동을 하면 "왜 그걸 누르셨어요?"라고 물어봐. 여기서 인사이트가 나와

테스트가 끝나면 관찰한 팀원들과 모여서 디브리핑을 해.

크룩의 디브리핑 방법:

• 각자 관찰한 가장 심각한 문제 3개를 적어
• 전체가 모여서 공유해
• 공통적으로 나온 문제가 우선순위가 높은 문제야
• 당장 고칠 수 있는 것부터 고쳐

여기서 중요한 건 — 모든 문제를 다 고치려 하지 말라는 거야. 가장 심각한 것, 가장 쉽게 고칠 수 있는 것부터. 완벽함은 적이지.

크룩의 답: "한 달에 한 번, 아침에."

한 달에 한 번 아침에 3명 테스트하고, 그날 오후에 디브리핑하고, 그 주에 수정하고, 다음 달에 또 테스트. 이 사이클을 반복하면 사이트가 계속 나아져.

시작 시점은 "최대한 빨리." 완성된 사이트만 테스트할 수 있는 게 아니야. 와이어프레임도 테스트할 수 있고, 프로토타입도 테스트할 수 있거든. 빨리 시작할수록 문제를 빨리 발견하고, 수정 비용도 적어.

크룩이 거듭 강조하는 것: 완벽한 테스트를 기다리며 안 하는 것보다, 불완전한 테스트라도 지금 당장 하는 게 나아. 사용성 테스트는 거창한 게 아니야. 사람 한 명 데려와서 내 사이트를 쓰게 하고 관찰하는 것, 그게 전부야.

---

정리

9장 읽고 기억할 거:

1. 3~4명이면 충분해. 대규모 테스트가 아니어도 핵심 문제는 잡을 수 있어
2. 거의 아무나 괜찮아. 완벽한 참가자를 찾으려다 테스트를 안 하는 게 최악이지
3. 관찰이 핵심이야. 질문보다 보기, 도와주고 싶어도 참기, 왜 그렇게 했는지만 물어보기
4. 한 달에 한 번, 일찍 시작해. 완성을 기다리지 마. 와이어프레임도 테스트할 수 있어