About face 3 /Cooper, Reimann & Cronin(2007)

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


心理模型與實現模型 | Mental model & Implementation model

Role Alan Cooper Donald Norman
使用者(User) 心理模型(Mental model)或概念模型(Concept model)
設計師(Designer) 表現模型(Represented model) 設計者模型(Designer model)
(Design/Object/Software) 實現模型(Implementation model) 系統模型(System model)

暫定的人物角色 Provisional persona

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


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


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

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

Design Principles 設計原則

  • 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