1.3.3 How to Write a Usability Aspect Report (UAR)

我將以SSD04的課程為藍(lán)圖，來(lái)簡(jiǎn)單講講軟件可用性分析報(bào)告的書(shū)寫方式。按照軟件工程的思想，我們需要將軟件開(kāi)發(fā)的點(diǎn)點(diǎn)滴滴以文檔的形式保存和傳遞。

• 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.

軟件分析報(bào)告主要涵蓋涉及軟件兩方面的內(nèi)容： 用戶使用中的問(wèn)題 （用以在下一個(gè)版本中指導(dǎo)軟件開(kāi)發(fā)者去修補(bǔ)）， 將對(duì)用戶使用起到幫助的設(shè)計(jì) （用以指導(dǎo)下一個(gè)版本的軟件升級(jí)）。如果我們能夠?qū)懗鲆粋€(gè)簡(jiǎn)單明了且全面的軟件可用性報(bào)告，將對(duì)軟件后續(xù)的衍生升級(jí)起到更大的幫助。在書(shū)寫這樣一份報(bào)告時(shí)，我們?nèi)匀恍枰裱己玫臅?shū)寫規(guī)范以保證 報(bào)告的真實(shí)、明了、準(zhǔn)確 為后續(xù)開(kāi)發(fā)維護(hù)和升級(jí)提供良好的備案支持。我個(gè)人在經(jīng)歷了一些開(kāi)發(fā)后也深有感觸，我同樣支持“ 文檔很重要 ”的論點(diǎn)。軟件開(kāi)發(fā)實(shí)際上就是將大家平時(shí)反復(fù)的工作以軟件的方式來(lái)模擬，開(kāi)發(fā)過(guò)程的前前后后涉及到各種工作人員，保證軟件質(zhì)量的唯一辦法就是讓每一個(gè)參與者盡量多的有全局感，能夠把握整個(gè)體系結(jié)構(gòu)，那么如何保證這種“ 信息傳遞的熱度 ”呢？強(qiáng)大的文檔支持。這種方式其實(shí)也適用于敏捷開(kāi)發(fā)，合適的文檔規(guī)模對(duì)敏捷開(kāi)發(fā)也是有巨大好處的。

?

?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.

文檔的標(biāo)識(shí)符，我們可以將它對(duì)應(yīng)到程序語(yǔ)言的標(biāo)識(shí)符，當(dāng)然這個(gè)應(yīng)該是“ 全局常量 ”。這個(gè)的定義一般會(huì)根據(jù)參與編寫文檔的人數(shù)和文檔針對(duì)的方面指定 一定的編碼規(guī)則 ，不過(guò)一般我們需要在標(biāo)識(shí)符后面加上 特種標(biāo)識(shí)符（壞的設(shè)計(jì)、好的設(shè)計(jì)） ，這種特殊的標(biāo)記會(huì)為以后的設(shè)計(jì)提供更大的幫助。

?

?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.

簡(jiǎn)單的將壞的設(shè)計(jì)或者好的設(shè)計(jì) 表達(dá) 出來(lái)。UAR標(biāo)識(shí)符只是一個(gè)簡(jiǎn)單的序號(hào)列，我們不能從中獲得有用的定位信息。我們需要將具體的方面表述出來(lái)， 但要注意是描述一個(gè)問(wèn)題，而不是描述問(wèn)題發(fā)生的場(chǎng)景 。在閱讀了上面的解釋，我有一個(gè)感覺(jué)就是在描述時(shí)直接給出正確的模式而不是說(shuō)“不是什么什么”。

?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.

提出針對(duì)具體問(wèn)題的正確方案。我們知道在一個(gè)報(bào)告中，我們需要在這個(gè)部分描述問(wèn)題發(fā)生的具體環(huán)境，并從不同的“檢查點(diǎn)”（有一定的規(guī)則，我們會(huì)更 客觀 。例如啟發(fā)式檢查、全方位思考檢查）去闡述分析問(wèn)題并最終給出問(wèn)題屬于的領(lǐng)域。

當(dāng)然對(duì)于不同的規(guī)則，我們還需要給出 相應(yīng)格式化的問(wèn)題描述文檔 。例如：

• HE：可以含有軟件的截屏圖，具體問(wèn)題說(shuō)涉及到的具體設(shè)計(jì)方面
• Think-aloud：描述具體設(shè)計(jì)問(wèn)題導(dǎo)致一些使用問(wèn)題的前前后后（包括系統(tǒng)自身的、用戶實(shí)際操作的）

?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.)

針對(duì)上面提出的解決方案，本部分需要給出詳細(xì)的原因。你需要按照think-aloud或者HE的有關(guān)法則來(lái)做出合理的解釋，從軟件工程的角度考慮就是我們需要給出 足夠的信息 （文檔）幫助設(shè)計(jì)人員針對(duì)原因給出物理級(jí)別的解決方案。

?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.

在這一部分，我們需要給出本報(bào)告中涉及問(wèn)題的好的方面所帶來(lái)的 益處 或者壞的方面說(shuō)帶來(lái)的 害處 。

?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.

對(duì)具體的使用問(wèn)題提出 可行的解決方案 ，不過(guò)這里需要注意：我們需要在認(rèn)真審視了 所有問(wèn)題后綜合各方面 的情況從一個(gè)更高的角度提出問(wèn)題的解決方案（由于對(duì)敏捷開(kāi)發(fā)學(xué)習(xí)很淺薄，不知道這種經(jīng)過(guò)大量的前期分析再做改動(dòng)的方法是否違背了小迭代的敏捷開(kāi)發(fā)解決方案）。

?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.)

寫出各個(gè)設(shè)計(jì)問(wèn)題之間的 關(guān)聯(lián) （記住這種關(guān)聯(lián)肯定是 雙向 的），在UAR上面的體現(xiàn)就是報(bào)告與報(bào)告間的相互關(guān)聯(lián)。

?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.

需要時(shí)時(shí)向回審視一下，需要有一個(gè) 全局感 。其實(shí)這不僅僅是寫報(bào)告時(shí)需要注意的，我個(gè)人的開(kāi)發(fā)體會(huì)是需要讓整個(gè)開(kāi)發(fā)團(tuán)隊(duì)有一個(gè)全局感、有 大局觀 。這也是困擾軟件開(kāi)發(fā)的主要問(wèn)題：丟失的信息、配合的錯(cuò)位、不合理的安排、錯(cuò)誤的流程。

?

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

如何撰寫一個(gè)軟件可用性分析報(bào)告