개념
세션 하나의 구조
사용성 테스트(UT) 세션은 대개 45~75분이다. 이 시간이 어떻게 쪼개지는지 미리 정해 두지 않으면, 잡담으로 20분을 쓰고 과업은 두 개만 돌린 채 끝난다.
[60분 세션 표준 구성]
0~ 5분 환영·동의 목적 설명, 녹화 동의, "제품을 평가하지 당신을 평가하지 않습니다"
5~10분 워밍업 평소 사용 습관 2~3문항. 긴장 풀고 맥락 파악
10~15분 첫인상 화면 보여 주고 "이건 무슨 서비스 같으세요? 여기서 뭘 할 수 있을 것 같으세요?"
15~50분 과업 3~5개 핵심. 과업당 5~10분
50~57분 사후 질문 SUS(레슨 3), 가장 어려웠던 점, 다시 쓴다면
57~60분 마무리 사례 지급, 추가 연락 동의첫인상 5분을 건너뛰지 않는다. 과업을 주는 순간부터 사용자는 "찾아야 하는 사람"이 되어 화면을 다르게 본다. 과업 전에 자유롭게 보게 하면, 실제 첫 방문자가 무엇을 먼저 읽고 무엇을 무시하는지가 드러난다. 이 5분에서 나오는 발견이 전체의 상당 부분을 차지하는 경우가 흔하다.
과업 설계 — 시나리오지 지시가 아니다
가장 많이 망가지는 지점이다. 과업을 화면 조작 지시 로 쓰면, 사용자는 지시대로 누르고 아무것도 발견되지 않는다.
[나쁨 — 지시문]
"마이페이지 > 주문 내역에서 3번째 주문의 환불 버튼을 누르세요"
→ 경로를 이미 알려 줬다. 이 과업으로는 "환불 진입점을 못 찾는다"는
가장 중요한 문제를 절대 발견할 수 없다
[나쁨 — 화면 용어 사용]
"주문 상세 화면에서 반품 신청을 하세요"
→ '주문 상세', '반품 신청'이 화면의 레이블 그대로다. 사용자는 그 단어를
찾아 누른다. 용어가 이해되는지 검증할 기회가 사라진다
[좋음 — 상황 시나리오]
"지난주에 주문한 운동화가 오늘 도착했는데 사이즈가 작습니다.
같은 상품을 한 치수 큰 것으로 바꾸고 싶어요. 이 앱에서 해 보세요."
→ 목표만 주고 경로는 안 준다. 사용자의 말('바꾸다')과 화면의 말
('교환 신청')이 다를 때 걸리는지가 그대로 드러난다과업 카드에는 네 가지를 적는다.
| 항목 | 내용 | 예시 |
|---|---|---|
| 시나리오 | 사용자 말로 쓴 상황과 목표 | 사이즈가 작아 한 치수 큰 것으로 바꾸고 싶다 |
| 성공 조건 | 관찰자가 무엇을 보면 성공으로 칠지 | 교환 신청 완료 화면에 도달 |
| 중단 조건 | 언제 끊을지 | 8분 경과 또는 본인이 "못 하겠다"고 말할 때 |
| 관찰 포인트 | 미리 의심하는 지점 | 마이페이지 진입, 교환/반품 구분, 사유 선택 |
중단 조건을 미리 정해 두는 것이 중요하다. 정해 두지 않으면 진행자는 사용자가 괴로워하는 걸 보다 못해 힌트를 준다. 그 순간 그 과업의 데이터는 버려진다.
과업 순서도 설계 대상이다. 쉬운 것 → 어려운 것 순으로 배치해 자신감을 쌓게 하되, 가장 중요한 과업을 마지막에 두지 않는다 — 시간이 부족하면 잘리는 것이 마지막이다.
사고발화(Think-Aloud)
사고발화는 사용자가 화면을 보며 드는 생각을 소리 내어 말하게 하는 기법이다. 화면 밖에서는 "3초 멈칫함"으로만 보이는 것이, 발화로는 "어... 여기에 환불이 있을 줄 알았는데 없네"로 기록된다. 멈칫함은 해석이 필요하지만 발화는 그 자체가 데이터다.
시작할 때 이렇게 설명한다.
"지금부터 화면을 보시면서 머릿속에 드는 생각을 그냥 소리 내서 말씀해 주세요.
정리해서 말씀하실 필요 없고, 혼잣말이라고 생각하시면 됩니다.
'이게 뭐지', '여기 눌러 볼까', '아 이건 아닌가 보다' 같은 것도 다 좋습니다.
제가 조용히 있더라도 신경 쓰지 마세요."사용자는 반드시 중간에 조용해진다. 집중하면 말이 멎는 것이 정상이다. 이때 내용이 없는 중립 촉구 를 쓴다.
| 상황 | 써도 되는 말 | 쓰면 안 되는 말 |
|---|---|---|
| 조용해졌을 때 | "지금 무슨 생각 하고 계세요?" | "뭘 찾고 계세요? 상단 메뉴 보셨어요?" |
| 헤맬 때 | "계속 해 보세요." (침묵 유지) | "거의 다 왔어요." |
| 질문을 받았을 때 | "평소에 혼자 쓰신다면 어떻게 하실 것 같으세요?" | "네, 거기 맞아요." |
| 포기 직전 | "지금 어떤 느낌이신지 말씀해 주시겠어요?" | "아, 그건 저희도 좀 헷갈리게 만들었어요." |
진행자가 하지 말아야 할 말
여기가 이 레슨의 핵심이다. 데이터를 망치는 것은 대개 진행자의 선의 다.
[1] 답을 알려 준다
"위쪽에 메뉴 있는 거 보이세요?"
→ 이 과업의 결과는 이제 무효다. 발견하지 못한 것을 발견했다고 기록할 수 없다
[2] 정답 여부를 알려 준다
"네 맞아요" / "아 그건 아니에요"
→ 사용자는 이후 진행자의 표정을 보며 조작한다. 자기 판단으로 움직이지 않는다
[3] 유도 질문을 한다
"이 버튼이 좀 찾기 어렵지 않으셨어요?"
→ 사용자는 동의해 준다. 문제가 없었어도 "네 좀 그렇네요"라고 답한다
→ 중립형: "이 화면에서 어떠셨는지 말씀해 주세요"
[4] 변명하거나 설명한다
"원래 여기 있었는데 최근에 옮겨서요"
→ 사용자가 미안해하기 시작한다. 이후 부정적 의견을 삼킨다
[5] 미래 행동을 묻는다
"이 기능 있으면 쓰실 것 같으세요?"
→ 사람은 자기 미래 행동을 잘 예측하지 못한다. "네 쓸 것 같아요"는 데이터가 아니다
→ 대체: "최근에 비슷한 상황이 있었다면 그때 어떻게 하셨어요?" (과거 행동을 묻는다)
[6] 사용자를 위로한다
"괜찮아요, 원래 다들 여기서 헤매세요"
→ 친절하지만, 사용자에게 "헤매는 게 정상"이라는 프레임을 준다
→ 대체: "제품을 보고 있는 거니까 편하게 하셔도 됩니다" (세션 시작 때 한 번만)"평소에 혼자였다면 어떻게 하셨을까요?" 가 진행자의 만능 문장이다. 질문을 받았을 때, 힌트를 달라고 할 때, 진행자를 쳐다볼 때 전부 이 문장으로 공을 되돌린다.
관찰 기록 — 사실과 해석을 분리한다
기록이 해석으로 오염되면 나중에 아무도 검증할 수 없다.
[오염된 기록]
"사용자 P3는 환불 메뉴를 못 찾아서 짜증이 났다. UI가 복잡하기 때문이다."
[분리된 기록]
관찰(사실) : 03:20 홈 → 03:35 마이페이지 → 03:52 설정(체류 21초) →
04:13 다시 홈 → 04:40 "없는 것 같은데요"라고 말함
발화(인용) : "보통 이런 건 주문한 데 있지 않나요?"
해석(가설) : 사용자는 환불을 '주문'의 하위로 기대했으나 '고객센터' 하위에 있음
→ 정보 구조 문제일 가능성. P1, P4에서도 유사 경로 확인 필요관찰·발화·해석 세 칸을 나눠 적는다. 해석 칸은 반드시 가설로 쓰고 다른 참가자에서 확인할 계획 을 붙인다. 한 명의 행동으로 결론을 내리면 그게 UT를 신뢰할 수 없게 만드는 가장 큰 이유가 된다.
기록에 반드시 남길 항목은 다음과 같다.
| 항목 | 왜 필요한가 |
|---|---|
| 과업 시작·종료 시각 | 소요 시간 계산(레슨 3) |
| 완료 여부 | 성공/도움받아 성공/실패 — 3단계로 |
| 도움 제공 여부와 시점 | 도움을 준 과업은 성공률 계산에서 별도 처리 |
| 오류 횟수 | 잘못 누른 경로, 되돌아간 횟수 |
| 직접 인용 | 리포트에서 가장 강한 증거. 요약하지 말고 그대로 |
| 비언어 신호 | 한숨, 화면 확대, 스크롤 반복 — 사실만 적는다 |
관찰자와 기록자를 분리한다
진행자가 동시에 기록하면 둘 다 나빠진다. 가능하면 진행자 1명 + 기록자 1명 으로 간다. 기록자는 다른 방이나 화면 공유로 보고, 세션 중에는 말하지 않는다. 기록자를 둘 수 없으면 녹화 후 회수 가 차선이다 — 이때 녹화 동의를 반드시 미리 받는다.
이해관계자(기획자·디자이너·개발자)를 참관시키면 좋다. 보고서 열 장보다 직접 본 5분이 더 강하다. 다만 참관자에게 규칙을 준다.
참관 규칙
1. 세션 중 말하지 않는다. 질문은 쪽지로 진행자에게 전달한다
2. 웃거나 한숨 쉬지 않는다. 사용자가 다 느낀다
3. 세션 직후 "가장 놀란 것 한 가지"를 각자 한 줄로 적는다3번이 핵심이다. 세션이 끝나면 기억은 30분 안에 각색되기 시작한다. 직후 5분 디브리핑 이 나중의 한 시간보다 정확하다.
몇 명을 봐야 하나
"5명이면 문제의 대부분이 나온다"는 말은 널리 쓰이지만 조건부다. 하나의 사용자 집단, 하나의 인터페이스 에서 그렇다. 신규 가입자와 5년 쓴 관리자는 다른 집단이므로 각각 봐야 한다. 모바일과 데스크톱도 다른 인터페이스다.
실무 판단은 이렇게 한다.
집단이 하나 → 5명 전후. 3명째부터 반복되는 문제가 보이기 시작한다
집단이 둘 이상 → 집단당 3~4명. 총 6~8명
비교(A안 vs B안) → 통계적 비교가 목적이면 훨씬 많이 필요하다.
소수 세션으로는 "B가 더 낫다"를 주장할 수 없고,
"B에서 이런 혼란이 관찰됐다"까지만 말할 수 있다마지막 줄이 중요하다. 소수 세션의 숫자는 문제를 찾는 용도 지 우열을 판정하는 용도 가 아니다. 판정이 필요하면 레슨 7의 A/B 테스트로 간다.
원격 세션과 비모더레이트 세션
모더레이트 원격(화상 + 화면 공유)은 대면과 거의 같게 운영할 수 있다. 다만 두 가지가 달라진다 — 표정과 손의 움직임이 안 보이고, 화면 공유 지연으로 "지금 뭐 하시는 거예요"라고 묻게 된다. 시작 전에 화면 공유·마이크·녹화를 점검하는 5분을 따로 잡는다.
비모더레이트(도구가 과업을 제시하고 혼자 수행)는 값싸고 빠르지만 왜 그랬는지를 물을 수 없다. 진행자의 개입이 없어 데이터는 깨끗하지만, 사용자가 과업을 오해해도 바로잡을 수 없다. 과업이 아주 명확한 검증(예: 두 레이블 중 어느 쪽이 찾기 쉬운가)에 적합하다.
실무에서 왜 필요한가
QA가 사용성 세션을 직접 돌릴 수 있으면 조직에서의 위치가 달라진다. 기능 결함은 "고쳐 주세요"라고 요청하는 입장이지만, 사용성 세션 기록은 의사결정 회의에 가져갈 수 있는 증거 다. "5명 중 4명이 교환 진입점을 못 찾았고, 평균 4분 30초를 헤맸습니다. 영상 2분짜리 클립 보시겠어요?"에 반론하기는 어렵다.
또 UT는 요구사항 결함을 잡는 마지막 그물 이다. 모듈 2에서 요구사항 검증을 배웠지만, 명세 리뷰로는 "이 흐름이 사용자의 머릿속 모델과 다르다"를 잡기 어렵다. 명세대로 정확히 구현했는데 아무도 못 쓰는 화면이 나오는 이유가 여기 있다. UT는 명세가 아니라 사람 을 기준으로 삼는 유일한 검증이다.
채용시장에서의 위치
"UT 운영 경험"은 프로덕트 QA·UX 리서처 공고에 자주 등장하는데, 실제로 돌려 본 사람이 드물어 변별력이 높다. 면접에서는 방법론 이름보다 "세션 중에 사용자가 답을 물어보면 어떻게 하세요?" 같은 실무 질문이 나온다. "평소에 혼자 쓰신다면 어떻게 하실 것 같은지 되묻는다"라고 답할 수 있으면 실제로 해 본 사람이라는 게 드러난다.