[내일 배움 캠프] 33일차

TIL — 사용성 테스트는 “유저의 실제 행동”을 보는 가장 빠른 방법

1) 왜 UT가 중요한지, 오늘 제일 크게 남은 한 줄

우리는 유저가 아니다.
기획/디자인/개발을 오래 붙잡고 있을수록 서비스 구조를 “이미 알고 있는 상태”가 되어서, 처음 들어온 사람의 막힘을 상상으로만 때우게 된다. UT는 그 상상을 관찰 가능한 사실로 바꿔준다.

2) UT의 목적과 적용 시점이 명확해졌다

프로토타입만 준비돼 있으면 개발 단계 어디서든 가능하고

개선 전에는 “어디가 불편한지”를 찾고

개선 후에는 “의도한 시나리오대로 행동하는지”를 확인한다.
결국 UT의 목적은 예상한 흐름대로 유저가 움직이는지 + 예상 못한 문제(막힘, 실수, 혼란)가 있는지 확인하는 것.

3) 준비 절차는 ‘문서’보다 ‘설계’였다

오늘 배운 준비 프로세스가 머릿속에서 한 줄로 정리됐다.

목적 설정 → 리크루팅/스크리닝 → 테스크 선정 → 시나리오 작성 → 파일럿 테스트

특히 파일럿 테스트가 “있으면 좋은 것”이 아니라,

음향/화면/프로토타입 버그 같은 환경 변수

질문 문구가 내부 용어로 오염됐는지

전체 소요 시간이 터지는지
를 미리 잡아주는 필수 안전장치라는 게 확 와닿았다.

4) 실행의 핵심은 Think Aloud + 진행자의 ‘개입 최소화’

UT에서 제일 어려운 건 “진행자가 친절해지고 싶은 마음”을 참는 거였다.

Think Aloud: 유저가 클릭하는 순간의 생각/감정을 말하게 해서 “왜 그 선택을 했는지”까지 데이터로 남긴다.

진행자는 힌트를 주지 않고, 유도 질문 대신 열린 질문으로 파고든다.

예: “왜 그 버튼을 눌렀어요?” / “여기서 어떤 걸 기대했어요?”

원격이라면 Zoom, Google Meet 같은 툴로도 가능하고, 시간/예산이 부족하면 카페에서 1:1로도 할 수 있다는 점이 현실적으로 도움이 됐다.

5) 결과 정리는 ‘문제점-원인-개선방향’ 3단 구조로

오늘 배운 정리 방식이 실무적으로 딱이었다.

문제점: 실제 발언/행동 기반으로 무엇이 막혔는지

원인: 유저의 기대 vs 실제 경험의 불일치

개선 방향: 테스크 단위로 액션 아이템화 (필요 시 구조 개선까지)

그리고 우선순위는 느낌이 아니라 데이터로:

성공/실패(PASS/FAIL)

소요 시간(Think Aloud/인터뷰 시간 제외)

이동 동선(예상 경로 대비 얼마나 헤맸는지)

만족도(5점 척도 + 이유)

과제 적용 — 커머스 로그인/회원가입 UT 테스크 7개 설계

오늘 배운 내용을 그대로 과제에 붙여보니, 테스크는 “기능 나열”이 아니라 막히기 쉬운 순간을 의도적으로 만들기라는 걸 알게 됐다.
그래서 신규 유저 기준으로 가입→로그인→복구→이탈 후 재진입까지 전형 흐름 + 에지 케이스를 모두 커버하도록 7개를 잡았다.

1 회원가입 진입 경로 찾기

2 카카오로 소셜 가입 완료

3 이메일로 회원가입 완료(비밀번호/약관 포함)

4 가입 후 로그아웃 → 재로그인(방금 만든 계정)

5 로그인 유지/자동로그인 설정 확인

6 비밀번호 찾기/재설정으로 복구 로그인

7 가입 중 이탈 후 재진입(중단 복구/재시도)

이렇게 구성한 이유는, 로그인/회원가입에서 문제는 대부분

진입 버튼을 못 찾거나

가입 방식 선택에서 갈등하거나(소셜 vs 이메일)

인증/비밀번호 규칙에서 막히거나

로그인 유지/복구(비번 재설정)에서 실패하거나

중단 후 다시 왔을 때 길을 잃는 것
에서 터지기 때문이다.

6) 휴리스틱 평가와 UT의 관계도 연결됐다

휴리스틱 평가는 전문가 관점 점검이고, UT는 유저 행동 관찰이다.
둘 다 필요하지만, UT를 하다 보면 닐슨의 원칙이 “결과 해석 프레임”으로 바로 쓰인다는 게 인상적이었다.

예를 들어 회원가입에서

오류 메시지가 모호하면 “오류 인지/해결 지원”이 약한 거고

현재 단계가 안 보이면 “시스템 상태의 가시성”이 약한 거고

취소/뒤로가기가 불편하면 “사용자 자유도/제어”가 부족한 신호가 된다.
(닐슨 10가지 프레임이 UT 결과를 분류하고 설득하는 데 진짜 유용할 것 같다. 제이콥 닐슨)

오늘의 결론

UT는 “잘 만들어졌는지”를 묻는 게 아니라, 유저가 실제로 ‘통과’할 수 있는지를 확인하는 과정이었다.
그리고 과제에서 테스크를 짤 때도, “할 수 있는 것”보다 헤매기 쉬운 지점이 드러나는 흐름을 설계하는 게 핵심이라는 걸 배웠다.