Ⓒsblim, 2010
14. 14. 휴리스틱 평가 휴리스틱 평가
2010 년 2 학기 숙명여자대학교 임순범
1
14.1 휴리스틱 평가 방법의 특징
휴리스틱
그리스어 - “ 발견한다”
시스템 디자인의 결정 / 평가를 할 때 사용하는 일종의 가이드라인
시스템의 사용성 측면에서 어떤 문제가 있는지 ‘ 발견’ 휴리스틱 평가 (Heuristic Evaluation)
닐슨 (Jacob Nielsen) 이 제안 소프트웨어 사용자 인터페이스를 평가 목적으로 개념화시킨 방법
휴리스틱을 사용하여 시스템 인터페이스의 약점이나 문제점 파악
닐슨 이후 여러 종류의 휴리스틱이 다양한 목적을 위해 제시됨Ⓒsblim, 2010
Ⓒsblim, 2010
휴리스틱 평가의 장점
빠른 시간 내에 사용성의 문제점을 광범위하게 발견
여러가지 사용성 문제를 빠른 시간 내 발견하는 것이 목적
학문보다는 개발현장에서 실제 개발과 평가에 도움 시스템의 개발이나 평가를 위해 사용
상호작용 패턴이나 일 , 환경 등의 인간적인 측면의 이해가 아님
시스템 개발 주기 동안 다양한 사용성의 문제를 좀 더 일찍 발견
시스템 디자인 변경에 요구되는 비용이나 시간 절감 비전문가들이 사용하기에도 유용
가이드라인을 통해 사용성을 평가 휴리스틱에 기초해서 직접 시스템의 인터페이스를 평가
사용자 관찰이나 사용성 평가 없이 직접 평가3
휴리스틱 평가의 단점
평가자가 실제 사용자가 아닌 대행자
“ 실제 상황은 시뮬레이션과 다르다 .”
실제 사용자들은 평가자들이 생각하지 못했던 사용성 문제를 제기할 수도 몇 명의 가상 평가자가 사용자를 대표할 수 없음
어느정도 한계 그러나 이러한 단점을 상쇄할 만큼의 가치
Ⓒsblim, 2010
14.2 닐슨의 휴리스틱
닐슨의 휴리스틱 개발
1990 년 몰릭과 함께 개발 (Nielsen and Molich, 1990)
개선된 휴리스틱 집합 제안 (Nielsen, 1994)5
1) 시스템 상태의 시각화
Visibility of system status
시스템은 끊임없이 자신의 상태를 알려주어야 한다 .
인간은 현재 무엇이 진행되는지 알아야 다음 과정을 수행 가능함 반응시간에 따른 주의력 집중
0.1 초 : 특별한 반응 없음
1.0 초 : 데이터 흐름을 놓친다
10 초 : 주의집중에 참는 한계
더 이상 : progress bar 를 이용해야Ⓒsblim, 2010
Ⓒsblim, 2010
2) 시스템 / 실세계 일치
Match between system & real world
시스템은 사용자의 언어로 말해야 한다 .
사용자에게 익숙한 단어 , 문구 , 개념으로 해야 직관적 이해 가능 용어 , 문구 뿐 아니라 아이콘 , 메뉴 , 명령어 , 그룹핑 , 시각화된 형태
잘못된 사례 예전 맥 시스템에서
7
3) 제어의 자유
User control & freedom
인간이 기계를 자유롭게 제어할 수 있어야 한다 . 시스템의 자동 수행보다 , 사용자의 적절한 행동이 필요할 때
전 상태로 돌아갈 수 있는 기능이 제공되어야 함Ⓒsblim, 2010
Ⓒsblim, 2010
4) 일치와 표준
Consistency & Standards
사용자는 서로 다른 용어 , 상황 , 행동들이 같은 것을 의미하고 있는 지 고민하지 않아야 한다 .
다른 시스템에서도 사용하는 GUI 표준을 따르는 것이 중요 깜박임의 시간 간격 , 색상의 수 , 사운드 효과 , 메뉴 선택 명칭과 순서 등 이 산업 표준들과 일치해야 함
9
5) 에러 방지
Error prevention
에러를 어떻게 알리는가의 문제보다는 에러를 미리 방지할 수 있는가 의 문제가 중요 사용자가 심각한 에러를 저지르기 전에 경고
메뉴나 명령어의 용어가 모호하지 않아야 함
Ⓒsblim, 2010
Ⓒsblim, 2010
6) 기억보다 인식
Recognition rather than recall
대상 , 행동 , 옵션을 시각화하는 것은 중요 사람의 인지 능력은 한계가 있으므로 , 직관적으로 인식할 수 있도록
GUI 메뉴들 , 아이콘들은 행위 유발성
활성 / 비활성 , 데이터 강조 / 비강조 , 의미있는 그룹 사이의 경계선11
7) 융통성과 효율성
Flexibility & efficiency of use
초보자와 경험 있는 사용자가 모두 만족할 수 있는 시스템 다양한 계층의 사람들에게 사용성이 제공되는 것이 중요
하나의 명령을 수행하는 방법에도 대체 방법이 필요 메뉴와 단축키 등
Ⓒsblim, 2010
Ⓒsblim, 2010
8) 간소화 된 디자인
Aesthetic & minimalist design
컴퓨터와 대화에서 부적절 , 또는 불필요한 정보는 제외시켜야 불 필요한 정보는 중요한 정보의 시각화를 방해하거나 격감
모든 아이콘이 중복된 느낌 없이 서로 구분 지워질 수 있는지 점검
배경과 분명하게 구분13
9) 에러 인식 , 진단 , 복구
Help users recognize, diagnose, & recover from errors
에러메시지는 자연어로 된 , 사용자에게 익숙한 문장이어야 소스코드에서나 있을 법한 문구나 , 사용자를 질책하는 듯한 표현이 들어 가서는 안됨
문제의 원인을 명시하거나 해결책을 제안할 수 있으면 더욱 좋음Ⓒsblim, 2010
Ⓒsblim, 2010
10) 도움말과 문서화
Help and documentation
복잡성이 증가하는 시스템의 경우 도움말 기능과 문서화를 필수적 필요한지 여부보다 , 얼마나 쉽게 빨리 찾아낼 수 있는지가 중요
기술적 측면보다 사용자의 작업을 염두에 두고 만들어져야 함
분량보다 얼마나 간결하게 사용자를 납득시킬 수 있는가가 중요
15
14.3 휴리스틱 평가 단계
“ 휴리스틱을 어떻게 활용할 것인가 ?”
어떤 일을 수행하게 할 것인가 ?
누구를 평가자로 세울 것인가 ? 몇 명을 선택할 것인가 ?
개별 평가 vs. 그룹 평가 ?
발견 된 사용성의 문제는 무엇이고 , 해결책은 무엇인가 ?Ⓒsblim, 2010
Ⓒsblim, 2010
1) 계획
평가의 계획
평가자에게 제시할 말
“ 여기 닐슨이 제공하는 휴리스틱이 있습니다 . 이것을 잘 검토해보시면서 시스템을 한 번 평가해 주십시오 .”
vs. “ 이 작업을 수행해 보십시오 .”
가장 중요한 작업들이 어떤 것인지 발견하여 테스트해야 성공
평가 시간도 여러 상황을 고려하여 미리 결정
다양한 휴리스틱의 선택 ( 참고 )
닐슨의 휴리스틱
토그나찌니의 인터페이스 디자인을 위한 기본 원칙
프리스의 사용성 평가에 대한 9 가지 체크포인트
반 데르 기스트 , 스피리다키스의 휴리스틱 모음
17
2) 평가자 결정
평가자의 수
평가자가 많을수록 더 많은 사용성의 문제를 발견할 수 있음
효용 대비 비용을 고려할 때 , 적절한 수의 평가자가 필요 효용 / 비용 비율은 5 명 이후 급격히 감소
3~5 명 정도가 적절 (Nielsen & Landauer, 1993)
평가자의 능력
모든 평가자가 사용성 평가의 경험이 풍부한 사람들일 수는 없음 사용성 평가의 전문가도 전문 분야 ( 생물 , 의학 등 ) 의 사용성 평가에는
문제 발견 확률
평가자의 수
5 10
Ⓒsblim, 2010
Ⓒsblim, 2010
3) 실행
2 단계로 진행
브리핑 세션 (briefing session) 평가자에게 무엇을 하는지 말하고 , 시스템 전체와 흐름을 파악하도록
평가실행 : 구체적인 문제에 집중 평가자에게 가이드라인으로 작업 시나리오 제공
바로 실행 가능한 시스템 혹은 익숙한 시스템은 가이드 필요 없음
평가 방식
개별 평가 : 각 개인의 평가자가 각각 사용성을 평가하고 정리 그룹 평가 대비 더 많은 사용성 문제 발견에 유리 , but 시간 많이 소요
그룹 평가 : 하나의 팀으로 구성 모든 팀원이 동의할 필요 없지만 , 발견 / 논의된 문제는 기획자에게 보고
개별 평가에 비해 계획에 더 많은 시간이 필요
19
평가자는 문제점 목록 작성
각 문제점을 구체적이고 개별적으로 기록 어느 휴리스틱에 저촉되는지 명기
가능하다면 해결책도 제시 ( 모든 문제에 대해서는 아님 )
예 ) 문제점 1 xxx 화면에 나오는 3 개의 대화창에 각기 다른 서체 사용
(H4) Consistency & Standard 휴리스틱에 저촉
해결책 : 전체 인터페이스에서 대화창에 일관된 포맷 사용
문제가 자주 발생하는 곳 UI 에서 어는 한 지점 , 또는 비교되는 2 군데 이상 지점
UI 의 전체 구성 / 구조에 대한 문제
Ⓒsblim, 2010
Ⓒsblim, 2010
4) 결과 분석
분석기법 – Severity Rating ( 심각도 / 중요도 점수 )
문제해결을 위한 자원배분 목적
사용성 개선에 필요한 노력을 예측 빈도 (frequency), 영향력 (impact), 지속성 (persistence) 등을 분석
휴리스틱 평가 종료 후 모든 문제점에 독립적으로 점수부여
점수 배점 예 0 : 문제 아님 (don’t agree to be a usability problem)
1 : 단순 외형적 문제 (cosmetic problem)
2 : 사소한 사용성 문제 (minor usability problem)
3 : 중요한 사용성 문제 , 가급적 수정 필요 (major usability problem)
4 : 심각한 사용성 침해 , 반드시 수정 필요 (usability catastrophe)
21
디브리핑 세션 (debriefing session)
평가 결과에 대한 분석 단계
진행 단계1. 중복된 평가는 줄이고 , 비슷한 주제들을 같은 부류로 묶는다 .
2. 문제 혹은 주제에 대한 우선순위를 정한다 .
3. 발견된 문제에 대해서 가능한 해결책을 제시한다 .
4. 개발팀은 수정 (fix) 난이도를 배점한다 .
예 ) [H4 Consistency] [Severity 3] [Fix 1] or [H4 일관성 ] [ 중요도 3] [ 난이도 1]
주의사항 평가자들이 함께 모여서 결과에 대해 의논할 수 있으면 매우 좋음
Ⓒsblim, 2010
Ⓒsblim, 2010
휴리스틱 평가에 대한 결론
휴리스틱 vs. 사용성 평가
빠르다 vs. 정확하다
휴리스틱 평가와 사용성 평가 병행이 바람직 비용 대비 효과가 뛰어나다
Nielsen 의 연구에 의하면 $10 만불 비용 지출에 $50 만불 효과 가 능
적용 대상 : 내부적으로는 생산성 증가 , 외부적으로는 매출 상승 평가자 인원 대비 효과
1 명 : 35% 문제점 검출
5 명 : 75% 문제점 검출23
problems found benefits / cost
