Citation - Cooper, A., Reimann, R., & Cronin, D. (2007). About face 3: the essentials of interaction design. Indianapolis, IN: Wiley Pub.

• Cooper, A.、Reimann, R.與 Cronin, D.（2007）。About face 3 交互設計精隨（劉濤等 譯）。北京：電子工業出版社。

Keyword - HCI, UI, interaction design

儘管我們應該盡可能在詳細的質性資料中建立人物角色，但若我們沒有足夠的時間、資源或金錢來作足夠的實際工作，可以採用暫定的人物角色(Provisional persona)，Donald Norman 稱之為 ad hoc persona。

使用暫定角色：

• 標示他們是未經檢驗的暫定角色
• 使用草圖而非照片
• 盡可能利用既有次級資料，如市場調查研究。
• 紀錄使用的數據與做出的假設
• 避免以刻版印象(stereotype)建立角色
• 重點在於動機與行為，而不是人口統計資料

Alan Cooper 對應 Donald Norman 在情感設計(Emotional design)一書中提出的三個認知處理層次(本能、行為、反思)，建立三種使用者目標：

• 體驗目標
• 最終目標
• 人生目標

• Interaction design is not guesswork.
• User interfaces should be based on user mental models rather than implementation models.
• Goal-directed interactions reflect user mental models.
• Users don't understand Boolean logic.
• Don't replicate Mechanical-Age artifacts in user interfaces without Information Age enhancements.
• Significant change must be significantly better.
• Nobody wants to remain a beginner.
• Optimize for intermediates.
• Imagine users as very intelligent but very busy.
• Don't make the user feel stupid.
• Focus the design for each interface on a single primary persona.
• Define whatthe product will do before you design howthe product will do it.
• In early stages of design, pretend the interface is magic.
• Never show a design approach that you're not happy with; stakeholders just might like it.
• There is only one user experience - form and behavior must be designed in concert with each other.
• Decisions about technical platform are best made in concert with interaction design efforts.
• Optimize sovereign applications for full-screen use.
• Sovereign interfaces should feature a conservative visual style.
• Sovereign applications should exploit rich input.
• Maximize document views within sovereign applications.
• Transient applications must be simple, clear, and to the point.
• Transient applications should be limited to a single window and view.
• A transient application should launch to its previous position and configuration.
• Kiosks should be optimized for first-time use.
• No matter how cool your interface is, less of it would be better.
• Well-orchestrated user interfaces are transparent.
• Follow users' mental models.
• Less is more.
• Enable users to direct, don't force them to discuss.
• Keep tools close at hand.
• Provide modeless feedback.
• Design for the probable; provide for the possible.
• Contextualize information.
• Provide direct manipulation and graphical input.
• Reflect object and application status.
• Avoid unnecessary reporting.
• Don't use dialogs to report normalcy.
• Avoid blank slates.
• Ask for forgiveness, not permission.
• Differentiate between command and configuration.
• Provide choices; don't ask questions.
• Hide the ejector seat levers.
• Optimize for responsiveness; accommodate latency.
• Eliminate excise wherever possible.
• Don't weld on training wheels.
• Don't stop the proceedings with idiocy.
• Don't make users ask for permission.
• Allow input wherever you have output.
• Inflect the interface for typical navigation.
• Users make commensurate effort if the rewards justify it.
• The computer does the work and the person does the thinking.
• Software should behave like a considerate human being.
• If it's worth the user entering, it's worth the application remembering.
• Most people would rather be successful than knowledgeable.
• All idioms must be learned; good idioms need to be learned only once.
• Never bend your interface to fit a metaphor.
• A visual interface is based on visual patterns.
• Visually distinguish elements that behave differently.
• Visually communicate function and behavior.
• Take things away until the design breaks, then put that last thing back in.
• Visually show what; textually tell which.
• Obey standards unless there is a truly superior alternative.
• Consistency doesn't imply rigidity.
• Managing disks and files is not a user goal.
• Save documents and settings automatically.
• Put files where users can find them.
• Disks are a hack, not a design feature.
• An error may not be your fault, but it's your responsibility.
• Audit, don't edit.
• Rich visual feedback is the key to successful direct manipulation.
• Support both mouse and keyboard use for navigation and selection tasks.
• Use cursor hinting to show the meanings of meta-keys.
• Single-click selects data or an object or changes the control state. “
• Mouse-down over an object or data should select the object or data.
• Mouse-down over controls means propose action; mouse-up means commit to action.
• Visually communicate pliancy.
• Use cursor hinting to indicate pliancy.
• The selection state should be visually evident and unambiguous.
• Drop candidates must visually indicate their receptivity.
• The drag cursor must visually identify the source object.
• Any scrollable drag-and-drop target must auto-scroll.
• Debounce all drags.
• Any program that demands precise alignment must offer a vernier.
• A dialog box is another room; have a good reason to go there.
• Provide functions in the window where they are used.
• The utility of any interaction idiom is context-dependent.
• A multitude of control-laden dialog boxes doth not a good user interface make.
• Use links for n”avigation, and buttons or butcons for action.
• Distinguish important text items in lists with graphic icons.
• Never scroll text horizontally.
• Use bounded controls for bounded input.
• Use noneditable (display) controls for output-only text.
• Use menus to provide a pedagogic vector.
• Disable menu items when they are not applicable.
• Use consistent visual symbols on parallel command vectors.
• Toolbars provide experienced users fast access to frequently used functions.
• Use ToolTips with all toolbar and iconic controls.
• Put primary interactions in the primary window.
• Dialogs are appropriate for functions that are out of the main interaction flow.
• Dialogs are appropriate for organizing controls and information about a single domain object or application function.
• Use verbs in function dialog title bars.
• Use object names in property dialog title bars.
• Visually differentiate modeless dialogs from modal dialogs.
• Use consistent terminating commands for modeless dialog boxes.
• Don't dynamically change the labels of terminating buttons.
• Inform the user when the application is unresponsive.
• Never use transitory dialogs as error messages or confirmations.
• All interaction idioms have practical limits.
• Don't stack tabs.
• Error message boxes stop the proceedings with idiocy and should be avoided.
• Make errors impossible.
• Users get humiliated when software tells them they failed.
• Do, don't ask.
• Make all actions reversible.
• Provide modeless feedback to help users avoid mistakes.
• Offer shortcuts from the Help menu.
• Offer users a gallery of ready-to-use templates.

.

file link - Google Schloar, XXC