이번 문서의 목표: 사용성 평가 참여자 구성과 과업 시나리오를 설계하고, 시뮬레이션 결과를 심각도 기준으로 정리해 개선 방향을 도출한 뒤 평가 보고서 형식으로 문서화할 수 있게 된다.
1. 왜 프로토타입을 만든 뒤에도 검증이 필요한가
17편과 18편에서 서비스 프로토타입을 기획하고 제작했습니다. 그런데 만든 사람의 눈에는 문제가 보이지 않습니다. 서비스를 설계한 팀은 그 흐름에 이미 익숙해져 있어서, 처음 접하는 사용자가 어디서 멈추고 어디서 헷갈리는지 스스로는 알아채기 어렵습니다.
쉽게 말하면: 요리사가 자기 요리의 간을 맞게 느끼는 것과, 처음 먹어 보는 손님이 짜다고 느끼는 것은 다릅니다. 손님에게 직접 먹여 보지 않으면 알 수 없습니다.
사용성 평가(usability evaluation)는 실제 또는 잠재 사용자가 프로토타입으로 정해진 과업을 수행하게 하고, 그 과정에서 나타나는 문제점을 관찰·측정해 개선점을 찾아내는 활동입니다. 18편의 서비스 워크스루(walkthrough)가 “설계자가 흐름을 점검”하는 것이라면, 사용성 평가는 “사용자가 실제로 겪는 어려움을 확인”하는 것으로 관점이 다릅니다.
2. 평가 방법 계획 수립
참여자 구성
| 항목 | 판단 기준 |
|---|---|
| 인원수 | 5명 내외면 주요 사용성 문제의 대부분이 드러난다(문제 발견 수가 인원 증가에 따라 급격히 둔화됨) |
| 대상 선정 | 10편 페르소나의 핵심 사용자 특성을 대표하는 실제 인물로 모집 |
| 사전 경험 여부 | 서비스를 접해 본 적 없는 신규 참여자와 이미 써 본 참여자를 구분해 각각 다른 문제를 확인 |
| 다양성 | 디지털 기기 활용도가 높은 참여자와 낮은 참여자를 함께 포함해 극단 사용자의 어려움도 확인 |
자주 틀리는 점: 참여자를 팀 내부 직원이나 지인으로만 구성하는 경우가 많습니다. 내부 직원은 서비스 구조를 이미 알고 있어 실제 신규 사용자가 겪는 혼란을 재현하지 못합니다. 답안에서는 반드시 페르소나와 일치하는 외부 참여자를 명시해야 합니다.
과업 시나리오 설계
과업 시나리오는 참여자에게 “이 화면을 눌러 보세요”라고 지시하는 대신, 실제 목표만 제시하고 스스로 경로를 찾게 구성합니다.
| 잘못된 지시 | 올바른 과업 시나리오 |
|---|---|
| 메뉴 화면에서 대체 메뉴 버튼을 누르세요 | 오늘 배송될 반찬 중 하나가 입맛에 맞지 않아 다른 메뉴로 바꾸고 싶습니다. 원하는 대로 바꿔 보세요 |
| 알림 설정 화면으로 이동하세요 | 배송이 언제 오는지 매번 확인하기 번거롭습니다. 알아서 알려 주도록 설정해 보세요 |
왜 목표만 제시해야 하는가: 화면 이름과 버튼 위치까지 알려 주면 참여자가 실제로 그 경로를 스스로 찾아낼 수 있는지 확인할 수 없습니다. 사용성 평가의 목적은 경로를 찾는 과정 자체에서 어디가 막히는지 보는 것입니다.
평가 지표
| 지표 | 정의 |
|---|---|
| 성공률 | 과업을 스스로 완료한 참여자 비율 |
| 소요 시간 | 과업 시작부터 완료까지 걸린 시간 |
| 오류 횟수 | 잘못된 경로로 들어갔다가 되돌아온 횟수 |
| 주관 만족도 | 과업 완료 직후 참여자가 평가하는 체감 난이도 점수 |
3. 프로토타입 시뮬레이션 평가 절차
- 참여자에게 과업 시나리오를 하나씩 제시한다 — 한 번에 여러 과업을 섞지 않는다
- 참여자가 소리 내어 생각하며 조작하게 한다(사고 발화법) — “지금 왜 이 버튼을 누르셨나요?” 같은 질문으로 이유를 함께 기록한다
- 관찰자는 개입하지 않고 막히는 지점과 소요 시간을 기록한다 — 힌트를 주면 실제 사용성 문제가 가려진다
- 과업이 끝나면 주관 만족도를 점수로 묻는다
- 모든 참여자의 시뮬레이션이 끝나면 지표를 표로 종합한다
자주 틀리는 점: 관찰자가 참여자가 헤맬 때 바로 도와주는 경우가 많습니다. 도와주는 순간 그 지점의 문제가 데이터에서 사라지므로, 원칙적으로 참여자가 완전히 포기 의사를 밝히기 전까지는 개입하지 않습니다.
4. 서술 답안 예시 — 평가 결과표와 개선 방향 도출
가상 서비스 오늘의반찬의 “메뉴 변경” 과업에 대한 시뮬레이션 결과를 케이스로 정리합니다.
| 참여자 | 성공 여부 | 소요 시간 | 오류 횟수 | 만족도(5점) |
|---|---|---|---|---|
| P1(20대, 디지털 활용도 높음) | 성공 | 18초 | 0 | 5 |
| P2(30대, 디지털 활용도 보통) | 성공 | 42초 | 1 | 3 |
| P3(60대, 디지털 활용도 낮음) | 실패(중도 포기) | 95초 | 4 | 1 |
| P4(20대, 디지털 활용도 높음) | 성공 | 21초 | 0 | 5 |
| P5(50대, 디지털 활용도 낮음) | 성공(도움 요청 후) | 88초 | 3 | 2 |
해석: 성공률만 보면 4/5(80퍼센트)로 양호해 보입니다. 그러나 디지털 활용도가 낮은 참여자 두 명(P3, P5)에게서 오류 횟수와 소요 시간이 집중적으로 나타났습니다. 평균값만 보고 “대체로 문제없다”고 결론 내리면 특정 사용자 집단의 문제를 놓칩니다. 집단별로 나누어 해석하는 것이 핵심입니다.
문제점을 심각도로 분류하기
- 관찰된 문제를 모두 나열한다 — “메뉴 변경 버튼을 찾지 못함”, “변경 확인 화면에서 뒤로 가기를 눌러 처음부터 다시 시도함” 등
- 각 문제가 발생한 참여자 수와 과업 실패로 이어졌는지를 확인한다
- 영향받는 사용자 수와 실패 여부를 기준으로 심각도를 매긴다
- 심각도가 높은 문제부터 개선 방향을 도출한다
| 문제점 | 영향받은 참여자 | 실패로 이어졌는가 | 심각도 | 개선 방향 |
|---|---|---|---|---|
| 메뉴 변경 버튼의 위치를 찾지 못함 | P3, P5 | 예 | 높음 | 배송 예정 화면 상단에 변경 버튼을 고정 노출 |
| 변경 확인 화면 문구가 이해되지 않음 | P2, P5 | 아니오 | 보통 | 확인 문구를 쉬운 말로 다시 작성 |
| 버튼 글자 크기가 작아 다시 확인함 | P3 | 아니오 | 낮음 | 다음 개편 시 글자 크기 조정 검토 |
자주 틀리는 점: 발견된 문제를 심각도 구분 없이 나열만 하는 답안이 많습니다. 실기 답안에서는 영향받은 인원과 실패 여부라는 근거를 바탕으로 심각도를 매기고, 심각도 순서로 개선 방향을 제시해야 합니다. 심각도가 낮은 문제부터 손대면 정작 실패로 이어지는 문제가 방치됩니다.
5. 평가 결과 문서화
평가 보고서 구성
- 평가 목적과 대상 프로토타입 — 무엇을 검증하려 했는지
- 참여자 구성 — 인원수, 페르소나와의 대응 관계
- 과업 시나리오와 평가 지표 — 무엇을 어떻게 측정했는지
- 결과표 — 참여자별 지표 종합
- 문제점과 심각도 분류표
- 개선 방향과 우선순위 — 21편 로드맵·포트폴리오와 연결해 언제 반영할지 명시
왜 로드맵과 연결해야 하는가: 사용성 평가에서 나온 개선안은 그 자체로 끝나지 않고, 21편에서 다룬 서비스·경험 로드맵의 입력값이 됩니다. 심각도가 높은 개선안은 로드맵의 단기 항목으로, 심각도가 낮은 개선안은 중장기 항목으로 배치되는 것이 논리적으로 일관됩니다.
핵심 정리
- 사용성 평가는 설계자가 아니라 실제 사용자가 프로토타입으로 과업을 수행하며 겪는 문제를 확인하는 활동이다.
- 참여자는 5명 내외로도 주요 문제 대부분이 드러나며, 페르소나를 대표하는 외부 참여자로 구성해야 한다.
- 과업 시나리오는 버튼 위치가 아니라 목표만 제시해, 참여자가 스스로 경로를 찾는 과정을 관찰해야 한다.
- 평가 지표는 성공률·소요 시간·오류 횟수·주관 만족도이며, 평균만 보지 않고 사용자 집단별로 나누어 해석해야 특정 집단의 문제를 놓치지 않는다.
- 문제점은 영향받은 인원 수와 실패 여부를 근거로 심각도를 매기고, 심각도 순서로 개선 방향을 도출해야 한다.
- 평가 결과는 목적-참여자-과업-결과표-심각도 분류-개선 방향의 순서로 문서화하며, 개선 방향은 로드맵과 연결해 실행 시기를 명시한다.