실제 사용자를 모집해서 진행하는 ‘사용성 테스트’는 효과적입니다.
하지만 시간과 비용이 많이 든다는 현실적인 어려움이 있습니다.
만약, 전문가 몇 명이 모여서 이미 검증된 좋은 사용성의 ‘원칙’들에 따라, 시스템의 문제점을 빠르게 평가할 수 있다면 어떨까요?
이러한 전문가 기반의 사용성 평가 방법을 ‘휴리스틱 평가(Heuristic Evaluation)’라고 합니다.
이번 글에서는 가장 유명하고 널리 쓰이는 ‘제이콥 닐슨의 10가지 사용성 휴리스틱’에 대해 알아보겠습니다.
Q. ‘휴리스틱 평가’, 정확히 무엇인가요?
‘휴리스틱 평가’는 UI/UX 전문가가 이미 널리 알려지고 검증된 ‘사용성 원칙(Heuristics)’을 기준으로, 시스템의 디자인과 기능이 이 원칙들을 잘 지키고 있는지 평가하고 문제점을 찾아내는 방법입니다.
보통 3~5명의 평가자가 각자 독립적으로 평가한 뒤, 그 결과를 종합하여 객관성과 신뢰도를 높입니다.
QA는 이 원칙들을 학습하여, 사용성 테스트의 보완재 혹은 대체재로 활용할 수 있습니다.
Q. [원칙 1] 시스템 상태의 가시성 (Visibility of system status)
시스템은 현재 무슨 일이 일어나고 있는지, 합리적인 시간 안에 적절한 피드백을 주어 사용자에게 항상 알려줘야 합니다.
- 좋은 예:
- 파일 업로드 시, 몇 퍼센트가 진행되었는지 진행률 바(Progress bar)를 보여주는 것.
- 버튼을 클릭했을 때, 로딩 스피너를 보여주어 시스템이 요청을 처리하고 있음을 알려주는 것.
- 나쁜 예:
- 버튼을 눌렀는데 아무런 시각적 반응이 없어, 사용자가 답답함을 느끼고 버튼을 여러 번 다시 누르게 만드는 것.
Q. [원칙 2] 시스템과 현실 세계의 일치 (Match between system and the real world)
시스템은 개발자만 아는 내부 용어가 아닌, 사용자에게 익숙한 현실 세계의 단어, 문구, 개념을 사용해야 합니다.
- 좋은 예:
- 삭제 기능을 현실 세계의 ‘휴지통’ 아이콘으로 표현하는 것.
- 쇼핑몰에서 상품을 담는 행위를 ‘장바구니’ 아이콘으로 표현하는 것.
- 나쁜 예:
- 오류 발생 시, ‘Null Pointer Exception’과 같은 개발 용어를 사용자에게 그대로 보여주는 것.
Q. [원칙 3] 사용자 제어와 자유 (User control and freedom)
사용자가 실수로 어떤 행동을 했더라도, 쉽게 그 상태를 빠져나갈 수 있는 ‘비상구’를 명확하게 제공해야 합니다.
- 좋은 예:
- ‘실행 취소(Undo)’ 와 ‘다시 실행(Redo)’ 기능.
- 글쓰기 창을 닫으려고 할 때, “저장하지 않고 나가시겠습니까?” 라고 한번 더 물어보는 확인 창.
- 나쁜 예:
- 한번 들어가면 ‘뒤로 가기’나 ‘닫기’ 버튼이 없어, 앱을 강제 종료해야만 빠져나올 수 있는 페이지.
Q. [원칙 4] 일관성 및 표준 (Consistency and standards)
동일한 기능이나 용어, 아이콘은 서비스 내에서 항상 동일한 의미와 형태로 표현되어야 사용자가 혼란을 느끼지 않습니다.
- 좋은 예:
- 모든 페이지에서 ‘저장’ 버튼은 항상 파란색이고, ‘취소’ 버튼은 항상 회색인 것.
- 모든 페이지의 상단 우측에는 항상 ‘내 정보’ 아이콘이 있는 것.
- 나쁜 예:
- 어떤 페이지에서는 ‘삭제’라고 하고, 다른 페이지에서는 ‘제거’라고 하여 사용자를 혼란스럽게 만드는 것.
Q. [원칙 5] 오류 예방 (Error prevention)
오류가 발생한 후 친절한 메시지를 보여주는 것보다, 애초에 사용자가 오류를 저지를 상황을 만들지 않는 것이 더 좋은 디자인입니다.
- 좋은 예:
- 날짜를 직접 입력하게 하는 대신, 달력(Calendar) UI를 제공하여 존재하지 않는 날짜(예: 2월 30일)를 선택할 수 없게 만드는 것.
- ‘삭제’ 버튼을 누르는 즉시 삭제하는 대신, “정말로 삭제하시겠습니까?” 라는 확인 절차를 거치는 것.
- 나쁜 예:
- 전화번호 입력 시, 하이픈(-)을 넣으면 오류가 발생한다고 알려주지 않고, 입력 자체를 막지도 않는 것.
Q. [원칙 6] 기억보다 인식 (Recognition rather than recall)
사용자가 정보를 기억하도록 만들지 말고, 필요한 정보나 기능을 눈에 보이게 하여 쉽게 ‘인식’할 수 있도록 해야 합니다.
- 좋은 예:
- 최근 내가 본 상품 목록을 보여주어, 사용자가 이전에 무엇을 봤는지 기억해낼 필요가 없게 만드는 것.
- 나쁜 예:
- 검색창에 최근 검색어 목록을 보여주지 않아, 매번 같은 검색어를 다시 입력하게 만드는 것.
Q. [원칙 7] 유연성과 사용 효율성 (Flexibility and efficiency of use)
초보자와 전문가 모두를 만족시킬 수 있도록, 시스템은 다양한 사용 수준에 맞는 효율적인 사용 방식을 제공해야 합니다.
- 좋은 예:
- 복사-붙여넣기를 메뉴 클릭으로도 할 수 있지만, 전문가를 위해
Ctrl+C,Ctrl+V와 같은 단축키도 함께 제공하는 것.
- 복사-붙여넣기를 메뉴 클릭으로도 할 수 있지만, 전문가를 위해
- 나쁜 예:
- 모든 기능을 버튼 클릭으로만 수행할 수 있어, 숙련된 사용자가 반복 작업을 할 때 비효율을 느끼게 만드는 것.
Q. [원칙 8] 미학적이고 미니멀한 디자인 (Aesthetic and minimalist design)
인터페이스는 불필요하거나 관련 없는 정보로 가득 채워져서는 안 됩니다. 모든 정보는 저마다의 목적이 있어야 합니다.
- 좋은 예:
- 구글 검색 첫 화면처럼, 가장 핵심적인 기능(검색창)에만 집중할 수 있도록 디자인하는 것.
- 나쁜 예:
- 화면에 너무 많은 광고와 팝업, 관련 없는 정보들이 가득하여, 정작 사용자가 원하는 핵심 기능을 찾기 어렵게 만드는 것.
Q. [원칙 9] 오류의 인식, 진단, 복구 지원 (Help users recognize, diagnose, and recover from errors)
오류 메시지는 사용자에게 좌절감을 주어서는 안 됩니다. 명확한 언어로 문제가 무엇인지 알려주고, 해결책을 건설적으로 제안해야 합니다.
- 좋은 예:
- “비밀번호는 영문, 숫자를 포함하여 8자 이상이어야 합니다.” 와 같이, 무엇이 잘못되었고 어떻게 해야 하는지 명확히 알려주는 것.
- 나쁜 예:
- 단순히 “에러 코드 502: 잘못된 입력” 과 같이, 사용자가 이해할 수 없는 메시지만 보여주는 것.
Q. [원칙 10] 도움말 및 문서 (Help and documentation)
가장 좋은 것은 도움말 없이도 시스템을 사용할 수 있는 것이지만, 필요할 때를 대비해 사용자가 쉽게 찾을 수 있는 도움말과 문서를 제공해야 합니다.
- 좋은 예:
- 복잡한 기능 옆에 ‘?’ 아이콘을 두어, 클릭 시 해당 기능에 대한 간단한 설명을 보여주는 것.
- 자주 묻는 질문(FAQ) 페이지를 찾기 쉬운 곳에 제공하는 것.
- 나쁜 예:
- 고객센터에 전화해야만 도움을 받을 수 있는 것.
결론: 사용자의 편에서 생각하는 나침반
‘휴리스틱 평가’는 QA나 기획자가 ‘사용성 전문가’의 시각을 빌려, 제품의 불편함을 체계적으로 찾아낼 수 있게 돕는 강력한 도구입니다.
이 10가지 ‘사용성 평가’ 원칙을 체크리스트처럼 활용하면, 실제 사용자를 만나기 전에 수많은 잠재적인 문제점을 미리 발견하고 개선할 수 있습니다. 좋은 QA는 기능적 결함뿐만 아니라, 사용자를 불편하게 만드는 경험적 결함까지 찾아내는 사람입니다.
참고 자료 (References)
- Nielsen Norman Group – 10 Usability Heuristics for User Interface Design:
https://www.nngroup.com/articles/ten-usability-heuristics/