사용자 테스트

이번 주 읽기: 상담 도구는 일반 앱과 다르게 테스트해야 한다

카카오톡이나 배달 앱에서 버튼이 안 눌리면 짜증이 난다. 하지만 상담 앱에서 위기 상황의 내담자(상담을 받는 사람)가 “도움 요청” 버튼을 못 찾으면? 그건 짜증이 아니라 안전 문제다.Gainer(2025)는 이걸 “불편(inconvenience)”과 “위해(harm)”의 차이라고 부른다. 일반 앱의 실패는 불편을 주지만, 상담 앱의 실패는 사람에게 해를 끼칠 수 있다.

이 차이를 구체적으로 생각해보자. 배달 앱에서 주문 버튼이 안 되면 다른 앱을 깐다. 피자를 못 먹는 건 아쉽지만 생명에 지장은 없다. 하지만 우울증으로 한 달째 집 밖에 나가지 못하던 사람이 겨우 용기를 내서 상담 앱을 열었는데, 시작 버튼을 못 찾거나 로딩이 끝나지 않으면? 그 사람은 “역시 나한테는 아무것도 안 되는구나”라고 느낄 수 있다. 기술적 실패가 심리적 상처로 변환되는 순간이다.

그래서 Gainer는 “공감적 사용성(empathic usability)”이라는 개념을 제안한다. 보통 사용성(usability, 쓰기 쉬운 정도)은 “과업을 얼마나 빨리 끝냈는가”, “실수가 몇 번 있었는가”로 측정한다. 하지만 상담 도구에서는 세 가지를 더 봐야 한다. 첫째, 사용자가 자기 감정을 솔직하게 드러내도 안전하다고 느끼는지(정서적 안전감). 둘째, 사용 과정에서 존중받는 느낌이 드는지(존엄성 보존). 셋째, 대화가 뚝뚝 끊기지 않고 일관된 경험을 제공하는지(치료적 연속성)다.

정서적 안전감을 예로 들어보자. 사용자가 “요즘 너무 외로워요”라고 입력했는데, 챗봇이 갑자기 “운동을 해보세요!”라고 밝게 답하면 어떨까? 사용자는 “내 마음을 무시당했다”고 느낀다. 존엄성 보존의 예는 자가 검사 결과 화면이다. “당신은 중증 우울증입니다” 같은 직접적 진단 표현 대신, “현재 심리적으로 어려운 시기를 보내고 계신 것 같습니다. 전문 상담사와 이야기해 보시면 도움이 될 수 있습니다” 처럼 사용자의 자존감을 지키는 표현을 써야 한다.

세네카 R. 게이너

사용성 테스트에서 가장 중요한 발견은 사용자가 무엇을 하지 못했는가가 아니라, 무엇을 느꼈는가이다. 상담 도구에서 좌절감은 이탈로 이어지고, 이탈은 치료 중단을 의미한다.

— Gainer (2025, p. 203)

치료적 연속성의 예를 하나 더 들어보자. 사용자가 AI 챗봇과 “어머니와의 관계”에 대해 대화하고 있었는데, 앱을 껐다가 다시 열었을 때 이전 대화가 전혀 기억되지 않으면 어떨까? 상담에서 매번 처음부터 다시 이야기해야 한다면 내담자는 “이 사람은 내 이야기에 관심이 없구나”라고 느낀다. AI 챗봇도 마찬가지다. 이전 대화의 맥락을 유지하는 것이 치료적 연속성이고, 이것은 기술적으로 대화 기록 저장과 컨텍스트(context, 맥락 정보) 관리를 통해 구현된다.

5명이면 충분하다: Nielsen의 사용성 원칙

사용성(usability)이라는 분야를 만든 사람이Jakob Nielsen이다. Nielsen(1994)은 사용성을 다섯 가지로 나눴다. 배우기 쉬운가(학습용이성), 빠르게 쓸 수 있는가(효율성), 다음에 다시 와도 기억나는가(기억용이성), 실수가 적은가(오류), 쓰면서 기분이 좋은가(만족도). 이 다섯 기준은 30년이 지난 지금도 표준이다.

Nielsen이 이 다섯 가지를 정한 배경에는 수백 건의 사용성 테스트 관찰이 있었다. 그는 사용자들이 소프트웨어를 사용하는 모습을 관찰하면서, 문제가 반복적으로 발생하는 패턴을 발견했다. 사용자들은 매뉴얼을 읽지 않고, 첫인상으로 판단하며, 한두 번 실패하면 떠난다. 이런 관찰에서 나온 원칙들이기 때문에 이론이 아니라 경험적 사실에 가깝다. Nielsen은 또한 “휴리스틱 평가(heuristic evaluation, 전문가가 원칙에 따라 인터페이스를 점검하는 방법)”라는 기법도 만들었다. 10가지 원칙 (가시성, 일관성, 오류 방지 등)에 따라 전문가가 인터페이스를 체계적으로 검토하는 방법이다.

제이콥 닐슨

5명의 사용자만 테스트해도 전체 사용성 문제의 85%를 발견할 수 있다. 완벽한 테스트보다 빈번한 소규모 테스트가 훨씬 효과적이다.

— Nielsen (1994)

이 원칙이 우리 프로젝트에 딱 맞는 이유가 있다. 대규모 사용자 조사가 아니라, 동료 5명에게 테스트를 부탁하는 것만으로도 핵심 문제 대부분을 찾을 수 있다는 뜻이기 때문이다. Nielsen의 연구에 따르면 테스트 인원이 늘어날수록 새로 발견되는 문제는 급격히 줄어든다. 첫 번째 테스터가 전체 문제의 31%를 찾고, 다섯 번째 테스터까지 합치면 85%에 도달한다. 15명을 테스트해야 100%에 가까워지지만, 5명과 15명 사이의 차이는 투자 대비 효과가 크게 떨어진다.

다만 상담 도구에 적용할 때는 기준을 좀 바꿔야 한다. “효율성”은 단순히 클릭 수가 아니라, 위기 상황에서 도움까지 도달하는 시간이다. “오류”는 입력 실수가 아니라, 위기 신호를 놓치는 것(미감지)이나 괜찮은데 위기로 판단하는 것(과잉 감지)이다. “만족도”는 편리함이 아니라, 대화 후 “이해받았다”고 느끼는 정도다.

상담 도구의 사용성 테스트에서 특별히 신경 써야 할 것이 하나 더 있다. 바로 테스터의 심리적 안전이다. 위기 시나리오를 테스트한다는 건, 테스터가 “죽고 싶다” 같은 입력을 해봐야 한다는 뜻이다. 이런 시나리오는 테스터에게도 심리적 영향을 줄 수 있다. 테스트 전에 시나리오의 성격을 미리 알려주고, 불편하면 언제든 중단할 수 있음을 고지해야 한다. 이것은 연구 윤리에서의 “사전 동의(informed consent)”와 같은 원리다.

“생각하게 만들지 마라”: Krug의 설계 원칙

Steve Krug(2014)는 “Don't Make Me Think(생각하게 만들지 마라)”라는 유명한 책을 썼다. 핵심은 간단하다 -- 좋은 웹사이트는 사용자가 “이 버튼을 눌러도 되나?”, “다음에 뭘 해야 하지?”라고 고민하는 순간이 없어야 한다는 것이다. Krug에 따르면 사용자는 웹페이지를 “읽지 않고 훑어본다(scan)”. 제목과 굵은 글씨만 보고, 클릭할 곳을 직감적으로 찾는다. 그래서 버튼은 버튼처럼 보여야 하고, 링크는 링크처럼 보여야 한다. “여기를 눌러야 하나?”라는 의문이 드는 순간, 이미 설계가 실패한 것이다.

스티브 크루그

사용자는 사이트에 처음 올 때 일정량의 인내심을 갖고 온다. 혼란스러운 경험이 쌓이면 이 인내심이 바닥나고, 사용자는 떠난다.

— Krug (2014)

이걸 상담 도구에 적용하면 더 심각해진다. 불안이나 우울을 겪는 내담자는 이미 집중력이 떨어지고, 결정하기가 어려운 상태다. 이런 사람에게 복잡한 회원가입, 헷갈리는 메뉴, 작은 글씨의 긴 안내문을 보여주면? 치료 이전에 사용자를 잃어버리는 것이다. 연구에 따르면 정신건강 앱의 평균 이탈률은 일반 앱보다 높다. 다운로드 후 한 번만 쓰고 삭제하는 비율이 70%가 넘는다. 이유 중 하나가 바로 복잡한 초기 설정과 어려운 인터페이스다.

Gainer(2025)는 Krug의 사용자 중심 설계와 Rogers의 내담자 중심 접근을 결합해서 “내담자 중심 UX”라는 개념을 만들었다. 모든 설계 결정을 “이게 내담자의 치료 여정을 돕는가, 방해하는가?”라는 질문으로 판단하자는 것이다. Rogers가 상담실에서 “내담자가 편안하게 자기를 탐색할 수 있는 환경을 만들어야 한다”고 했듯, 디지털 상담 도구에서도 사용자가 편안하게 자기 감정을 표현할 수 있는 인터페이스를 만들어야 한다.

내담자 중심 UX의 구체적 원칙을 정리하면 네 가지다. 첫째, “첫 화면에서 가치를 보여줘라” — 복잡한 가입 절차 전에 도구가 무엇을 해줄 수 있는지 먼저 보여준다. 둘째, “판단하지 마라” — 자가 검사 결과를 “심각합니다”가 아니라 “전문가와 상담해 보시면 도움이 됩니다”로 표현한다. 셋째, “탈출구를 항상 열어둬라” — 어떤 화면에서든 위기 자원에 접근할 수 있어야 한다. 넷째, “리듬을 만들어라” — 질문과 응답, 활동과 휴식이 자연스럽게 교대하는 대화 흐름을 설계한다.

칼 로저스

내담자가 자유롭게 자기를 표현할 수 있는 환경을 만드는 것이 치료의 시작이다. 심리적 안전이 탐색과 성장의 전제 조건이다.

— Rogers (1961)

이번 주에 동료의 플랫폼을 직접 테스트하면서, 이 읽기에서 배운 원칙들이 실제로 어떻게 적용되는지 체험하게 된다. 이론으로 읽을 때와 직접 겪을 때의 차이는 크다. “생각하게 만들지 마라”라는 원칙을 읽으면 고개를 끄덕이지만, 실제로 남의 앱에서 “이게 뭐지?”라고 멈추는 순간을 경험하면 그 원칙이 피부로 와닿는다. 동시에 누군가가 내 앱 앞에서 헤매는 모습을 보면, “이렇게 당연한 걸 왜 못 찾지?”라는 생각 대신 “내가 당연하다고 여긴 것이 실은 당연하지 않았구나”라는 깨달음을 얻게 된다.

Think-aloud: 사용자의 머릿속을 들여다보는 방법

Jakob Nielsen이 체계화한 Think-aloud Protocol(사고 구술법, 생각을 소리 내어 말하는 방법)은 사용성 테스트의 기본이다. 방법은 간단하다. 테스터에게 과업을 주고, “지금 무슨 생각이 드는지 말해주세요”라고 요청한다. 테스터는 화면을 보면서 머릿속에 떠오르는 생각, 혼란, 기대, 판단을 모두 소리 내어 말한다. 관찰자는 이 과정을 기록한다.

이 방법이 강력한 이유는 사용자의 “내면 경험”을 실시간으로 포착할 수 있기 때문이다. 설문조사를 하면 사용자는 기억에 의존해서 답하고, 실제로 겪은 혼란의 절반은 잊어버린다. 하지만 Think-aloud에서는 혼란이 일어나는 바로 그 순간에 “이게 뭐지?”라는 말이 나온다. 이 한마디가 설계의 약점을 정확히 가리킨다.

예를 들어 테스터가 상담 플랫폼에 처음 들어오면 이런 식으로 말한다. “음, 메인 화면인데 어디서부터 시작해야 할지 모르겠다”, “이 아이콘이 채팅인지 전화인지 구분이 안 된다”, “아, 여기를 누르니까 자가 검사가 나오는구나”. 관찰자는 이걸 기록하되, 절대 개입하지 않는다. “거기를 클릭해 보세요” 같은 유도는 금물이다. 왜냐하면 개입하는 순간, 테스터는 자기 판단이 아니라 관찰자의 지시를 따르게 되고, 실제 사용 경험과 달라지기 때문이다.

제이콥 닐슨

사용성 테스트에서 관찰자의 가장 어려운 역할은 침묵을 유지하는 것이다. 테스터가 잘못된 경로를 따라가는 걸 보면서 개입 충동을 억제해야 한다.

— Nielsen (1994)

이 침묵의 원칙은 상담사에게 친숙한 개념이다. 상담에서도 내담자가 스스로 해답을 찾도록 기다리는 것이 핵심이다. 내담자가 침묵하면 상담사는 그 침묵을 채우고 싶은 충동을 느끼지만, 참고 기다려야 내담자의 진짜 생각이 나온다. Think-aloud 테스트의 관찰자 역할과 상담사의 경청 자세는 근본적으로 같은 태도다 — “내가 이끌지 않고, 상대방이 자연스럽게 드러내도록 기다린다”. 상담 훈련을 받은 학생이라면 이 태도가 이미 몸에 배어 있을 것이다. 그래서 상담 전공자는 사용성 테스트의 관찰자로서 독특한 강점을 가진다.

Think-aloud에는 두 가지 방식이 있다. 동시적 방식은 과업을 하면서 동시에 생각을 말하는 것이다. 실시간으로 사용자의 생각을 포착할 수 있지만, 말하느라 과업 자체가 방해받을 수 있다.회고적 방식은 과업을 먼저 끝낸 다음 녹화 영상을 보면서 “이때 이런 생각이었어요”라고 되돌아보는 것이다. 상담 도구 테스트에서는 보통 동시적 방식을 쓰지만, 자살 위기 같은 민감한 시나리오에서는 회고적 방식을 쓴다. 위기 시나리오에 몰입하면서 동시에 생각을 구술하면 인지적 부담이 너무 크기 때문이다. 테스터의 심리적 안전도 테스트 설계에서 고려해야 할 요소다.

시나리오 기반 테스트: 현실적인 상황 만들기

좋은 사용성 테스트의 핵심은 현실적인 시나리오다. “이 버튼을 클릭하세요”가 아니라, 사용자의 배경과 심리 상태까지 포함해야 한다. 시나리오에 맥락을 넣는 이유는 같은 기능이라도 사용자의 심리 상태에 따라 전혀 다르게 경험되기 때문이다. 차분한 상태에서 자가 검사를 받는 것과, 불안 발작 직후에 급하게 도움을 찾는 것은 완전히 다른 경험이다.

예시를 보자. 시나리오 A: “당신은 취업 준비 때문에 2주째 잠을 못 자고 있는 대학생입니다. 친구가 이 앱을 추천해서 처음 접속했습니다. 자가 검사를 받아보세요.” 시나리오 B: “당신은 최근 이별 후 우울감이 지속되는 직장인입니다. AI 챗봇과 대화를 시작해 보세요.” 시나리오 C: “당신의 친구가 자해 충동을 언급했습니다. 이 앱에서 위기 상담 연결 방법을 찾아보세요.”

각 시나리오에서 보는 것이 다르다. A에서는 자가 검사까지 얼마나 빨리 도달하는지, 질문이 이해하기 쉬운지, 결과 화면이 겁을 주지 않는지를 본다. B에서는 AI와의 대화에서 “이해받는 느낌”이 드는지, 대화가 자연스럽게 흘러가는지, 갑자기 맥락 없는 질문을 하지 않는지를 본다. C에서는 위기 자원(자살예방 상담전화 등)까지 몇 번 클릭으로 도달하는지를 본다.Krug(2014)의 “3번 클릭 규칙”에 따르면, 원하는 정보까지 3번 클릭 이내에 도달해야 한다. 위기 상담 도구에서 이 규칙은 생명과 직결된다.

세네카 R. 게이너

상담 도구의 사용성 테스트에서 가장 중요한 시나리오는 위기 상황이다. 평소 잘 작동하는 도구도 위기의 순간에 실패하면 그 도구의 가치는 0이 된다.

— Gainer (2025, p. 208)

시나리오를 만들 때 주의할 점이 있다. 시나리오가 너무 구체적이면 테스터가 역할극을 하는 느낌이 들어서 자연스러운 반응을 못 보여주고, 너무 모호하면 뭘 해야 하는지 몰라서 헤맨다. 적절한 수준은 “상황과 동기를 제시하되, 구체적 행동은 지시하지 않는 것”이다. “자가 검사 버튼을 클릭하세요”가 아니라 “당신의 마음 상태를 확인해 보세요”라고 유도하면, 사용자가 자연스럽게 그 기능을 찾아가는 과정을 관찰할 수 있다.

교차 테스트: 남의 눈으로 내 작품 보기

자기가 만든 앱을 자기가 테스트하면 문제를 거의 못 찾는다. 이걸 “개발자 눈가림(developer blindness)”이라고 한다. 모든 기능의 위치를 이미 알고 있으니 길을 잃을 수가 없다. 자기가 만든 용어를 쓰니 헷갈릴 일도 없다. 상담에서 이런 현상을 “반전이(countertransference, 상담사가 자신의 감정을 내담자에게 투영하는 것)”와 비교할 수 있다. 개발자는 자기 의도를 제품에 투영해서, 사용자도 같은 방식으로 이해할 거라고 착각한다. 이 편향을 깨는 가장 좋은 방법이 교차 테스트다.

2인 1조로 서로의 플랫폼을 테스트한다. A가 B의 플랫폼을, B가 A의 플랫폼을 써본다. 테스터로서는 처음 보는 화면에서 겪는 혼란을 생생하게 경험하고, 개발자로서는 내가 “당연하다”고 생각한 것이 남에게는 전혀 당연하지 않다는 사실을 깨닫는다. 이 깨달음은 글로 읽어서는 절대 얻을 수 없고, 직접 누군가가 내 앱 앞에서 헤매는 모습을 봐야만 체감할 수 있다. 교차 테스트 후에는 서로의 발견을 공유하는 시간을 갖는다. “여기서 3번이나 뒤로 갔어요”, “이 버튼이 뭔지 몰라서 안 눌렀어요” 같은 피드백은 개발자에게 직접적인 개선 포인트를 준다.

스티브 크루그

모든 것은 사용자가 '이게 뭐지?' 하고 멈추는 순간에서 시작된다. 그 한마디에 설계의 실패 지점이 정확히 드러난다.

— Krug (2014)

피드백 정리: 뭘 먼저 고칠 것인가

테스트에서 받은 피드백은 두 가지 기준으로 분류한다.심각도(얼마나 큰 문제인가)와빈도(몇 명이 같은 문제를 겪었는가)다. 심각도는 세 단계다. Critical -- 핵심 기능이 아예 안 되거나 안전에 영향을 미침(예: 위기 자원을 못 찾음, 위기 감지가 작동하지 않음).Major -- 기능은 되지만 큰 혼란이 있음(예: 자가 검사 페이지에서 길을 잃음, AI 응답이 맥락을 벗어남). Minor -- 불편하지만 쓸 수는 있음(예: 글씨가 좀 작음, 색상이 약간 안 어울림).

이 분류 체계는 병원의 트리아지(triage, 환자의 긴급도에 따라 치료 우선순위를 정하는 것)와 비슷하다. 응급실에 환자가 여러 명 들어오면, 가장 위급한 환자부터 치료한다. 소프트웨어 문제도 마찬가지다. 모든 문제를 동시에 고칠 수 없으니, 가장 심각한 것부터 해결한다. 피드백을 받으면 감정적으로 방어적이 될 수 있다. 자기가 힘들게 만든 것을 비판받는 느낌이니까. 하지만 사용성 테스트의 피드백은 나를 비판하는 것이 아니라, 내 도구를 개선하기 위한 단서다. 상담사가 수퍼비전에서 피드백을 받을 때의 자세와 같다 — 열린 마음으로 듣고, 배울 점을 찾는다.

상담 도구에서는 예외가 하나 있다. 안전 관련 문제는 한 명만 겪었더라도 무조건 최우선이다. 실제 위기 상황에서 그 한 명이 도움을 못 받으면 치명적 결과로 이어질 수 있기 때문이다. 일반 앱에서 Critical 기준은 “매출에 영향을 미치는가”이지만, 상담 앱에서 Critical 기준은 “안전에 영향을 미치는가”이다. 이 차이를 항상 기억해야 한다.

앨런 쿠퍼

사용자 피드백의 가치는 피드백 자체에 있지 않다. 그 피드백을 바탕으로 실제로 제품을 개선했을 때 가치가 완성된다.

— Cooper (2014)

사용성 테스트의 핵심 규칙: Critical은 즉시 수정, Major는 우선 수정, Minor는 여유 있을 때 수정. 단, 안전 문제는 빈도와 무관하게 항상 최우선이다.

실습: 사용성 테스트 직접 해보기

사용성 테스트를 하려면 세 가지를 준비해야 한다. 첫째,테스트 계획서다. 무엇을 확인하려는지(목적), 누가 테스트하는지(대상), 어떤 과업을 수행하는지(시나리오), 무엇을 기록하는지(지표), 어떤 결과면 합격인지(기준)를 적는다. 상담 도구라면 여기에 “윤리적 안전장치 확인”이 반드시 들어가야 한다. 위기 상황에서 안전 자원으로 연결되는지, 개인정보가 보호되는지, AI의 한계가 솔직하게 고지되는지를 점검하는 것이다.

테스트 계획서를 쓸 때 가장 흔한 실수는 목적을 너무 넓게 잡는 것이다. “내 앱의 사용성을 확인한다”는 너무 막연하다. “처음 접속한 사용자가 자가 검사까지 3분 이내에 도달할 수 있는지 확인한다”처럼 구체적이어야 테스트 후 결과를 판단할 수 있다. 측정할 수 있는(measurable) 목표를 세우는 것이 핵심이다.

둘째, 테스트 도구를 준비한다. Maze(maze.co)는 원격 테스트 도구로, 테스터에게 링크를 보내면 과업 완료율, 소요 시간, 클릭 경로를 자동으로 모아준다. Hotjar(hotjar.com)는 히트맵(heatmap, 사용자가 어디를 많이 클릭하는지 색으로 보여주는 도구)과 세션 녹화를 제공한다. 둘 다 무료 플랜이 있어서 학기 프로젝트에 쓰기 좋다. 대면 테스트를 할 때는 Zoom 화면 공유 + 녹화로 충분하다. 녹화를 하면 테스트 중에 놓친 세부 사항을 나중에 다시 확인할 수 있어서 분석의 정확도가 올라간다.

스티브 크루그

완벽한 사용성 테스트를 한 번 하는 것보다, 간단한 테스트를 여러 번 하는 게 훨씬 낫다. 한 달에 한 번, 아침에 1시간이면 된다.

— Krug (2014)

셋째, 관찰자의 역할을 이해한다. 관찰자는 기록만 하고 절대 개입하지 않는다. 테스터가 헤매고 있어도 “거기가 아니에요”라고 말하면 안 된다. 테스터가 막혀서 도움을 요청할 때만 최소한의 힌트를 주되, 그 과업은 “실패”로 기록한다.Nielsen은 이 침묵이 관찰자의 가장 어려운 역할이라고 했다. 상담사가 내담자에게 성급하게 조언하지 않는 훈련과 비슷하다.

관찰 시 기록해야 할 것은 네 가지다. 행동(사용자가 무엇을 클릭했는가), 발화(무엇을 말했는가),감정(표정이나 목소리에서 느껴지는 감정이 무엇인가),시간(각 과업에 얼마나 걸렸는가). 특히 상담 도구 테스트에서는 “감정” 기록이 중요하다. 테스터가 AI 챗봇의 답변을 읽고 고개를 갸웃거리거나, 미간을 찌푸리거나, 웃는 순간을 포착하면, 그 반응이 UX 개선의 구체적 단서가 된다. 기록은 가급적 테스트 중에 실시간으로 한다. 테스트가 끝난 후에 기억에 의존해서 적으면 세부 사항을 놓칠 수 있다. 관찰 기록 양식을 미리 만들어두면 현장에서 빠르게 기록할 수 있다.

테스트 결과 정리하기

테스트가 끝나면 바로 결과를 정리해야 한다. 시간이 지나면 관찰의 세부 사항을 잊어버리기 때문이다. 상담에서 회기 직후에 상담 기록을 작성하는 것과 같은 원리다. 가능하면 테스트 후 30분 이내에 핵심 관찰 내용을 정리하는 것이 좋다.

관찰 내용은 어피니티 다이어그램(affinity diagram)으로 정리한다. 포스트잇(또는 FigJam, Miro 같은 디지털 도구)에 관찰 내용을 하나씩 적고, 비슷한 것끼리 그룹으로 묶는다. 예를 들어 “채팅 시작을 못 찾음”, “채팅 아이콘이 불분명함”, “채팅 기능이 있는 줄 몰랐음” 세 개는 “채팅 기능 발견 어려움”이라는 하나의 이슈로 묶인다.

어피니티 다이어그램은 상담에서의 주제 분석(thematic analysis)과 원리가 같다. 상담에서 여러 회기에 걸쳐 내담자가 반복적으로 언급하는 주제를 묶어서 핵심 이슈를 파악하듯, 사용성 테스트에서도 여러 테스터의 관찰을 묶어서 핵심 문제를 파악한다. 한 명이 말한 불편은 개인의 취향일 수 있지만, 세 명 이상이 같은 문제를 겪었다면 그건 설계의 문제다.

이렇게 정리한 이슈에 심각도(Critical / Major / Minor)와 빈도를 매기면 개선 우선순위가 나온다. 고친 뒤에는 반드시 재테스트를 한다. Critical 문제가 정말 해결됐는지, 고치면서 새로운 문제가 생기지 않았는지 확인한다. “테스트 → 분석 → 개선 → 재테스트” -- 이 사이클이 사용자 중심 설계의 핵심이다. 한 번의 사이클로 끝나는 것이 아니라, 계속 반복하면서 제품을 점진적으로 개선해나간다. 이것을 반복적 설계(iterative design, 반복을 통해 점점 나아지는 설계 방식)라고 부른다.

제이콥 닐슨

사용성 테스트의 목적은 '사용자가 얼마나 잘 못하는지'를 증명하는 게 아니다. 설계를 개선할 구체적 단서를 찾는 것이다.

— Nielsen (1994)

세네카 R. 게이너

상담 도구의 사용성 개선은 한 번의 이벤트가 아니라 지속적 과정이다. 내담자의 피드백은 가장 정직한 수퍼비전이다.

— Gainer (2025, p. 215)