Heuristic Evaluation

좋은 디자인? or 나쁜 디자인?

• 사용자에게 정말로 삭제할지 여부를 묻는 다이얼로그 • 문제점?

– 컬러 사용의 문제 • Yes(녹색), No(붉은색) – 색상 선택의 문화적 부적합 • 보통 녹색을 좋은 의미로, 붉은 색을 나쁜 의미로 사용하지만, 중국이나 다른 문화의 경우 붉 은색이 좋은 의미로 받아들여질 수도 있다.

HE: Heuristic Evaluation

목차

• 휴리스틱 평가법의 대략보기 • 휴리스틱 • 휴리스틱 평가법 수행 방법 • 휴리스틱 평가 vs. 사용성 테스트

휴리스틱 평가방법

• Jakob Nielsen에 의해 개발됨 • UI 디자인에서의 사용성에 관한 문제점을 찾는데 도움을 준다.

• 적은 수의 평가원들이 UI를 평가한다.

– 각 평가원들은 독립적으로 사용성 이론( “ 휴리스틱”에 따라 평가한다.

– 평가원은 평가가 끝나고 난 후에만 제품에 관해 말할 수 있다.

• 사용되는 UI나 스케치 모두에 적용 가능하다.

왜 여러명의 평가원을 쓰나?

• 한 평가원이 모 든 문제를 찾을 수는 없다.

• 좋은 평가원은 쉽고 어려운 것 을 모두 찾을 수 있는 사람이다.

휴리스틱 평가 과정

• 평가원들은 UI를 여러 번 수행한다.

– 다이얼로그의 다양한 요소들을 꼼꼼히 조사한다.

– 사용성 이론의 요소 리스트들과 비교한다.

– 떠오르는 다른 이론이나 결과 등을 고려한다.

• 사용성 이론 – Nielsen의 “휴리스틱” – 카테고리-specific 휴리스틱의 추가적인 리스트 • 다른 분석이나 기존 존재하는 사용자 테스팅 • 문제점을 고치거나 다시 디자인하기 위하여 지 적받은 점들을 참고한다.

휴리스틱 (by Nielsen)

• H1-1: 간단하고 자연 스러운 다이얼로그인 가?

• H1-2: 사용자의 언어 로 말하는가?

• H1-3: 사용자의 기억 력을 적게 요구하는가?

• H1-4: 일관성 • H1-5: 사용자 입력에 대한 반응/피드백 • H1-6: 종료 버튼이 명 확한가?

• H1-7: 단축버튼이나 단축키 • H1-8: 정확하고 건설 적인 에러 메시지 • H1-9: 에러를 방지한 다 • H1-10: 도움말과 관 련 문서

휴리스틱 (by Nielsen)

H1-1.

시스템 상태의 시각화 H1-10.

도움말과 문서화 H1-2.

시스템/실세계의 일치 H1-9.

에러 인식, 진단, 복구 H1-3.

제어의 자유 닐슨의 10계명 H1-8.

심미적이고 간소화된 디자인 H1-4.

일치와 표준 H1-7.

유연성과 효율성 H1-5.

에러 방지 H1-6.

기억보다 인식

휴리스틱 (by Landay)

searching database for matches • H2-1: 시스템 상태의 가시성 – 사용자에게 무엇이 진행 중인지 알려줌 – 예: 응답 시간에 따른 집중도 • 0.1 초: 특별한 지시자가 필요 없다. 왜?

• 1.0 초: 사용자는 데이터 … ..

• 10 초: 사용자가 기다릴 수 있는 최대 시간 • 더 길어지면, 퍼센트를 보여주는 지시 바를 사용하 라

휴리스틱

• 나쁜 예: Mac 데스크탑 – 디스크를 휴지통에 끌어다 놓 음 • H2-2: 시스템과 실세계 간 의 연결 – 사용자의 언어로 말하라 – 실세계의 전통을 따르라

휴리스틱

• H2-3: 사용자 작업의 전문 성과 자유도 – 잘못된 선택에 종료 또는 undo와 redo – 고정된 방법만을 강요하지 말 라 • 마법사 – 다음으로 진행하기 전에 질문에 답해야 만 한다.

– 자주 사용하지 않는 작업에 적합 • 예: 모뎀 설정 – 일상적인 작업에는 적합하지 않음 – 초보자에게 좋다.

• 초보자와 전문가용 두 버전 존재 (winzip) • BART 처럼 …

휴리스틱

휴리스틱

• MS Web Publishing Wizard • 다이얼링 전에 – ID와 비밀번호를 물어봄 • 연결되었을 경우 – ID와 비밀번호를 다시 물어봄 • H2-5: 에러 방지 • H2-6: 재호출 보다는 재인지 – 객체, 행위, 옵션, 방향 등을 사 용자에게 쉽게 보이거나 쉽게 재 사용 가능하도록 한다.

휴리스틱

• H2-7: 사용의 유연성과 효율성 – 전문가에게는 더욱 빠른 사용을 가능하게 함 (예: 제스 쳐, 키보드 단축키) – 사용자에게 자주 사용되는 행위에 대해서 적합한 입력 방식을 제공 (예: 매크로, 상용구 등)

휴리스틱

• H2-8: 심미적이고, 단순한 디자인 – 다이얼로그에서 부적절한 정보를 제거하라

휴리스틱

• H2-9: 사용자에게 에러에 대하여 인지 하거나, 분석하거나, 이를 수정할 수 있 도록 하라. – 에러 메시지는 평문 형태가 좋다. – 정확하게 문제에 대하여 지적하라. – 건설적인 해결책을 제시하라.

휴리스틱

• H2-10: 도움말과 관련 문서 – 찾기 쉬워야 함.

– 사용자의 작업 중심의 문서 – 수행되는 구체적인 순서에 대하여 기술하라 – 너무 방대하지 않아야 한다.

휴리스틱 평가의 순서

1. 평가전 훈련 평가원들에게 필요한 사전 지식을 알려주고, 평가 시나 리오에 대해 설명한다.

2. 평가 각 평가원은 UI를 평가하고, 문제점 리스트를 만든다.

3. 문제점 평가 각 항목이 얼마나 중대하게 문제가 있는지 평가한다.

4. 통합 평가된 문제점과 그에 대한 중대성을 통합한다.

5. 결과 보고 결과를 디자인팀과 상의한다.

어떻게 평가를 수행할 것인가?

• 각 평가원당 최소한 두 번씩의 평가를 수행한다.

– 처음에는 전체 흐름과 시스템의 영역에 익숙하도록 인지 – 두 번째에는 각 세부 요소에 대해 초점을 맞춘다. • 만약 시스템이 walk-up-and-use거나 평가원들 이 전문가라면 평가도우미가 필요 없을 것이다.

– 그렇지 않다면 각 시나리오마다 평가 도우미들을 제 시하는 것이 좋다.

• 각 평가원들은 문제점 리스트를 만든다.

– 각 문제점을 휴리스틱이나 다른 정보에 근거해 이유 를 설명한다.

– 각 문제점을 세부적으로 설명한다.

예제

• “ 정보를 한 윈도우에서 다른 곳으로 복사할 수가 없어요” – 『제어의 자유』 (H1-3) 위반 – 수정: 복사 허용 • “3개의 다이얼로그에서 서로 다른 폰트를 사용 해요” – 『일치와 표준』(H2-4) 위반 – 수정: 전체 인터페이스에 하나의 단일한 포맷을 적용

어떻게 휴리스틱 평가를 할 것인가?

• 왜 각 위반 사항을 구분하는가?

– 문제점을 반복하는 위험risk of repeating problematic aspect – may not be possible to fix all problems • Where problems may be found – single location in UI – two or more locations that need to be compared – problem with overall structure of UI – something that is missing • common problem with paper prototypes • note: sometimes features are implied by design docs and just haven ’ t been “ implemented ” – relax on those

심각도 평가 (Severity Rating)

• 문제를 해결하기 위하여 필요한 자원을 할당하 기 위하여 사용된다.

• 얼마나 더 많은 노력 (사용성에 관한 노력)이 필 요한가에 대한 추정 • 다음의 요소들의 조합을 이루어진다.

– 빈도수 – 중요도 – 지속성 (반복 or 한번) • 모든 평가마다 시행되어야 한다.

• 모든 다른 평가와 독립적으로 이루어져야한다.

심각도 평가 (Severity Rating)

0 – 1 – 2 – 큰 문제 없음 가식적인 문제는 거의 없음 작은 사용성 문제 3 – 큰 사용성 문제; 반드시 고쳐야 함 4 – 사용성 재난(catastrophe); 긴급히 고쳐 야함

요약

• 평가자, 관찰자, 개발팀 멤버 등을 안내한 다.

• UI의 일반적인 특성에 대해 논의한다.

• 심각한 사용성 문제에 접근하기 위하여 가 능한 접근을 제시한다.

• 개발팀은 그것이 얼마나 고치기 어려운가 를 평가한다.

• Make it a brainstorming session – little criticism until end of session

심각도 평가 예

1. [H1-4 일치] [심각성 3][수정 0] 이 인터페이스에서 첫 화면에서는 “저장” 을 사용자의 파일에 저장하기 위하여 사용 하였으나, 다른 화면에서는 “파일에 쓰기” 를 그러한 용도로 사용하였다. 사용자는 이렇게 같은 역할을 하는 상이한 용어에 의해 혼란스러울 수 있다.

휴리스틱 평가 vs. 사용자 테스트

• 휴리스틱 평가가 훨씬 빠름 – 각 평가원마다 1~2시간 vs. 수 일~수 개월 • 휴리스틱 평가는 사용자의 움직임을 번역할 필 요가 없음.

• 사용자 테스트가 훨씬 정확 (정의에 의해) – 실제 사용자와 그들의 작업에 의해 이루어지므로 – 휴리스틱 평가의 경우 문제점을 놓치거나 잘못된 문 제점을 찾을 가능성도 있다.

• 휴리스틱 평가와 사용자 테스트 사이의 적당한 절충안을 찾을 필요가 있다.

– 각기 다른 문제점들을 찾으라. – 참가자들의 시간을 허비하지 말라.

휴리스틱 평가의 장점

• 자원 절약: 비용 대비 이익 비율이 48 정도 증가 [Nielsen94] – 이익 $500,000 마다 비용이 $10,500 – 각 문제당 가치는 약 $15,000까지 계산됨 (Nielsen & Landauer) – 이 가치를 어떻게 계산할까?

• in-house -> 생산성; open market -> 매출 • 심각도와 휴리스틱 평가로 찾은 문제 사이에는 상관관계 존재 • 단일 평가원은 안 좋은 결과를 찾음 – 약 35% 정도의 사용성 문제만을 발견 – 5명의 평가원은 약 75% 까지의 문제점을 발견함 – 더 많은 평가원은?

• 평가원을 더하면 비용이 크게 증가하나 그에 반해 더 많은 문제점을 발견하지 못할수도 있음

이익의 감소

problems found benefits / cost

요약

• 평가원들에게 UI를 두 번씩 평가하게 한다.

• 그들에게 휴리스틱에 근거하여 평가하도록 한다.

– 휴리스틱에 어긋난다면 왜 그런지 이유를 묻는다.

• 3~5명 정도의 평가원이 적당하다.

• 평가시에는 각 평가원들은 독립적으로 평가하도 록 한다.

• 이를 이용하여 사용자 테스트를 대신할 수 있다.

읽을 꺼리

•

Usability Engineering

, by Nielsen, 1994 • Useit.com