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.

如何撰寫一個軟件可用性分析報告