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

1.3.3 How to Write a Usability Aspect Report (UAR)

我将基于SSD04课程的知识体系来具体阐述软件可用性分析报告的撰写规范。遵循软件工程的方法论原则，我们将对软件开发的所有细节进行记录并传播。

• Usability Reports Documenting
  • The Structure of a Usability Assessment Report
    • Unique Identifier for Usability Features
    • A Concise Explanation of Each Usability Element
    • Empirical Evidence Supporting Identified Issues
    • Detailed Analysis to Justify Findings
    • Quantification of Issue Magnitude or Advantage
    • Potential Fixes and Considerations for Solutions
    • Connection to Other Key Usability Concerns
  • WARNING: Remember to Evaluate the Broader Implications!

Usability Aspect Reports

When analyzing an interface using the techniques taught in this course, one can identify features that pose challenges for users—these require fixing in future versions—or features that significantly enhance usability—these should be retained. Preparing a clear and comprehensive report detailing these findings is essential as it ensures future usability improvements. In practical scenarios, such reports are prepared for other developers who haven’t encountered this usability issue yet. Consequently, clarity and completeness are crucial. Regardless of whether intended solely for personal use or shared with others within your team, maintaining clarity and completeness ensures understanding six months later when implementing suggested changes.

该软件分析报告主要涉及两个方面：一是用户在使用过程中遇到的问题（这些信息可用于指导后续版本中的修复工作），二是经过设计改进后对用户体验有帮助的部分（这些设计可用于指导后续版本的功能升级）。撰写一份简明扼要又全面的可用性报告对于后续开发维护和升级具有重要意义。撰写这样一份详实且条理清晰的报告不仅有助于提升开发效率和质量，在实际开发过程中积累的经验对于提升工作质量至关重要……个人经验表明，在实际开发过程中积累的经验对于提升工作质量至关重要……个人经验表明，在实际开发过程中积累的经验对于提升工作质量至关重要……构建全面而详实的技术文档是确保信息顺畅传递的关键。

The Elements of a UAR Report

It is recommended that a standardized format be used in reports to ensure that you remember to include specific information related to each usability aspect. The Usability Assessment Report (UAR) must incorporate the following key components:

• UAR identifier serves as an indicator for distinguishing between problems and good features.
• A brief overview of how this usability feature manifests.
• Empirical evidence supporting this usability characteristic.
• Clarification of this usability feature’s characteristics.
• The extent to which it impacts user experience.
• The potential solutions and associated trade-offs when addressing this issue.
• The connection between this feature and others in terms of their impact on user experience.

Each slot will be described below, including its nature and the reason why this information is necessary. As we introduce the details of the HE and think-aloud techniques, we will provide numerous examples of UARs.

---

UAR Identifier

---

This should serve as a unique identifier for classifying files. When multiple individuals are involved in a project or diverse analytical techniques are applied, the identifier may incorporate alphanumeric characters. For instance, if Chris Smith and Jan Koo are collaborating on an analysis, potential identifiers could include CS1 or JK75. Additionally, depending on the evaluation methods employed—such as heuristic assessment and think-aloud usability studies—the identifiers might take forms like HE6 or TA89.

Proceed with the unique identifier by appending either "Problem" or "Good Feature" to it, depending on whether the report discusses a usability issue of the interface or an aspect that should remain consistent in any redesign.

在处理文档时我们引入了一种独特的表示方法即使用特定符号来代替原有的变量名以避免混淆并提高可读性这种方法被称为变量重命名它能够有效减少代码冗余并提升开发效率。

Succinct Description of the Usability Aspect

The term for this description will function as a designated identifier for this UAR, particularly when discussing its relationship with other UARs. It should be concise, ideally between three to five words, while also being descriptive enough to differentiate it from other components within the system.

If this UAR pertains to a problem (instead of being a positive feature), ensure your name accurately reflects the issue rather than offering a solution. For example, consider this button whose design conveys

Figure 1: A button with a small label.

if you believe the label is too small for the average individual to read comfortably, it would be more appropriate to frame this as a "Press-Me label too small" issue (a problem statement) rather than suggesting it "should be 24 point" (which implies a solution). The rationale behind addressing this as a problem at this stage is to maintain flexibility, allowing for the possibility that we might identify multiple related issues that could suggest a shared solution. However, if we opt to solve each problem individually by embedding its specific solution into its respective URN, we might overlook underlying similarities between them.

通过明确区分不良的设计与优秀的设计来进行表征。UAR标识符仅作为一个简单的序号序列存在，并不能提供有用的位置信息。为了准确描述问题的本质特征，则需要聚焦于关键的差异点而避免笼统地谈论发生的情景。整体感觉是在强调在描述时应尽量清晰传达正确的解决方案而非单纯否定其他可能性。

Evidence for the Aspect

The following document serves as objective supporting material and is intended to justify your classification of a particular aspect as significant for reporting purposes. This section must provide sufficient details so that readers of this UAR can comprehend what triggered the report process. For HE reports specifically, this documentation could include an image depicting a cluttered interface along with insights into aesthetic principles and minimalist design considerations. Alternatively, it might detail menu items lacking keyboard shortcuts and strategies for enhancing usability through shortcut provision. In think-aloud studies, this documentation typically encompasses elements such as screen displays ( screenshots or descriptions ), user interactions ( keystrokes, mouse movements ), system responses to these actions, and user utterances or annotations made during the session. If video annotation or editing capabilities are available, supplementary materials like brief animations can enhance understanding.

It is necessary for readers to be provided with sufficient relevant details concerning how an aspect is identified, so that they can comprehend what motivated and guided its analysis (specifically for HE purposes) or, alternatively, discern whether a particular action attempted by a user could have either impeded or facilitated their progress.

我们应针对特定问题设计出合理的解决方案。在撰写一份报告时，在这一部分中需要描述问题发生的具体环境，并采用一系列预先设定的评估标准（如启发式方法和全面性评估等）系统地进行分析，并最终确定该问题涉及的领域。

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

• HE：支持包含软件截图的功能，并且能够详细描述涉及的具体设计细节。
• Think-aloud：详细说明具体的设计难题及其引发的一系列使用困扰（涵盖系统内部的问题以及用户操作过程中的挑战）。

Explanation of the Aspect

This represents your evaluation of the evidence. Specifically, this pertains to why you believe a think-aloud usability test would reveal a particular phenomenon or how an HE might reason about such occurrences. This could encompass situations like "the button label XYZ is a standard programming term but users unfamiliar with programming may not recognize it" or "the system appeared in edit mode but users assumed it was in run mode because there's no visible distinction between the two modes on the screen." (The tone should focus on analyzing what occurred with respect to this system aspect without implying judgment about either the developers or the users.)

Our users must ensure that explanations are provided with an adequate amount of context so that readers can grasp the problem effectively—even if they lack knowledge about the system or domain as well as we do. We believe that looking at these reports months ahead will require readers to have a great deal of background information.

针对上述提出的解决方案本段将详细阐述原因并根据软件工程学原理提供足够的文档信息以协助设计人员制定物理层面的解决方案

Severity of the Problem or Benefit of the Good Feature

This is your consideration of the crucial factors involved in addressing this issue or safeguarding its positive attributes. This encompasses elements such as user frequency of encountering this aspect, likelihood of gaining an understanding of its functionality, potential impact on different user demographics including newbies, casual users, and seasoned users.

在本报告中所涉及的问题及其带来的影响中, 我们需要阐述其积极效果以及存在的缺陷所导致的负面影响

Possible Solutions and Potential Trade-offs

When this aspect presents an issue (contrasted with being a positive feature in the next software version), it's appropriate here to propose a solution. There's no need to act immediately upon identifying an issue; analysis may reveal that multiple problems are interconnected, allowing all issues to be resolved with one comprehensive change instead of several smaller fixes.

When considering a potential solution, it's important to address any identified design trade-offs. One potential issue is the lack of keyboard shortcuts for menu items in email systems; as an alternative, suggesting using_CTRL_S as the SEND function. It's crucial to document any conflicts; for instance,CTRL_S might already be used for another menu item (e.g., SAVE), so all shortcut keys need to be examined before making any design changes.

针对具体的应用场景设计切实可行的解决方案 ，然而需要注意的是，在全面审视所有问题的基础上综合考虑多方面因素后从更高层次上提出解决方案 （由于本人对于敏捷开发的学习尚浅薄） ，担心这种方法虽然经过大量前期分析后再进行修改可能会与小迭代原则相冲突

Relationship to Other Usability Aspects

通常情况下，URIs（UARs）之间存在关联。此处记录该URI与其他哪些URI相关联，并说明它们之间的关系。确保所有相关的URI相互指向彼此。也就是说，在此部分中，如果URI#1与URI#30相关联，则URI#30应指向URI#1；同时，在URI#1的部分中也应指向URI#30。（这是一个常见的错误：创建新URI时忘记更新原有相关URI的链接）

阐述各个设计问题之间存在的联系（这种联系具有相互性），在UAR框架下表现为各报告之间的相互联系

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

In the UAR, this final slot captures crucial insights from an essential phase within usability analysis: taking a step back to identify emerging patterns among usability issues. Suggest performing this review at multiple points throughout your analysis. Each time a new UAR is generated, be sure to examine prior Usability Assessments (UAs) to determine if they relate to current findings. Once all Usability Assessments are complete, revisit them one more time with fresh eyes before drawing conclusions. This process enables us to pinpoint significant interface issues that may be resolved by addressing multiple minor concerns through a single strategic adjustment. Additionally, this method offers valuable evidence about substantial changes needed for effective redesign of user interfaces.

时常回顾过去的同时,也需要保持整体意识。实际上这不仅仅局限于撰写报告时所需关注的重点。在我的开发经验中发现,在整个团队中培养大局观是一个至关重要的因素。这也成为了软件开发面临的主要挑战:信息丢失会导致效率低下;团队配合出现偏差会影响项目进度;不合理安排可能导致资源浪费;而错误流程则可能导致额外工作量。

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