如何撰写一个软件可用性分析报告

1.3.3 How to Write a Usability Aspect Report (UAR)

我将以SSD04的课程为蓝图，来简单讲讲软件可用性分析报告的书写方式。按照软件工程的思想，我们需要将软件开发的点点滴滴以文档的形式保存和传递。

• Usability Aspect Reports
• The Elements of a UAR Report
  • UAR Identifier
  • Succinct Description of the Usability Aspect
  • Evidence for the Aspect
  • Explanation of the Aspect
  • Severity of the Problem or Benefit of the Good Feature
  • Possible Solutions and Potential Trade-Offs
  • Relationship to Other Usability Aspects
• IMPORTANT: Always Step Back and Try to See the Bigger Picture!

Usability Aspect Reports

As you examine an interface with the techniques this course will teach you, you will find aspects of the interface that are problems for users (which you will want to fix in the next version) and aspects that are very helpful to users (which you will want to preserve in the next version). Writing a clear, useful report of these aspects (called a usability aspect report or UAR ) will help to make that next version more usable. In the real world, you will write these reports for other members of your development team who have not seen the usability issue; therefore, your reports must be clear and complete. Even when you are writing these UARs just for yourself, clarity and completeness will help you understand each report six months after you write it, when you finally get around to implementing the changes it suggests.

软件分析报告主要涵盖涉及软件两方面的内容：用户使用中的问题 （用以在下一个版本中指导软件开发者去修补），将对用户使用起到帮助的设计 （用以指导下一个版本的软件升级）。如果我们能够写出一个简单明了且全面的软件可用性报告，将对软件后续的衍生升级起到更大的帮助。在书写这样一份报告时，我们仍然需要遵循良好的书写规范以保证报告的真实、明了、准确 为后续开发维护和升级提供良好的备案支持。我个人在经历了一些开发后也深有感触，我同样支持“文档很重要 ”的论点。软件开发实际上就是将大家平时反复的工作以软件的方式来模拟，开发过程的前前后后涉及到各种工作人员，保证软件质量的唯一办法就是让每一个参与者尽量多的有全局感，能够把握整个体系结构，那么如何保证这种“信息传递的热度 ”呢？强大的文档支持。这种方式其实也适用于敏捷开发，合适的文档规模对敏捷开发也是有巨大好处的。

 

 The Elements of a UAR Report

We advocate a standard form for the report so you remember to include specific pieces of information for each usability aspect. The UAR should include the following slots:

• UAR Identifier — <Problem or Good Feature>
• Succinct description of the usability aspect
• Evidence for the aspect
• Explanation of the aspect
• Severity of the problem or benefit of the good feature
• Possible solution and potential trade-offs (if the aspect is a problem)
• Relationship to other usability aspects (if any)

We will describe each slot below—that is, what it is and why this information is necessary. We will give many examples of UARs as we introduce the details of the HE and think-aloud techniques.

 UAR Identifier

 

This should be a unique identifier for the purposes of filing. If more than one person is working on the project or more than one analysis technique is being used, this identifier could contain letters and numbers. For example, if Chris Smith and Jan Koo are both doing an analysis, the identifier might be CS1 or JK75. If both a heuristic evaluation and a think-aloud usability study were used, the identifiers might be HE6 or TA89.

Follow the unique identifier with the word "Problem," if the report pertains to a usability problem of the interface, or the words "Good Feature," if it describes an aspect of the interface you feel should be preserved in any redesign.

文档的标识符，我们可以将它对应到程序语言的标识符，当然这个应该是“全局常量 ”。这个的定义一般会根据参与编写文档的人数和文档针对的方面指定一定的编码规则 ，不过一般我们需要在标识符后面加上特种标识符（坏的设计、好的设计） ，这种特殊的标记会为以后的设计提供更大的帮助。

 

 Succinct Description of the Usability Aspect

This description will be used as the "name" of this UAR when you talk about its relation to other UARs. Make the name as short as possible (about three to five words) but still descriptive and distinguishable from other aspects of the system.

If this UAR is about a problem (as opposed to a good feature), make sure you have a name that describes the problem, rather than a solution. For instance, if there is a button that looks like this

 

Figure 1: A button with a small label.

and you think the label is too small for the average person to read comfortably, you should call the UAR "Press-Me label too small" (which is a problem statement) as opposed to "Press-Me label should be 24 point" (which is a solution, not a problem). The reason you want the name to be the problem, not the solution at this point, is that you want to leave room for the possibility that you might find several problems that are similar and that suggest one common solution. But, if you solve each individual problem individually and enshrine its individual solution in the name of its UAR, you may not see the similarities in the problems.

简单的将坏的设计或者好的设计表达 出来。UAR标识符只是一个简单的序号列，我们不能从中获得有用的定位信息。我们需要将具体的方面表述出来，但要注意是描述一个问题，而不是描述问题发生的场景 。在阅读了上面的解释，我有一个感觉就是在描述时直接给出正确的模式而不是说“不是什么什么”。

 Evidence for the Aspect

This is the objective supporting material that justifies your identifying the aspect as worthy of report. This section needs to contain enough information for a reader of this UAR to understand what triggered the report. For an HE report, for instance, this could be an image of a cluttered screen and the heuristic about aesthetics and minimalist design. Or, it could be a list of menu items that do not have keyboard shortcuts and the heuristic about providing shortcuts. In a think-aloud study this is usually what was on the screen (a screen shot or description), what the user did (keystrokes, mouse movements), what the system did in response to any user actions, and what the user said. If you have video annotating or editing capability, it can be a brief animation.

You need to include enough pertinent information about the identification of an aspect for the reader to understand what the analyst was thinking when the aspect was identified (for HE) or what the user was trying to do when the aspect either hindered or facilitated the user's progress.

提出针对具体问题的正确方案。我们知道在一个报告中，我们需要在这个部分描述问题发生的具体环境，并从不同的“检查点”（有一定的规则，我们会更客观 。例如启发式检查、全方位思考检查）去阐述分析问题并最终给出问题属于的领域。

当然对于不同的规则，我们还需要给出相应格式化的问题描述文档 。例如：

• HE：可以含有软件的截屏图，具体问题说涉及到的具体设计方面
• Think-aloud：描述具体设计问题导致一些使用问题的前前后后（包括系统自身的、用户实际操作的）

 Explanation of the Aspect

This is your interpretation of the evidence. That is, for a think-aloud usability test, why you think what happened, happened, or, for an HE, why you think the aspect was designed the way it was. This can include things like "the button label, XYZ, is a standard programming term, but the user didn't seem to know that term" or "the system was in editing mode, but the user thought it was in run mode because there isn't a noticeable difference between the modes on the screen." (This should be written in a tone that analyzes what happened with the system aspect, NOT in a tone that suggests an evaluation of the developers or of the user.)

You need to provide enough context in this explanation for the reader to understand the problem—even if they do not know the system or domain as well as you do. (It is our experience that you will yourself need a lot of context when you look at these reports months in the future.)

针对上面提出的解决方案，本部分需要给出详细的原因。你需要按照think-aloud或者HE的有关法则来做出合理的解释，从软件工程的角度考虑就是我们需要给出足够的信息 （文档）帮助设计人员针对原因给出物理级别的解决方案。

 Severity of the Problem or Benefit of the Good Feature

This is your reasoning about how important it is to either fix this problem or preserve this good feature. This includes how frequently the users will experience this aspect, whether they are likely to learn how it works, whether it will affect new users, casual users, experienced users, etc.

在这一部分，我们需要给出本报告中涉及问题的好的方面所带来的益处 或者坏的方面说带来的害处 。

 Possible Solutions and Potential Trade-offs

If this aspect is a problem (as opposed to a good feature to be preserved in the next version of the software), this is the place to propose a solution. It is not necessary to have a solution as soon as you identify a problem—you might find after analyzing the whole interface that many problems are related and can all be fixed by making a single broad change instead of making several small changes.

However, if you do propose a possible solution, report any potential design trade-offs that you see. For instance, the problem might be that there are no keyboard shortcuts for items on a menu in a mail system and you propose CTRL-S for SEND. A design trade-off you should record is that CTRL-S might already be used for another menu item (e.g., SAVE), so all shortcut keys need to be examined before any design changes are made.

对具体的使用问题提出可行的解决方案 ，不过这里需要注意：我们需要在认真审视了所有问题后综合各方面 的情况从一个更高的角度提出问题的解决方案（由于对敏捷开发学习很浅薄，不知道这种经过大量的前期分析再做改动的方法是否违背了小迭代的敏捷开发解决方案）。

 Relationship to Other Usability Aspects

It is often the case that UARs are related to each other. This is where you record which UARs this one is related to and a statement about how it is related. Make sure that all the related UARs point to each other. That is, if UAR #1 related to UAR #30, then UAR #30 should point to UAR #1 in this section and UAR #1 should point to UAR #30 in its version of this section. (It is a common mistake to enter the pointer into a newly created UAR, but neglect to go back to the previous ones that it relates to and update their UARs.)

写出各个设计问题之间的关联 （记住这种关联肯定是双向 的），在UAR上面的体现就是报告与报告间的相互关联。

 IMPORTANT: Always Step Back and Try to See the Bigger Picture!

This last slot in the UAR records the results of a very important step in the usability analysis process: stepping back and looking for patterns in the usability problems. You should do this at several times during the analysis. When each UAR is created, you should look back to the previous UARs and see if they are related to the new one. When you have completed all UARs, you should go back and look again for patterns. This step allows you to detect larger problems in the interface that might have a solution that fixes many small problems with only one change. This step also provides the opportunity to amass evidence for a fundamental change in the proposed interface, something that would never arise out of considering single UARs in isolation.

需要时时向回审视一下，需要有一个全局感 。其实这不仅仅是写报告时需要注意的，我个人的开发体会是需要让整个开发团队有一个全局感、有大局观 。这也是困扰软件开发的主要问题：丢失的信息、配合的错位、不合理的安排、错误的流程。

 

© Copyright 1999-2003, iCarnegie, Inc. All rights reserved.