230305 How to Conduct a Heuristic Evaluation (휴리스틱 평가 수행하는 법 from NN group) 上

 안녕하세요 갓생도전입니다. 예전부터 해보고 싶었던 해외아티클 번역을 오늘부터 야금야금 진행해보려합니다!!!! 야호 일벌리기 제일 좋아

아무래도 공부하는 분야가 IT 서비스 쪽이다 보니 해외에서 발행한 글들을 훑어볼 일이 많은데요, 그 중에서 함께 공유하면 좋을 것 같은 글들을 언어 공부도 할 겸 번역해보려고 합니다. 전문가가 아닌만큼 번역 과정에서 매끄럽지 못 한 부분이나 오역이 있을 수 있음을 미리 고지드립니다. 또한 틀린 부분은 댓글 남겨주시면 수정하도록 하겠습니다! 많이 많이 지적해주세용

 

 오늘 번역할 글은 휴리스틱 평가에 관한 아티클인데요, 2월 28일 개인 실습 때 관련 자료를 검색해보다 발견한 글을 가져와봤습니다. UI/UX 컨설팅 분야의 세계적인 회사인 Nielsen Norman 그룹에서 발행한 글인데요, 원글은 여기를 클릭하시면 확인하실 수 있습니다. :)

 

또 저의 실습 내용이 궁금하시다면 아래 포스팅을 클릭해주세요!

2023.02.28 - [개인프로젝트/과제] - 230228 "tistory" 서비스를 휴리스틱 평가로 살펴보기

230228 "tistory" 서비스를 휴리스틱 평가로 살펴보기

 

각설하고 번역을 시작하겠습니닷

---

휴리스틱 평가 수행 방법 How to Conduct a Heuristic Evaluation

Summary: Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the "heuristics").

By Jakob Nielsen on November 1, 1994
Topics: Heuristic Evaluation

요약: 휴리스틱 평가는 소규모의 평가자들이 인터페이스(UI)를 검사하고, "휴리스틱"으로 일컬어지는 인식된 사용성 원칙을 준수하는지를 평가하는 것을 포함한다.

 

compliance 응낙, 규정준수

 

Heuristic evaluation  (Nielsen and Molich, 1990; Nielsen 1994) is a usability engineering method for finding the usability problems in a user interface design so that they can be attended to as part of an iterative design process. Heuristic evaluation involves having a small set of evaluators examine the interface and judge its compliance with recognized usability principles (the "heuristics").

 휴리스틱 평가(닐슨과 몰리치, 1990; 닐슨, 1994)는 유저 인터페이스 디자인에서 발생하는 사용성 문제를 발견하여 반복적 설계 프로세스의 부분으로서 존재할 수 있도록하는 사용성 공학 기법이다. 휴리스틱 평가는 소규모의 평가자들이 인터페이스(UI)를 검사하고, "휴리스틱"으로 일컬어지는 인식된 사용성 원칙을 준수하는지를 평가하는 것을 포함한다.

 

iterative 반복적인

In general, heuristic evaluation is difficult for a single individual to do because one person will never be able to find all the usability problems in an interface. Luckily, experience from many different projects has shown that different people find different usability problems. Therefore, it is possible to improve the effectiveness of the method significantly by involving multiple evaluators.
 Figure 1 shows an example from a case study of heuristic evaluation where 19 evaluators were used to find 16 usability problems in a voice response system allowing customers access to their bank accounts (Nielsen 1992). Each of the black squares in Figure 1 indicates the finding of one of the usability problems by one of the evaluators. The figure clearly shows that there is a substantial amount of nonoverlap between the sets of usability problems found by different evaluators. It is certainly true that some usability problems are so easy to find that they are found by almost everybody, but there are also some problems that are found by very few evaluators. Furthermore, one cannot just identify the best evaluator and rely solely on that person's findings. First, it is not necessarily true that the same person will be the best evaluator every time. Second, some of the hardest-to-find usability problems (represented by the leftmost columns in Figure 1) are found by evaluators who do not otherwise find many usability problems. Therefore, it is necessary to involve multiple evaluators in any heuristic evaluation (see below for a discussion of the best number of evaluators). My recommendation is normally to use three to five evaluators since one does not gain that much additional information by using larger numbers.

 일반적으로, 휴리스틱 평가는 개인이 수행하기엔 어렵다. 한 명의 사람이 인터페이스 내의 모든 사용성 문제를 파악하기란 불가능할 것이기 때문이다. 다행인 점은, 많은 다른 프로젝트로부터 얻은 경험은 각기 다른 사람들은 각기 다른 사용성 문제를 찾는다는 것을 보여줘왔다는 것이다. 그러므로, 복수의 평가자를 포함시킴으로써 휴리스틱 평가의 효율성을 상당히 개선시킬 수 있다.

 그림1은 19명의 평가자가 고객이 그들의 은행계좌로 액세스할 수 있게 하는 음성 응답 시스템에서 16가지 사용성 문제를 발견한 휴리스틱 평가의 사례 분석 예시이다(닐슨, 1992). 그림 1에서의 각각의 검은 사각형은 평가자들 중 한 명이 발견한 사용성 문제들 중 한 가지를 나타낸다. 이 그림은 각기 다른 평가자가 찾은 사용성 문제 세트 간 겹치는 부분이 상당히 적다는 것을 분명히 보여주고 있다. 몇 가지 사용성 문제는 거의 모든 평가자가 찾아낼 만큼 발견하기 쉽다는 것은 분명한 사실이나, 아주 소수의 평가자들만 찾아낸 몇가지 문제들 또한 있다.

 게다가, one은 단지 가장 뛰어난 평가자를 식별할 수 없고 그 사람이 찾아낸 것에만 단독으로 의존할 수 없다.  (*one이 어떤 의미로 쓰였는지 모르겠음) 우선, 매번 같은 사람이 최고의 평가자가 된다는 것은 반드시 참이지 않다. 다음으로, '가장 찾기 힘든 사용성 문제'들 중 몇 가지는 (그림1에서 가장 왼쪽 열에 표시된) 오히려 많은 사용성 문제들을 찾아내지 못한 평가자들이 발견했다. 그러므로, 어떤 휴리스틱 평가든 복수의 평가자가 참여하는 것이 필요하다(최상의 평가자 수에 관하 논의를 아래에서 보아라). 나는 3명에서 5명의 평가자를 추천하는데, 더 많은 평가자가 참여해도 그다지 추가적인 정보를 얻을 수 없기 때문이다.

 

significantly 상당히

substantial 실질적인, 상당한, 중요한, 본질적인

 

그림 1 평가자들이 은행 시스템의 휴리스틱 평가에서 찾은 사용성 문제를 보여주는 그림. 각 행은 19명의 평가자들을 의미하며, 각 열은 16가지 사용성 문제들을 의미한다. 각 사각형들은 평가자가 사용성 문제를 찾아냈는지 여부를 나타내는데, 검은색이면 평가자가 문제를 발견한 것이고, 흰색이면 그렇지 않은 것이다. 세로축은 가장 많이 성공한 평가자가 아래에, 가장 적게 발견한 평가자가 위에 있는 방식으로 분류되었다.가로축은 가장 쉽게(많이) 찾아진 사용성 문제가 오른쪽에, 가장 어렵게(적게) 찾아진 문제가 왼쪽에 배치되었다.

 Heuristic evaluation is performed by having each individual evaluator inspect the interface alone. Only after all evaluations have been completed are the evaluators allowed to communicate and have their findings aggregated. This procedure is important in order to ensure independent and unbiased evaluations from each evaluator. The results of the evaluation can be recorded either as written reports from each evaluator or by having the evaluators verbalize their comments to an observer as they go through the interface. Written reports have the advantage of presenting a formal record of the evaluation, but require an additional effort by the evaluators and the need to be read and aggregated by an evaluation manager. Using an observer adds to the overhead of each evaluation session, but reduces the workload on the evaluators. Also, the results of the evaluation are available fairly soon after the last evaluation session since the observer only needs to understand and organize one set of personal notes, not a set of reports written by others. Furthermore, the observer can assist the evaluators in operating the interface in case of problems, such as an unstable prototype, and help if the evaluators have limited domain expertise and need to have certain aspects of the interface explained.

 휴리스틱 평가는 개인 평가자가 홀로 인터페이스를 평가하게 함으로써 수행된다. 모든 평가가 끝난 뒤에야 평가자들은 소통할 수 있고 그들의 분석을 취합할 수 있다. 이 절차는 각각의 평가자들로부터 독립적이고 편향되지 않은 평가를 보장하기 위해 중요하다. 이 평가의 결과는 각 평가자들이 쓴 서면 보고서 혹은 평가자들이 인터페이스를 거치며 관찰자에게 구두로 코멘트하게 함으로써 기록된다. 서면 보고서는 평가를 공식적인 기록으로 나타낸다는 장점이 있지만, 평가자들의 추가적인 노력과 평가 관리자의 기록 읽고 취합하기가 요구된다. 관찰자 투입은 각 평가 세션에 간접 비용이 더 들게 되지만, 평가자들의 작업량을 줄여준다. 또한, 평가 결과는 마지막 평가 세션 이후에 곧장 사용가능한데, 관찰자가 다른이들이 쓴 리포트 묶음이 아닌 자신이 쓴 메모 하나만 정리하고 이해하면 되기 때문이다. 게다가, 관찰자는 평가자들이 불안정한 프로토타입과 같은 문제 사례에서 인터페이스를 작동할 수 있게 도울 수 있고, 평가자들이 제한된 도메인 전문성을 가지고 있고 특정 방면의 인터페이스에 대해 설명해야 할 때 도울 수 있다.

 

inspect 검사하다, 검열하다, 시찰하다

procedure 절차, 순서

verbalize 말로 표현하다, 언어로 나타내다, 동사적으로 사용하다

go through 통하다, -을 빠져나가다, 완료하다

overhead 오버헤드, 간접비

workload 작업량

operate 작동하다

In a user test situation, the observer (normally called the "experimenter") has the responsibility of interpreting the user's actions in order to infer how these actions are related to the usability issues in the design of the interface. This makes it possible to conduct user testing even if the users do not know anything about user interface design. In contrast, the responsibility for analyzing the user interface is placed with the evaluator in a heuristic evaluation session, so a possible observer only needs to record the evaluator's comments about the interface, but does not need to interpret the evaluator's actions.

 사용자 테스트의 경우, (보통 "실험자"라 불리는) 관찰자는 어떻게 이러한 행동들이 디자인 설계 안의 사용성 이슈와 연계되는지에 대해 추론하기 위해 사용자의 행동을 예측해야 한다. 이것이 심지어 사용자들이 UI 디자인에 대해 아무것도 모르더라도 사용성 테스트가 수행될 수 있게 한다. 

 반대로, 휴리스틱 평가 세션에서는 UI 분석의 책임은 평가자에게 있어서, 관찰자는 인터페이스에 대한 평가자의 코멘트만 기록하면 되지만 평가자의 행동에 대해 예측할 필요는 없다.

 

infer 미루다, 추론하다, 추단하다

be placed with 배치하다

 

Two further differences between heuristic evaluation sessions and traditional user testing are the willingness of the observer to answer questions from the evaluators during the session and the extent to which the evaluators can be provided with hints on using the interface. For traditional user testing, one normally wants to discover the mistakes users make when using the interface; the experimenters are therefore reluctant to provide more help than absolutely necessary. Also, users are requested to discover the answers to their questions by using the system rather than by having them answered by the experimenter. For the heuristic evaluation of a domain-specific application, it would be unreasonable to refuse to answer the evaluators' questions about the domain, especially if nondomain experts are serving as the evaluators. On the contrary, answering the evaluators' questions will enable them to better assess the usability of the user interface with respect to the characteristics of the domain. Similarly, when evaluators have problems using the interface, they can be given hints on how to proceed in order not to waste precious evaluation time struggling with the mechanics of the interface. It is important to note, however, that the evaluators should not be given help until they are clearly in trouble and have commented on the usability problem in question.

 휴리스틱 평가 세션과 전통적 사용자 테스트의 두가지 추가적인 차이점은 관찰자가 세션 진행동안 평가자들의 질문에 대답할 의지와, 평가자들이 인터페이스를 사용함에 있어 힌트를 제공받을 수 있는 정도에 있다. 기존의 사용자 테스트에서, 일반적으로 인터페이스를 사용할 때 사용자가 저지르는 실수를 발견하길 원하는데, 실험자들은 그래서 완벽한 필요보다 더 도움을 제공하길 주저한다. 또한, 사용자들은 실험자가 그들에게 답변해주기보다는 시스템을 사용하면서 그들의 질문에 대한 답을 발견하는 것을 요구받는다. 특정 도메인이 적용된 휴리스틱 평가에서는, 만일 비전문가가 평가자로 참여한다면 도메인에 대한 평가자들의 질문에 대한 답을 (실험자가) 거부하는 것은 비합리적일 수 있다. 반대로, 평가자들의 질문에 대답하는 것은 그들을 도메인의 특성적 면과 함께 UI의 사용성에 더 접근할 수 있게 해준다. 비슷하게, 평가자들이 인터페이스를 사용하며 문제가 생겼을 때, 그들은 인터페이스 구조(메커니즘)로 고통받으며 소중한 평가시간을 낭비하지 않게 어떻게 진행하는지에 대한 힌트를 받을 수 있다. 그러나 평가자들이 그들이 분명히 도움을 받아야하고 사용성 문제에 대한 질문을 하기 전까지 도움을 받지 않도록 주의하는 것은 중요하다.

 

reluctant 주저하는, 싫어하는, 다루기 힘든, 저항하는

proceed 진행하다, 발생하다, 나아가다

mechanics 역학, 기능적 구조, 기계적인 부분