사용성 평가·사용성 테스트·제품 사용성·디자인 평가, 어디서 막히는지 찾는 법
새로 만든 앱의 회원가입 화면을 보여줬는데, 팀원들은 모두 “괜찮다”고 했습니다. 그런데 실제 사용자는 비밀번호 입력 단계에서 멈췄고, 문의 게시판에는 같은 질문이 계속 올라왔습니다. 만든 사람에게는 자연스러운 화면도 처음 방문한 사람에게는 길을 잃게 만드는 표지판일 수 있습니다.
사용성 평가는 이런 차이를 찾아내는 과정입니다. 이 글을 읽으면 사용성 평가와 사용성 테스트의 차이, 무엇을 관찰해야 하는지, 적은 인원으로 시작하는 방법, 결과를 디자인 개선으로 연결하는 기준을 알게 됩니다.
사용성 평가란 무엇인가
사용성 평가는 제품이나 화면이 사용하기 편한지 살펴보는 일입니다. 여기서 제품은 앱과 웹사이트뿐 아니라 키오스크, 안내문, 업무용 프로그램처럼 사람이 직접 조작하거나 읽는 모든 것을 포함할 수 있습니다.
평가할 때는 단순히 “예쁘다” 또는 “불편하다”라고 말하는 데서 끝나지 않습니다. 사용자가 목표를 얼마나 빨리 찾는지, 실수했을 때 다시 돌아올 수 있는지, 안내 문구를 이해하는지, 도움 없이 과정을 끝내는지를 함께 봅니다. 따라서 디자인 평가는 시각적인 인상만 보는 활동이 아니며, 실제 행동과 맥락까지 살펴야 합니다.
- 효율성: 원하는 일을 하기까지 불필요한 단계가 많지 않은가
- 이해 가능성: 버튼과 안내 문구의 뜻이 바로 전달되는가
- 오류 대응: 잘못 눌렀을 때 원인을 알 수 있고 되돌릴 수 있는가
- 기억 부담: 다음에 다시 방문했을 때 사용법을 새로 배워야 하는가
- 만족도: 과정이 불안하거나 답답하지 않은가
평가 전에 확인할 체크리스트
좋은 평가의 출발점은 화면이 아니라 사용자의 목표입니다. “홈 화면이 예쁜가”보다 “처음 온 사람이 원하는 강좌를 1분 안에 신청할 수 있는가”처럼 확인할 행동을 정해야 합니다.
- 누가 사용하는가: 처음 방문한 사람인지, 반복 이용자인지 구분합니다.
- 무엇을 하려는가: 검색, 신청, 결제, 문의처럼 행동을 하나로 좁힙니다.
- 어디서 사용하는가: 집의 큰 화면인지, 이동 중인 휴대전화인지 적습니다.
- 어떤 기기와 환경인가: 작은 화면, 느린 통신, 밝은 야외처럼 조건을 포함합니다.
- 성공 기준은 무엇인가: 완료 여부뿐 아니라 걸린 시간과 도움 요청도 기록합니다.
참여자를 고를 때는 나이만 보지 말고 경험 차이를 살펴야 합니다. 온라인 예약을 자주 하는 사람과 거의 하지 않는 사람은 같은 화면을 보고도 다른 어려움을 겪습니다. 장애가 있거나 글자와 조작에 제약이 있는 사용자도 대상에 포함할 필요가 있습니다. 모든 사용자를 한 번에 대표할 수는 없으므로, 서비스의 실제 이용자와 가까운 집단부터 정합니다.
사용성 테스트와 다른 평가 방법 비교
사용성 테스트는 사용자가 실제로 과제를 수행하는 모습을 관찰하는 방법입니다. 예를 들어 “이번 달 토요일 오전에 이용 가능한 강좌를 찾아 신청해 주세요”라고 요청한 뒤, 어디에서 멈추고 어떤 말을 하는지 기록합니다. 질문지를 통해 의견만 묻는 것보다 행동의 원인을 발견하기 좋습니다.
반면 전문가 검토는 경험 많은 사람이 정해 둔 기준으로 화면을 살피는 방식입니다. 짧은 시간에 큰 문제를 찾는 데 유리하지만, 실제 사용자가 느끼는 혼란을 모두 대신 보여 주지는 못합니다. 설문조사는 많은 사람의 만족도나 선호를 확인하기 좋지만, 특정 버튼을 왜 누르지 않았는지까지 깊게 밝히기 어렵습니다.
| 방법 | 잘 찾는 것 | 주의할 점 |
|---|---|---|
| 사용성 테스트 | 실제 행동, 막히는 순간, 오해 | 참여자와 진행 환경을 잘 준비해야 함 |
| 전문가 검토 | 기본 규칙 위반, 구조적 문제 | 전문가의 관점에 치우칠 수 있음 |
| 설문조사 | 만족도, 선호, 반복되는 의견 | 행동의 원인을 깊게 알기 어려움 |
| 자료 분석 | 이탈 구간, 이용 빈도, 검색어 | 수치만으로 감정과 이유를 단정할 수 없음 |
처음부터 한 가지 방법만 고집할 필요는 없습니다. 전문가 검토로 위험한 문제를 먼저 걸러 낸 뒤, 사용성 테스트로 실제 행동을 확인하고, 개선 후 자료 분석으로 변화가 있었는지 살피는 식으로 이어 갈 수 있습니다.
사용성 평가를 진행하는 순서
- 질문을 정합니다. “화면이 좋은가” 대신 “처음 방문한 사용자가 배송비를 찾을 수 있는가”처럼 행동으로 씁니다.
- 과제를 만듭니다. 실제 상황처럼 구체적으로 작성하되, 정답 버튼의 이름을 직접 알려 주지 않습니다.
- 관찰 기준을 정합니다. 완료 여부, 머문 위치, 잘못 누른 횟수, 도움을 요청한 시점, 사용자의 말을 기록합니다.
- 진행합니다. 참여자에게 정답을 가르치기보다 생각나는 말을 해 달라고 요청합니다. 진행자는 중립적인 표정을 유지해야 합니다.
- 문제를 묶습니다. 버튼 위치, 단어 이해, 정보 부족, 오류 처리처럼 원인별로 분류합니다.
- 우선순위를 정합니다. 자주 발생하고 목표 달성을 막는 문제부터 고칩니다. 보기 불편하지만 업무를 끝낼 수 있는 문제보다, 결제나 신청을 막는 문제가 먼저입니다.
- 다시 확인합니다. 수정 뒤 같은 문제가 줄었는지 확인합니다. 참여자의 의견이 좋아졌다는 말만으로 성공을 단정하지 않습니다.
질문도 결과를 크게 바꿉니다. “이 버튼이 신청 버튼인 것 같죠?”라고 묻는 대신 “지금 무엇을 하려고 하나요?”라고 물어야 합니다. 전자는 진행자의 생각을 주입하지만, 후자는 사용자의 이해 과정을 보여 줍니다. 한 사람의 표현이 인상적이어도 여러 관찰 기록과 함께 판단하는 것이 안전합니다.
자주 생기는 실수와 개선 방법
첫째, 팀원만 대상으로 평가하는 경우입니다. 팀원은 서비스 용어와 화면 구조를 이미 알고 있습니다. 그래서 실제 신규 사용자라면 놓칠 안내를 자연스럽게 넘길 수 있습니다. 팀 내부 검토는 초반 오류를 찾는 용도로 쓰고, 최종 판단은 실제 사용자와 가까운 사람에게서 얻는 편이 좋습니다.
둘째, 참여자에게 정답을 알려 주는 경우입니다. 막히는 순간마다 “오른쪽 위 메뉴를 눌러 보세요”라고 말하면 문제를 숨기게 됩니다. 대신 “무엇을 찾고 있나요?” 또는 “어디를 눌러야 할 것 같나요?”처럼 관찰을 돕는 질문을 사용합니다.
셋째, 예쁜 의견만 모으는 경우입니다. 색상 선호는 쉽게 말할 수 있지만, 사용자는 실제로 불편한 점을 잊고 지나갈 수도 있습니다. “좋았나요?”라는 질문과 함께 완료까지 걸린 시간, 오류 횟수, 되돌아간 경로를 기록해야 합니다.
넷째, 문제를 모두 같은 크기로 다루는 경우입니다. 자주 발생하는 작은 불편과 한 번 발생해도 업무를 완전히 막는 오류는 다르게 봐야 합니다. 발생 빈도와 영향도를 각각 낮음·중간·높음으로 표시하면 수정 순서를 정하기 쉽습니다.
다섯째, 접근성을 나중에 보는 경우입니다. 글자 크기를 키웠을 때 화면이 깨지는지, 색상만으로 상태를 구분하지 않는지, 키보드나 보조기기로 조작 가능한지 처음부터 확인해야 합니다. 공공서비스나 보조기기 관련 제품처럼 이용자 범위가 넓은 경우에는 기관의 최신 공식 안내와 관련 기준도 함께 재확인해야 합니다.
자주 묻는 질문
참여자는 몇 명이어야 하나요?
정해진 숫자만으로 품질을 보장할 수는 없습니다. 중요한 이용자 유형과 과제를 먼저 정하고, 같은 문제가 반복되는지 살피는 방식이 현실적입니다. 다만 한 유형만 보면 다른 사용자 집단의 문제를 놓칠 수 있으므로, 대상이 여러 종류라면 유형별로 나누어 확인해야 합니다.
화면이 완성되지 않아도 평가할 수 있나요?
가능합니다. 종이에 그린 화면, 클릭 가능한 시제품, 설명용 모형으로도 메뉴 이름과 이동 흐름의 문제를 찾을 수 있습니다. 오히려 개발이 끝난 뒤 구조를 바꾸는 것보다 초기에 고치는 편이 비용과 시간을 줄이기 쉽습니다.
사용자가 불편하다고 말하면 바로 고쳐야 하나요?
그 의견은 중요한 단서지만 곧바로 결론은 아닙니다. 같은 불편이 다른 참여자에게도 나타났는지, 목표 달성을 막는지, 특정 환경에서만 생기는지 확인해야 합니다. 개인 취향과 여러 사람이 반복해서 겪는 사용성 문제를 구분하는 과정이 필요합니다.
결과를 보고서에 어떻게 남기면 좋나요?
문제 설명, 발생한 상황, 관찰 근거, 영향도, 개선 제안, 다시 확인할 방법을 한 묶음으로 기록합니다. 예를 들어 “버튼이 작다”보다 “작은 화면에서 다음 단계 버튼을 두 번 놓쳤고, 참여자 다섯 명 중 세 명이 같은 위치에서 멈췄다”처럼 남기는 편이 행동으로 이어집니다.
사용성 평가는 누군가를 시험하는 일이 아니라 제품의 막힌 부분을 찾는 일입니다. 사용자의 말과 행동을 함께 보고, 문제의 크기를 비교하고, 수정한 뒤 다시 확인하면 작은 팀에서도 충분히 시작할 수 있습니다. 처음부터 모든 것을 측정하기보다 가장 중요한 사용자 목표 하나를 골라 관찰하는 것이 좋은 첫걸음입니다.