실험실 없이 하는 사용성 테스트: 초보자를 위한 가이드

FabricLoop 팀 작성  ·  2026년 5월  ·  4분 읽기

사용성 테스트는 비용이 많이 들고 느리다는 부당한 평판을 갖고 있습니다. "사용자 리서치"라고 하면 사람들은 매직미러, 클립보드를 든 진행자, 2주짜리 일정을 떠올립니다. 그런 방식의 테스트도 존재하고 나름의 쓰임이 있지만, 대부분의 제품 팀이 대부분의 경우에 필요로 하는 방식은 아닙니다.

대부분의 팀에 필요한 방식은 더 단순합니다. 사용자 5명, Figma 프로토타입이나 스테이징 환경, 화상 통화, 세션당 45분이면 됩니다. 제대로 하면 출시 전에 심각한 사용성 문제 대부분을 찾아낼 수 있습니다. 스프린트당 한 번이라도 꾸준히 하면 출시 후 분석으로는 얻을 수 없는, 제품 품질의 복리 같은 개선 효과가 생깁니다.

처음부터 진행하는 방법은 다음과 같습니다.

4단계로 진행하는 테스트 세션

1단계 모집: 몇 명을 테스트하느냐보다 누구를 테스트하느냐가 더 중요합니다

참가자 5명은 대부분의 사용성 테스트에 적절한 숫자입니다. Jakob Nielsen의 연구는 사용자 5명이 사용성 문제의 약 85%를 발견하며, 그 이후에는 얻는 효과가 줄어든다는 것을 밝혀냈습니다. 디자인 과정의 서로 다른 시점에서 5명씩 세 번 테스트하는 것이 15명을 한 번 테스트하는 것보다 더 가치 있습니다.

모집 기준은 인원수보다 더 중요합니다. 대상 사용자와 매우 비슷한 5명으로 하는 사용성 테스트는 실제 문제를 드러냅니다. 대상 사용자와 맞지 않는 15명으로 하는 테스트는 잡음만 만들어 냅니다. 역할, 사용 맥락, 기술 숙련도처럼 선별 기준을 2~3개 정하고 끝까지 지키세요.

대부분의 팀에 가장 빠른 모집 방법은 연락을 받는 데 동의한 기존 사용자에게 이메일을 보내는 것입니다. 약간의 사례를 제시하세요. 45분 세션에는 20파운드 상당의 기프트 카드면 충분합니다. 모집과 테스트 사이의 간격이 길수록 불참률이 높아지므로, 같은 주 안에 세션 일정을 잡는 것을 목표로 하세요.

2단계 스크립트: 지시문이 아니라 시나리오

스크립트를 쓸 때 가장 흔한 실수는 과업을 지시문으로 쓰는 것입니다. "설정을 클릭한 다음 알림으로 이동해서 환경설정을 ...로 바꾸세요." 이렇게 하면 사용자에게 무엇을 해야 하는지 알려 주는 셈이므로, 인터페이스가 직관적인지가 아니라 안내를 잘 따라 하는지를 테스트하게 됩니다.

대신 과업을 시나리오로 쓰세요. "알림이 너무 많이 와서 누군가 나를 직접 언급할 때만 알림을 받고 싶다고 상상해 보세요. 어떻게 하실지 보여 주세요." 이렇게 하면 사용자에게 현실적인 목표가 생기고, 헷갈리는 지점을 포함해 실제로 어떻게 탐색하는지 관찰할 수 있습니다.

3단계 진행: 여러분의 역할은 지켜보는 것이지 돕는 것이 아닙니다

사용성 테스트를 진행할 때 가장 어려운 점은 돕고 싶은 충동을 참는 것입니다. 사용자가 헤매면 본능적으로 끼어들어 어디를 눌러야 하는지 알려 주고 싶어집니다. 하지만 헤매는 모습 자체가 데이터입니다. 어려워하는 사용자는 인터페이스에 문제가 있다고 알려 주고 있는 것이며, 개입하는 순간 그 신호를 잃게 됩니다.

세션 내내 사용자에게 생각을 소리 내어 말해 달라고 요청하세요. "진행하면서 무엇을 보고 있고 어떤 생각을 하는지 말씀해 주세요." 이렇게 하면 사용자의 멘탈 모델에 대한 데이터가 끊김 없이 쌓입니다. 오류뿐 아니라 망설임도 기록하세요. 올바른 버튼을 누르기 전에 3초간 멈춘 사용자는 결국 성공했더라도 디자인 문제를 드러낸 것입니다.

4단계 종합: 발언이 아니라 패턴

종합 단계는 대부분의 가치가 만들어지는 곳이면서, 대부분의 팀이 대충 넘어가는 곳이기도 합니다. 5개 세션의 원본 메모는 아직 발견 사항이 아닙니다. 팀이 함께 디브리핑하고, 관찰 내용을 주제별로 묶고, 심각도 등급을 매겨야 비로소 발견 사항이 됩니다.

관찰 내용이 생생할 때 세션과 같은 날 디브리핑을 하세요. 문제를 세 가지로 분류합니다. 치명적(사용자가 과업을 완료하지 못함), 보통(사용자가 과업은 완료했지만 상당한 어려움이나 오류가 있었음), 경미(완료를 막지는 않았지만 불편을 준 것). 치명적인 문제는 출시 전에 수정해야 합니다. 보통 수준의 문제는 다음 스프린트에서 우선순위를 정해 처리합니다. 경미한 문제는 백로그에 넣습니다.

발견 사항은 한 페이지로 정리하세요. 가장 심각한 문제 세 가지와 각각 최소 두 명의 참가자에게서 나온 근거, 각 문제에 대한 디자인 변경 제안을 담습니다. 이보다 더 많은 분량이 필요한 내용은 별도 문서에 담으세요.