사용자 리서치: 방법 고르기, 페르소나·시나리오, 사용성 평가

사용자 리서치가 필요한 이유

제품 팀은 "이 제품이 무엇을 해야 하나"부터 "이 버튼에 뭐라고 쓰나"까지 끝없이 결정한다. 결정마다 위험이 있고, 그 위험을 줄이는 가장 중요한 근거가 사용자에 대한 이해다. 직관과 시장 이해만으로는 부족하다.

무시한 대가는 숫자로 돌아온다. 업계 조사(HDI, 2016년 데이터)에서 북미 고객지원 통화 한 건의 비용은 평균 15달러 남짓이었다. 디자인 결함으로 문의가 늘면 그대로 비용이 된다.

단계마다 맞는 방법: 더블 다이아몬드

영국 디자인 카운슬의 더블 다이아몬드는 문제를 넓게 탐색한 뒤 좁히고, 해결책을 넓게 시도한 뒤 좁히는 두 번의 발산·수렴이다.

flowchart LR
  subgraph D1["다이아몬드 1: 올바른 문제 찾기"]
    S1["탐색(발산)"] --> S2["정의(수렴)"]
  end
  subgraph D2["다이아몬드 2: 올바른 해결책 만들기"]
    S3["개발(발산)"] --> S4["전달(수렴)"]
  end
  D1 --> D2
  D2 --> S5["출시 후"]

일기 연구는 피트니스 트래커처럼 시간에 걸쳐 일어나는 사용을 볼 때, 단일 세션 관찰은 온라인 쇼핑처럼 한 번에 끝나는 과제에 맞다. 진행자가 있는 심층 세션 하나가 진행자 없는 여러 세션보다 많은 것을 알려 줄 때가 많다.

사용자를 직접 만날 수 없을 때

직접 조사를 대체할 수는 없지만, 이미 쌓인 사용자 목소리로 정성 데이터를 빠르게 모을 수 있다.

페르소나와 UX 시나리오: 조사 결과를 이야기로

조사 결과는 조사 → 분석 → 전략 도출 중 분석 단계에서 페르소나와 시나리오로 정리한다. 기능 목록만 보면 "있으면 좋은 기능"이 끝없이 늘어나지만, 누가 어떤 상황에서 어떤 문제를 안고 서비스를 쓰는지 이야기로 그리면 어떤 순간에 무엇이 가장 가치 있는지와 없어도 되는 기능이 보인다.

페르소나

페르소나는 리서치에서 찾은 사용자 유형을 한 명의 가상 인물로 구체화한 것이다. 수많은 사용자의 동기·욕구·행동 패턴을 한 장으로 요약하고, 회의에서 각자의 짐작 대신 "민지라면 이 버튼을 찾을까?"로 대화하게 한다. 개발자는 사용자의 기술 수준을 과대평가하고 영업은 과소평가하기 쉬운데, 그 시각차도 좁힌다.

UX 시나리오

UX 시나리오는 페르소나가 서비스를 쓰는 과정을 사용 전, 사용 중, 사용 후로 나눠 이야기로 쓴 것이다. 사용자(성격·가치관), 니즈와 문제, 사용 맥락(언제·어디서·무엇이 계기인가), 핵심 기능, 과업 흐름, 사용자 가치를 한 흐름에 엮는다. 경험은 동기에서 시작해 행동을 낳고, 결과를 기대와 비교해 평가하고, 그 평가가 기억과 태도로 남는다. 시나리오는 이 흐름 전체를 따라간다.

짧은 예: "퇴근길 지하철에서 지민(29, 직장인 3년 차)은 주말에 갈 북카페를 찾는다. 인스타그램에 저장해 둔 곳은 많지만 다시 찾기 어렵고, 가 보면 자리가 없던 적이 많다. 앱에서 저장한 카페를 지도로 모아 보고, 오늘 저녁 좌석 혼잡도를 확인한 뒤 독서 모임이 있는 곳을 예약한다. 모임이 끝나면 좋았던 문장을 사진으로 남기고 다음 모임 알림을 켠다." 이 한 단락에서 저장 목록, 지도 보기, 실시간 혼잡도, 모임 예약, 기록, 알림이라는 기능 후보와 우선순위가 나온다.

시나리오는 정보 구조와 화면 흐름을 정하는 근거가 되고, 같은 시나리오를 경쟁 서비스로 따라가면 단계별 강점과 빈틈이 보이며, 완성된 화면이 시나리오를 끝까지 따라갈 수 있는지가 곧 검증 기준이 된다. 시나리오의 장면이 사용자 동선대로 끊김 없이 이어져야 하고 단계별 기능이 순서대로 들어 있어야 한다. 힘든 상황의 사용자까지 시나리오에 넣는 관점은 공감하는 제품 만들기의 스트레스 케이스에 있다.

"유저 스토리"라는 말은 두 맥락에서 쓰인다. UX의 유저 스토리(유저 시나리오) 는 장면별 스케치와 매트릭스(시나리오, 니즈, 사용자 행동, 필요한 기능)로 리서치 결과를 이해관계자에게 전하고 기능을 도출하는 기획 초기 산출물이다. 애자일의 사용자 스토리는 "~로서, ~을 위해, ~을 원한다" 한 문장과 인수 조건으로 된 개발 백로그의 작업 단위다(백로그와 추정).

UX 전략으로 잇기

분석 결과는 포지셔닝, 차별화, 디자인 방향으로 정리한다.

이 방향이 이후 와이어프레임과 목업(와이어프레임, 목업, 프로토타입)의 판단 기준이 되고, 완성된 화면은 아래 사용성 평가로 검증한다.

사용성 평가

사용성(usability) 은 사용자가 특정 상황에서 목표를 이루려고 시스템을 쓸 때 "쓰기 쉬운가"다. 국제 표준 ISO 9241-11의 세 축과 재는 법은 다음과 같다. 사용성의 심리학적 바탕(지각, 기억, 어포던스)은 인터페이스 심리학에 있다.

제이콥 닐슨(Jakob Nielsen)은 이를 실무 속성으로 풀었다. 처음 쓰는 사람이 얼마나 빨리 익히나(학습 용이성), 익숙해진 뒤 얼마나 빨리 하나(효율성), 한동안 안 쓰다 돌아와도 기억나나(기억 용이성), 실수가 적고 쉽게 회복되나(오류), 쓰기 즐거운가(만족도). 사람은 보기 좋은 화면의 문제에 더 관대하다(심미적 사용성 효과). 그래서 "좋아요"라는 말이 나와도 실제로 과업을 해냈는지 따로 보고, 반대로 미관을 위해 사용성을 깎지 않는다(대비 낮은 회색 글자, 레이블 없는 아이콘).

휴리스틱 평가

휴리스틱 평가(heuristic evaluation) 는 사용자 없이 UX 전문가가 정해진 원칙 목록에 비춰 화면을 점검하는 방법이다. 평가자 한 명은 문제의 일부만 찾으므로 3~5명이 각자 따로 평가한 뒤 합친다. 빠르고 싸서 와이어프레임·프로토타입 단계에서 큰 문제를 미리 걸러 낸다. 찾은 문제마다 0(문제 아님)부터 4(출시 전 반드시 고침)까지 심각도를 매기고, 빈도·영향·반복성(한 번 겪으면 피할 수 있나)을 함께 본다. 전문가의 판단이라 실제 사용자가 막히는 지점을 놓칠 수 있어 사용성 테스트로 보완한다.

1994년에 정리된 닐슨의 10가지 휴리스틱이 지금도 거의 그대로 쓰인다.

이 목록은 출발점이고 제품에 맞게 항목을 고르거나 더한다. 접근성 관점의 휴리스틱은 디자인 단계의 접근성에, 문구 점검 기준은 UX 라이팅에, 입력 폼 기준은 폼 사용성에 있다.

사용성 테스트

사용성 테스트(UT) 는 실제 사용자(또는 대표 사용자)에게 과업을 주고 수행하는 모습을 관찰하며 문제와 원인을 찾는 방법이다. 어느 단계에서 왜 막혔는지와, 무엇부터 고칠지의 우선순위를 얻는다.

닐슨은 정성 테스트에서 5명 정도면 주요 문제 대부분이 나오고 그 이상은 같은 문제가 반복된다고 봤다. 20명을 한 번에 하기보다 5명씩 고치고 다시 테스트한다. 성공률이나 시간을 통계적으로 비교하려면 더 많은 인원이 필요하다.

정량 지표는 "어디서" 문제가 생겼는지를, 관찰과 발언은 "왜" 생겼는지를 알려 준다.

먼저 휴리스틱 평가로 뻔한 문제를 걷어 내고 남은 시간을 사용성 테스트에 쓰는 순서가 효율적이다. 접근성 측면의 평가 절차는 접근성 평가에 있다.

큰 조직에서 학습 문화 만들기

큰 조직은 느리고 예산을 정당화하라고 요구한다. 대신 사람·도구·업무 관행이라는 자원이 이미 많다. 새로 들이기보다 있는 것을 활용한다.

핵심 기법은 준비되기 전에 정기 세션 일정을 잡는 것이다. 매주 화요일 테스트, 수요일 회의 공유처럼 고정해 두면 "언제 테스트하나"를 따로 정할 필요가 없다. 논쟁이 생기면 아이디어를 적어 두고 다음 세션에서 확인한다. 테스트가 주간 리듬이 되면 팀원이 자기 기능의 피드백을 먼저 요청하게 된다.

리서치를 지속하려면 가치를 비즈니스 언어로 바꿔야 한다. 검증 안 된 기능을 만드느라 쓴 시간, 기능을 두고 논쟁한 시간을 비용으로 환산해 보여 준다.

서두를 때 생기는 디자인 리스크

린·애자일 압박 속에서 리서치를 급히 끝내라는 요구가 많다. 대충 만든 상관관계와 인용문에 기댄 결정이 리스크다.

리서치 윤리

리서치를 모두가 하게 되면서(리서치 민주화) 훈련받지 않은 사람이 사람을 대상으로 조사하는 일이 늘었다. 인터뷰는 말일 뿐이라 해도 참가자에게 해를 줄 수 있다.

당장 할 수 있는 것은 참가자 경험 중심의 사전 동의서와 동료의 연구 절차 검토다. 그다음이 윤리·데이터 분석 교육과 멘토링이고, 학술 발표나 아동·건강 관련 연구라면 학계의 기관윤리위원회(IRB) 검토까지 고려한다.

정리

• 단계에 맞는 방법을 고른다. 탐색엔 관찰, 우선순위엔 설문, 검증엔 진행자 있는 테스트, 미세 조정엔 원격 테스트.
• 사용자를 못 만나도 리뷰·상담 기록·포럼에 목소리가 있다.
• 조사 결과는 행동·목표·불편 중심의 페르소나 몇 명과 사용 전·중·후 시나리오로 정리하고, 그 문장에서 기능 후보와 우선순위를 뽑는다.
• 화면은 전문가 3~5명의 휴리스틱 평가로 먼저 훑고, 과제 시나리오로 실제 사용자 5명씩 관찰한다. 예쁜 화면은 문제를 가리니 말보다 행동을 본다.
• 리서치를 이벤트가 아니라 정기 일정으로 만들면 문화가 된다.
• 급할수록 맥락, 분석 시간, 내 디자인에 대한 애착을 경계한다.
• 참가자도 사람이다. 동의·투명성·데이터 보호를 절차로 갖춘다.

관련 노트: 웹 접근성, 제품 중심 개발자, 새 서비스 개발 프로젝트 진행 순서, 디자인 단계의 접근성, 공감하는 제품 만들기, 와이어프레임, 목업, 프로토타입, 인터페이스 심리학, 아이콘 사용성