Heuristic Evaluation

좋은 디자인? or 나쁜 디자인? 사용자에게 정말로 삭제할지 여부를 묻는 다이얼로그 문제점? 컬러 사용의 문제 Yes(녹색), No(붉은색) 색상 선택의 문화적 부적합 보통 녹색을 좋은 의미로, 붉은 색을 나쁜 의미로 사용하지만, 중국이나 다른 문화의 경우 붉은색이 좋은 의미로 받아들여질 수도 있다.

HE: Heuristic Evaluation

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

휴리스틱 평가방법 Jakob Nielsen에 의해 개발됨 UI 디자인에서의 사용성에 관한 문제점을 찾는데 도움을 준다. 각 평가원들은 독립적으로 사용성 이론(“휴리스틱”에 따라 평가한다. 평가원은 평가가 끝나고 난 후에만 제품에 관해 말할 수 있다. 사용되는 UI나 스케치 모두에 적용 가능하다.

왜 여러명의 평가원을 쓰나? 한 평가원이 모든 문제를 찾을 수는 없다. 좋은 평가원은 쉽고 어려운 것을 모두 찾을 수 있는 사람이다.

휴리스틱 평가 과정 평가원들은 UI를 여러 번 수행한다. 사용성 이론 다이얼로그의 다양한 요소들을 꼼꼼히 조사한다. 사용성 이론의 요소 리스트들과 비교한다. 떠오르는 다른 이론이나 결과 등을 고려한다. 사용성 이론 Nielsen의 “휴리스틱” 카테고리-specific 휴리스틱의 추가적인 리스트 다른 분석이나 기존 존재하는 사용자 테스팅 문제점을 고치거나 다시 디자인하기 위하여 지적받은 점들을 참고한다. 변경!

휴리스틱 (by Nielsen) H1-1: 간단하고 자연스러운 다이얼로그인가? H1-2: 사용자의 언어로 말하는가?

휴리스틱 (by Nielsen) 닐슨의 10계명 H1-1. 시스템 상태의 시각화 H1-10. 도움말과 문서화 H1-2. 시스템/실세계의 일치 H1-9. 에러 인식, 진단, 복구 닐슨의 10계명 H1-3. 제어의 자유 H1-8. 심미적이고 간소화된 디자인 H1-4. 일치와 표준 H1-7. 유연성과 효율성 H1-5. 에러 방지 H1-6. 기억보다 인식

휴리스틱 (by Landay) H2-1: 시스템 상태의 가시성 사용자에게 무엇이 진행 중인지 알려줌 searching database for matches H2-1: 시스템 상태의 가시성 사용자에게 무엇이 진행 중인지 알려줌 예: 응답 시간에 따른 집중도 0.1 초: 특별한 지시자가 필요 없다. 왜? 1.0 초: 사용자는 데이터….. 10 초: 사용자가 기다릴 수 있는 최대 시간 더 길어지면, 퍼센트를 보여주는 지시 바를 사용하라 수정 필요

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

휴리스틱 마법사 H2-3: 사용자 작업의 전문성과 자유도 다음으로 진행하기 전에 질문에 답해야만 한다. 자주 사용하지 않는 작업에 적합 예: 모뎀 설정 일상적인 작업에는 적합하지 않음 초보자에게 좋다. 초보자와 전문가용 두 버전 존재 (winzip) H2-3: 사용자 작업의 전문성과 자유도 잘못된 선택에 종료 또는 undo와 redo 고정된 방법만을 강요하지 말라 BART 처럼… H2-3 수정 필요

휴리스틱

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

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

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

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

휴리스틱 H2-10: 도움말과 관련 문서 찾기 쉬워야 함. 사용자의 작업 중심의 문서 수행되는 구체적인 순서에 대하여 기술하라 너무 방대하지 않아야 한다.

휴리스틱 평가의 순서 평가전 훈련 평가 문제점 평가 통합 결과 보고 평가원들에게 필요한 사전 지식을 알려주고, 평가 시나리오에 대해 설명한다. 평가 각 평가원은 UI를 평가하고, 문제점 리스트를 만든다. 문제점 평가 각 항목이 얼마나 중대하게 문제가 있는지 평가한다. 통합 평가된 문제점과 그에 대한 중대성을 통합한다. 결과 보고 결과를 디자인팀과 상의한다.

어떻게 평가를 수행할 것인가? 각 평가원당 최소한 두 번씩의 평가를 수행한다. 처음에는 전체 흐름과 시스템의 영역에 익숙하도록 인지 두 번째에는 각 세부 요소에 대해 초점을 맞춘다. 만약 시스템이 walk-up-and-use거나 평가원들이 전문가라면 평가도우미가 필요 없을 것이다. 그렇지 않다면 각 시나리오마다 평가 도우미들을 제시하는 것이 좋다. 각 평가원들은 문제점 리스트를 만든다. 각 문제점을 휴리스틱이나 다른 정보에 근거해 이유를 설명한다. 각 문제점을 세부적으로 설명한다. Walk-up-and-use가 뭐여?

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

어떻게 휴리스틱 평가를 할 것인가? 왜 각 위반 사항을 구분하는가? Where problems may be found 문제점을 반복하는 위험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. 사용자 테스트 휴리스틱 평가가 훨씬 빠름 휴리스틱 평가는 사용자의 움직임을 번역할 필요가 없음. 사용자 테스트가 훨씬 정확 (정의에 의해) 실제 사용자와 그들의 작업에 의해 이루어지므로 휴리스틱 평가의 경우 문제점을 놓치거나 잘못된 문제점을 찾을 가능성도 있다. 휴리스틱 평가와 사용자 테스트 사이의 적당한 절충안을 찾을 필요가 있다. 각기 다른 문제점들을 찾으라. 참가자들의 시간을 허비하지 말라. 2번째 문장 수정요 HE doesn’t require interpreting user’s actions 마지막 두 문장 find different problems don’t waste participants

휴리스틱 평가의 장점 자원 절약: 비용 대비 이익 비율이 48 정도 증가[Nielsen94] 이익 $500,000 마다 비용이 $10,500 각 문제당 가치는 약 $15,000까지 계산됨 (Nielsen & Landauer) 이 가치를 어떻게 계산할까? in-house -> 생산성; open market -> 매출 심각도와 휴리스틱 평가로 찾은 문제 사이에는 상관관계 존재 단일 평가원은 안 좋은 결과를 찾음 약 35% 정도의 사용성 문제만을 발견 5명의 평가원은 약 75% 까지의 문제점을 발견함 더 많은 평가원은? 평가원을 더하면 비용이 크게 증가하나 그에 반해 더 많은 문제점을 발견하지 못할수도 있음 In house와 open market을 어찌할까?

이익의 감소 problems found benefits / cost

요약 평가원들에게 UI를 두 번씩 평가하게 한다. 그들에게 휴리스틱에 근거하여 평가하도록 한다. 휴리스틱에 어긋난다면 왜 그런지 이유를 묻는다. 3~5명 정도의 평가원이 적당하다. 평가시에는 각 평가원들은 독립적으로 평가하도록 한다. 이를 이용하여 사용자 테스트를 대신할 수 있다.

읽을 꺼리 Usability Engineering, by Nielsen, 1994 Useit.com