휴리스틱 평가 체크리스트: 닐슨의 10원칙과 화면 평가 예시

휴리스틱 평가는 화면을 사용성 원칙에 비춰 살펴보고, 사용자가 막힐 만한 지점을 찾아 기록하는 방법이다. 실제 사용자를 모집하기 전에도 진행할 수 있어 초기 검토에 유용하다. 다만 평가자의 판단으로 문제 가능성을 찾는 방식이므로 사용성 테스트를 대신하지는 않는다. 사용자가 실제로 어디서 망설이고 어떤 표현을 이해하는지는 직접 관찰해야 알 수 있다.

 

사용성 테스트가 참여자에게 과제를 주고 행동을 관찰하는 조사라면, 휴리스틱 평가는 평가자가 정해진 기준으로 인터페이스를 검사하는 점이 다르다. 둘은 서로 보완할 수 있다. 아래 체크리스트의 원칙 이름은 닐슨 노먼 그룹(NN/g)의 표현을 옮겼고, 각 질문은 초심자가 화면을 살펴보도록 이 글에서 재구성했다.

 

닐슨의 10원칙 체크리스트

1. 시스템 상태의 가시성

Visibility of System Status

확인 질문: 저장·전송·처리 중인지, 완료됐는지 적절한 때에 알 수 있는가?

2. 시스템과 현실 세계의 일치

Match Between the System and the Real World

확인 질문: 메뉴와 안내가 사용자의 익숙한 말과 자연스러운 순서를 따르는가?

3. 사용자 제어와 자유

User Control and Freedom

확인 질문: 잘못 들어온 단계에서 취소·뒤로 가기·되돌리기를 쉽게 할 수 있는가?

4. 일관성과 표준

Consistency and Standards

확인 질문: 같은 기능이 화면마다 같은 이름과 방식으로 동작하는가? 익숙한 플랫폼 관례를 따르는가?

5. 오류 예방

Error Prevention

확인 질문: 실수하기 쉬운 입력이나 되돌리기 어려운 행동을 미리 막거나 확인하게 하는가?

6. 기억보다 인식

Recognition Rather than Recall

확인 질문: 다음 행동에 필요한 선택지와 정보가 화면에 보이거나 쉽게 다시 확인되는가?

7. 유연성과 효율성

Flexibility and Efficiency of Use

확인 질문: 초심자는 쉽게 배우고, 자주 쓰는 사람은 반복 작업을 효율적으로 할 방법이 있는가?

8. 미적이고 간결한 디자인

Aesthetic and Minimalist Design

확인 질문: 핵심 과제와 관계없는 정보가 중요한 정보의 주의를 빼앗지 않는가?

9. 오류를 인식·진단·복구하도록 돕기

Help Users Recognize, Diagnose, and Recover from Errors

확인 질문: 오류가 무슨 문제인지 쉬운 말로 알려주고 해결 방법을 제시하는가?

10. 도움말과 문서

Help and Documentation

확인 질문: 스스로 해결하기 어려울 때 관련 도움말을 찾고 구체적인 안내를 받을 수 있는가?

 

모든 화면에 열 가지 원칙을 기계적으로 적용할 필요는 없다. 한 원칙과 맞지 않아 보이는 디자인도 화면 크기나 과제 맥락에 따라 합리적일 수 있다. 먼저 사용자가 하려는 일을 정하고, 그 과정에서 실제로 방해가 되는지 살펴보자.

 

직접 평가하는 네 단계

1. 범위를 정한다. 예를 들어 “모바일에서 처음 방문한 사람이 이메일로 서비스에 가입한다”처럼 사용자, 과제, 기기를 좁힌다. 범위가 작을수록 관찰을 구체적으로 적기 쉽다.
2. 흐름을 한 번 익힌다. 평가하려는 과제를 실제로 따라가며 화면과 단계의 순서를 파악한다. 이 첫 회차에는 문제를 찾으려 애쓰기보다 흐름을 이해한다.
3. 다시 진행하며 관찰한다. 두 번째 회차에는 각 화면에서 원칙에 어긋나 보이는 요소와 그때 사용자가 겪을 수 있는 영향을 기록한다. 문제마다 한 항목씩 적고, 화면이나 단계 위치도 남긴다.
4. 중복을 묶고 우선순위를 정한다. 여러 평가자(권장 3~5명)는 먼저 각자 살핀 뒤 기록을 모아 비슷한 문제를 합친다. 빈도·영향·지속성을 따져 먼저 확인하거나 고칠 항목을 정한다. 의견이 갈리거나 영향이 불확실하면 사용성 테스트에서 확인할 질문으로 남긴다.

 

가상 이메일 가입 화면 예시

다음은 평가 방법을 설명하기 위해 만든 가상의 서비스와 화면이다. 실제 제품이나 사용자 조사 결과가 아니다. 과제는 “처음 방문한 사용자가 이메일로 계정을 만든다”라고 가정한다.

 

예시 1. 시스템 상태의 가시성

• 관찰한 사실: 가입 버튼을 누른 뒤 화면 변화나 처리 안내가 보이지 않는다.
• 예상 영향: 요청이 접수됐는지 몰라 버튼을 다시 누를 수 있다.
• 개선안: 버튼 진행 상태와 완료 메시지를 표시한다.
• 가정 및 추가 검증: 서버 응답 중에도 안내가 없는지 확인한다. 실제 재시도 빈도는 측정하지 않았다.

예시 2. 오류를 인식·진단·복구하도록 돕기

• 관찰한 사실: 이미 가입된 이메일을 입력해도 “오류”라는 문구만 보인다.
• 예상 영향: 사용자는 원인과 다음 행동을 알아내기 어렵다.
• 개선안: 계정 확인 또는 로그인으로 이어지는 안내를 제공한다.
• 가정 및 추가 검증: 계정 존재 여부 공개가 정책상 허용되는지 제품·보안 담당자와 확인한다.

예시 3. 기억보다 인식

• 관찰한 사실: 비밀번호 조건이 입력란과 떨어진 도움말에만 적혀 있다.
• 예상 영향: 조건을 기억해 입력해야 해 오류와 재입력이 생길 수 있다.
• 개선안: 입력란 가까이에 조건을 보여주고 입력 중 충족 여부를 알려준다.
• 가정 및 추가 검증: 모바일에서도 안내가 보이는지, 실제로 조건을 놓치는지 테스트한다.

 

문제는 “가입이 불편하다”처럼 평가자의 결론만 적기보다, 확인한 화면 상태와 그로부터 예상한 영향을 나눠 기록한다. 그래야 사실과 해석을 구별하고 개선안이 적절한지 다시 검토할 수 있다.

 

심각도는 우선순위 논의에만 쓴다

NN/g가 제시하는 0~4점 척도는 문제의 빈도, 발생했을 때의 영향, 문제가 지속되거나 반복되는 정도를 함께 고려한다. 아래 점수는 평가팀이 판단을 맞춰보기 위한 추정치다. 사용자 실측 결과나 객관적인 UX 품질 점수가 아니다.

 

• 0점: 사용성 문제라는 판단에 동의하지 않음
• 1점: 외관상 문제에 가까워 여유가 있을 때 수정
• 2점: 경미한 사용성 문제로 낮은 우선순위
• 3점: 주요 사용성 문제로 높은 우선순위
• 4점: 사용을 막는 심각한 문제로 출시 전 해결이 필요하다고 판단

 

한 사람이 준 점수를 확정적인 결론처럼 다루지 말자. 팀에서는 각자 판단한 이유를 함께 적고, 점수가 높거나 의견 차이가 큰 문제부터 재현하거나 실제 사용자에게 확인한다. 체크된 원칙의 개수를 합쳐 화면 점수를 만들면 안 된다. 원칙 위반처럼 보여도 맥락상 문제가 아닐 수 있고, 체크 수는 사용자가 겪는 영향의 크기를 나타내지 않는다.

 

복사해 쓰는 기록 양식

평가 범위
제품/화면:
사용자와 과제:
기기:
평가 날짜:

문제 기록 (문제 하나당 한 항목)
위치 또는 단계:
관련 원칙:
관찰한 사실:
예상 영향:
개선안:
가정 및 추가 검증:
심각도 (0~4)와 판단 이유:

휴리스틱 평가는 짧은 시간에 잠재적인 문제를 발견하고 다음 조사 질문을 만드는 데 쓸 수 있다. 그러나 평가자의 예상만으로 실제 사용자의 행동이나 성과를 단정할 수는 없다. 기록을 고칠 순서를 정하는 출발점으로 삼고, 중요한 판단은 사용성 테스트나 다른 사용자 조사로 확인하자.

 

참고 자료

• 10 Usability Heuristics for User Interface Design — NN/g
• How to Conduct a Heuristic Evaluation — NN/g
• Severity Ratings for Usability Problems — NN/g