230312 How to Conduct a Heuristic Evaluation (휴리스틱 평가 수행하는 법 from NN group) 中
안녕하세요 갓생도전입니다. 휴리스틱 평가를 수행하는 법에 대해 휴리스틱 평가의 창시자 제이콥 닐슨이 직접 저술한 글에 대한 두번째 번역 시간입니다. 일단 재밌겠다!!!하고 냅다 시작을 하긴 했는데요 만만하게 봤다가 무려 세 번에 걸쳐 번역해야할 분량임을 깨닫고 아주 고통스러운 중입니다 그래도 공부하기는 더 싫으니까 일단 냅다 번역이라도 해보겠습니다
시작
하기 전에 이전 글을 보고 싶은 분들을 위해 ^-^**
230305 How to Conduct a Heuristic Evaluation (휴리스틱 평가 수행하는 법 from NN group) 上
안녕하세요 갓생도전입니다. 예전부터 해보고 싶었던 해외아티클 번역을 오늘부터 야금야금 진행해보려합니다!!!! 야호 일벌리기 제일 좋아 아무래도 공부하는 분야가 IT 서비스 쪽이다 보니 해
lo-que-hoy-estudie.tistory.com
이제 찐 시작 !!
(발번역 주의, 오역 많을 수 있음, 피드백 환영)
Typically, a heuristic evaluation session for an individual evaluator lasts one or two hours. Longer evaluation sessions might be necessary for larger or very complicated interfaces with a substantial number of dialogue elements, but it would be better to split up the evaluation into several smaller sessions, each concentrating on a part of the interface.
전형적으로, 개인 평가자가 하는 휴리스틱 평가 세션은 1~2시간이 걸린다. 더 긴 평가 세션은 더 방대하거나 상당한 수의 대화 요소들이 있는 매우 복잡한 인터페이스에 필요할 수도 있으나, 평가를 더 작은, 각각 인터페이스의 한 부분을 포함하는 몇 개의 세션들로 쪼개는 것이 바람직하다.
During the evaluation session, the evaluator goes through the interface several times and inspects the various dialogue elements and compares them with a list of recognized usability principles (the heuristics). These heuristics are general rules that seem to describe common properties of usable interfaces. In addition to the checklist of general heuristics to be considered for all dialogue elements, the evaluator obviously is also allowed to consider any additional usability principles or results that come to mind that may be relevant for any specific dialogue element. Furthermore, it is possible to develop category-specific heuristics that apply to a specific class of products as a supplement to the general heuristics. One way of building a supplementary list of category-specific heuristics is to perform competitive analysis and user testing of existing products in the given category and try to abstract principles to explain the usability problems that are found (Dykstra 1993).
세션 평가 동안, 평가자는 인터페이스를 몇 번 거치고 다양한 대화요소들을 점검하며 그것들을 인정된 사용성 원칙 리스트(휴리스틱)과 비교한다. 이 휴리스틱들은 사용가능한 인터페이스의 공통 속성들을 묘사한 것으로 보이는 일반적 규칙이다. 모든 대화요소들에 대한 것으로 알려져 있는 일반적 휴리스틱 체크리스트에 더하여, 평가자는 명확히 어떠한 특정 대화 요소와 관련되어 있을지도 모르는, 떠오른 어떠한 추가적인 사용성 원칙이나 결과들을 고려할 수도 있다. 게다가, 일반적 휴리스틱을 보충하는 것으로서 특정 클래스의 프로덕트에 적용할 카테고리별 휴리스틱을 발전시키는 것도 가능하다. 카테고리별 휴리스틱의 보충 리스트를 빌드하는 한 가지 방법은, 주어진 카테고리 내에서 존재하는 제품에 대해 경쟁 분석과 사용자 테스트를 수행하고, 찾아낸 사용성 문제들을 설명하는 추상적인 원칙을 시도하는 것이다. (다익스트라, 1993)
instpect 검사하다, 검열하다, 시찰하다
property 속성, 재산, 성질, 소유권
supplement (n.) 보충, 부록, 보유 / (v.) 보충하다, 보유하다
abstract 추상적인
In principle, the evaluators decide on their own how they want to proceed with evaluating the interface. A general recommendation would be that they go through the interface at least twice, however. The first pass would be intended to get a feel for the flow of the interaction and the general scope of the system. The second pass then allows the evaluator to focus on specific interface elements while knowing how they fit into the larger whole.
Since the evaluators are not using the system as such (to perform a real task), it is possible to perform heuristic evaluation of user interfaces that exist on paper only and have not yet been implemented (Nielsen 1990). This makes heuristic evaluation suited for use early in the usability engineering lifecycle.
원칙적으로, 평가자들은 자신이 인터페이스 평가를 진행하고 싶은 방법을 결정한다. 그러나 최소 두번은 인터페이스를 겪어보는 것이 일반적으로 권장된다. 첫 번째에서는 상호작용의 흐름과 시스템의 일반적 범위에 대한 느낌을 얻도록 한다. 그러고 나서 두 번째에서는 평가자들이 그게 어떻게 더 큰 전체에서 맞아떨어지는지 알기 때문에, 특정 인터페이스 요소들에 집중할 수 있도록 한다.
평가자들이 이와 같이(실제 작업을 수행해보는 것) 시스템을 사용하지 않기 때문에, 종이에만 존재하고, 아직 구현되지 않은 UI의 휴리스틱 평가를 수행하는 것이 가능하다(닐슨, 1990). 이것이 휴리스틱 평가를 사용성 공학 라이프사이클에서의 이른 사용에 맞게 한다.
be intended to 의도하다
scope 범위
If the system is intended as a walk-up-and-use interface for the general population or if the evaluators are domain experts, it will be possible to let the evaluators use the system without further assistance. If the system is domain-dependent and the evaluators are fairly naive with respect to the domain of the system, it will be necessary to assist the evaluators to enable them to use the interface. One approach that has been applied successfully is to supply the evaluators with a typical usage scenario, listing the various steps a user would take to perform a sample set of realistic tasks. Such a scenario should be constructed on the basis of a task analysis of the actual users and their work in order to be as representative as possible of the eventual use of the system.
만약 시스템이 일반 대중들을 위한 워크업 유즈 인터페이스로 의도 되었다면, 혹은 평가자들이 도메인 전문가라면, 평가자들이 추가 도움 없이도 시스템을 사용하게 할 수 있을 것이다. 만약 시스템이 도메인 기반이고, 평가자들이 시스템의 도메인에 대해 무지할 경우, 그들이 인터페이를 사용할 수 있도록 도움이 필요할 수 있다. 성공적으로 적용되어온 한 가지 접근법은 평가자들을 일반적인 사용 시나리오에 적용시키는 것인데, 사용자가 실감나는 태스크 샘플 세트를 수행하기 위해 취해햐 할 여러 스텝들을 나열하는 것이다. 이런 시나리오는 시스템의 최종 사용을 최대한 반영하기 위해 실제 사용자와 그들의 작업에 대한 작업 분석에 기반하여 만들어져야한다.
walk-up-and-use Technologies that allow people to use the device or application without previous training or instruction; systems intended to be used by first-time and one-time users who need to be able to effectively use the system without any training
realistic 실감나는, 현실주의의, 실재론적인
eventual 최종의, 최후의, 어쩌면 이러날 수도 있는
The output from using the heuristic evaluation method is a list of usability problems in the interface with references to those usability principles that were violated by the design in each case in the opinion of the evaluator. It is not sufficient for evaluators to simply say that they do not like something; they should explain why they do not like it with reference to the heuristics or to other usability results. The evaluators should try to be as specific as possible and should list each usability problem separately. For example, if there are three things wrong with a certain dialogue element, all three should be listed with reference to the various usability principles that explain why each particular aspect of the interface element is a usability problem. There are two main reasons to note each problem separately: First, there is a risk of repeating some problematic aspect of a dialogue element, even if it were to be completely replaced with a new design, unless one is aware of all its problems. Second, it may not be possible to fix all usability problems in an interface element or to replace it with a new design, but it could still be possible to fix some of the problems if they are all known.
휴리스틱 평가 방법을 사용한 결과는, 평가자의 의견으로 각 케이스에서 디자인으로 위배된 사용성 원칙들에 대한 레퍼런스와 함께 인터페이스의 사용성 문제 목록이다. 평가자들이 단순히 그들이 어떤걸 좋아하지 않는다고 말하는 것으로는 충분치 않다; 그들은 휴리스틱 혹은 다른 사용성 결과를 참조해 왜 그들이 그것을 좋아하지 않는지 설명해야 한다. 평가자들은 가능한 한 구체적이여야 하고, 각각의 사용성 문제를 분리하여 목록을 작성해야 한다. 예를 들어, 여기에 한 특정 대화요소에서 세 가지 잘못된 점이 있다면, 왜 인터페이스 요소의 각각의 특정 측면이 사용성 문제인지를 설명하는 다양한 사용성 원칙을 참조하여 세 개 전체가 리스트에 작성되어야 한다. 각 문제를 분리하여 기록하는 두 가지 주요한 이유가 있는데: 우선, 심지어 완벽하게 새로운 디자인으로 바뀌었는데도 그것의 모든 문제를 인식하지 않는 한 대화 요소의 어떠한 문제적 측면을 반복할 리스크가 있다. 다음으로, 한 인터페이스 요소 안에 모든 사용성 문제들을 고치거나 새로운 디자인으로 바꾸는 것은 불가능할지도 모르지만, 문제들이 모두 알려진다면 여전히 몇 가지 문제들은 고칠 수 있을 수도 있기 때문이다.
violate 위반하다
replace 바꾸다, 재배치하다
unless ~하지 않는 한
be aware of 알아두다
Heuristic evaluation does not provide a systematic way to generate fixes to the usability problems or a way to assess the probable quality of any redesigns. However, because heuristic evaluation aims at explaining each observed usability problem with reference to established usability principles, it will often be fairly easy to generate a revised design according to the guidelines provided by the violated principle for good interactive systems. Also, many usability problems have fairly obvious fixes as soon as they have been identified.
휴리스틱 평가가 사용성 문제에 대해 수정하는 시스템적인 방법이나 어떠한 재설계의 가능한 퀄리티에 접근하는 방법을 제시하지는 않는다. 그러나, 휴리스틱 평가가 정립된 사용성 원칙에 참조하여 관찰된 각각의 사용성 문제를 설명하는 데에 초점이 맞춰져 있기 때문에, 종종 좋은 상호작용적 시스템에 대한 위반된 원칙에 의해 제공되는 가이드라인을 따라 디자인을 재수정 하는 것은 꽤 쉬울것이다. 또한, 많은 사용성 문제들은 그것들이 식별되자마자 상당히 명확한 수정 사항이 있다.
assess (가치, 성질을) 평가하다, 할당하다
aim at ~을 겨누다
For example, if the problem is that the user cannot copy information from one window to another, then the solution is obviously to include such a copy feature. Similarly, if the problem is the use of inconsistent typography in the form of upper/lower case formats and fonts, the solution is obviously to pick a single typographical format for the entire interface. Even for these simple examples, however, the designer has no information to help design the exact changes to the interface (e.g., how to enable the user to make the copies or on which of the two font formats to standardize).
예를 들어, 만약 사용자가 한 화면에서 다른 화면으로 정보를 복사하지 못하는 문제가 있다면, 그 솔루션은 명백하게도 복사 기능 같은 것을 포함하는 것이다. 마찬가지로, 대소문자 형식과 폰트 형태에서 일관적이지 않은 타이포그래피 사용이 문제라면, 그 해결책은 분명하게도 전체 인터페이스에 대해 한가지 타이포그래픽 형식을 고르는 것이다. 그러나, 이러한 간단한 예시들에서조차, 디자이너가 인터페이스에 대한 정확한 변화를 설계하는 것을 도울 정보는 없다(예를 들어, 어떻게 사용자가 복사를 가능하게 할지 또는 두 폰트 중 어떤 것을 표준으로 삼을지).
inconsistent 일관성 없는
One possibility for extending the heuristic evaluation method to provide some design advice is to conduct a debriefing session after the last evaluation session. The participants in the debriefing should include the evaluators, any observer used during the evaluation sessions, and representatives of the design team. The debriefing session would be conducted primarily in a brainstorming mode and would focus on discussions of possible redesigns to address the major usability problems and general problematic aspects of the design. A debriefing is also a good opportunity for discussing the positive aspects of the design, since heuristic evaluation does not otherwise address this important issue.
디자인적인 조언을 제공하기 위해 휴리스틱 평가 방식을 확장하는 한 가지 가능성은 마지막 평가 세션 이후에 debriefing(보고) 세션을 수행하는 것이다. 디브리핑의 참여자들은 평가자들과 평가 세션 중에 참여한 모든 관찰자, 그리고 디자인 팀의 대표를 포함해야한다. 보고 세션은 주로 브레인스토밍 모드로 수행되어야 하고, 주요 사용성 문제와 디자인의 일반적인 문제 측면을 해결하기 위해 가능한 재설계에 대한 토론에 초점이 맞춰질 것이다. 디브리핑은 또한 디자인의 긍정적 측면을 논의하는 좋은 기회이기도 한데, 휴리스틱 평가는 이러한 중요한 이슈를 다루지 않기 때문이다.
debriefing 보고, 복명(명령 복종하다)
primarily 주로, 첫째로
address 다루다, 말 걸다, 제기하다, 주소를 쓰다, 해결하다
ㅎㅎ... 시간 넘 잘 가네용 이어서 하 편까지 후딱 마무리 지어야겠습니다 다음 게시물에서 봐요!