INTRO

History
1970s, 1980s… software design -> user interface design -> user experience design

Digital systems with complex behaviours (thousands of states!)

Try to design behavior -> experience

Form - Content - Behavior

4 main steps to designing interactive systems:

• Researching the domain
• Understanding the users and their requirements
• Defining a solution’s framework
• Filling in the design details

• (validation)

  
  

  Part 1

  

  Ch 1 A design process for digital products

• Planning and designing product behavior

  • Understanding how the human using the product live and work
  • Designing product behavior and form that support and facilitate the human behaviors
  • A successful product is desirable, viable and buildable
    • Desirability - designer - user effectiveness and customer adoption
    • Viability - management - sustainable business
    • Capability - technologists - project delivery
  • Behavior-oriented design - goal-directed design
• Recognizing user goals
  • Focusing on activities is not enough
  • Goals in context
• Implementation models and mental models
  • Implementation models - describe the details of how an application is implemented in code
  • Mental models (conceptual model)
  • Represented models (designer’s models)
  • [Goal-directed interactions reflect user mental models]
• An overview of goal-directed design
  • Designers as researchers
    • Empathy
    • Pure researchers can hardly know what user information is really important from a design perspective
  • Between research and blueprint: models, requirements, and frameworks
• A process overview
  • 

• Understanding, abstracting, structuring, representing, detailing (five component activities of interaction design identified by Gillian Crampton Smith and Philip Tabor)

• Research
  • Ethnographic field study (observation, contextual interviews)
  • Competitive product audits
  • Reviews of market research, technology white papers, and brand strategy
  • One-on-one interviews with stakeholders, developers, subject matter experts (SMEs) and technology experts
  • Main outcomes of field observation and user interview: an emergent set of behavior patterns
  • Behavior patterns and the goals associated with them -> personas
  • Market search: select and filter valid personas that fit business models
  • Stakeholder interviews, literature reviews, and product audits deepen our understanding of the domain and elucidate business goals, brand attributes, and technical constraints
  • Detailed flow of design P25 (55/722)
• Modeling
  • Domain models: information flow, work flow diagrams
  • User models (personas): detailed, show distinct groupings of behaviors, attitudes, aptitudes, goals and motivations
• Requirements definition
  • For each interface/persona: analyze persona data and functional needs
  • Iteratively refined context scenario
  • Output: a requirements definition that balances user, business, and technical requirements of the design to follow
• Framework definition
  • Create the overall product concept (basic framework: behavior, visual design, physical form)
  • Interaction framework <- context scenarios, IXD principles, IXD patterns
  • data and functional needs (high level) -> design elements (IXD principles) -> design sketches and behavior descriptions (IXD patterns and principles)
  • Output: an interaction framework definition. Provide the logical and hi-level formal structure
• Refinement
  • Focus on detail and implementation
• Development support
  • Scaled-down design solutions…

Goals: the key to product success
“Interaction design is not guesswork.”

CH 2 Understanding the problem: design research

Behavioral and organizational knowledge <- qualitative research techniques

• Qualitative research helps us understand a product’s domain, context, and constraints
• Qualitative research is a useful tool to characterize user behaviors and latent needs, yet it cannot help stakeholders know the market sizing of the behavioral models -> quantitative techniques!
• 
• Goal-directed design research
  • Some useful goal-directed design practice
    • Kickoff meeting
      • May provide clues about how to structure stakeholder and user interviews
      • Provide pointers to understanding the product domain
    • Literature review
      • Internal documents
      • Industry reports
      • Web searches
    • Product/prototype and competitive audits
      • Examine existing version of the product and its chief competitors
      • Engage in an informal or expert review of both the current design and competitive product interfaces (interaction and visual design principles)
    • Stakeholder interviews
      • Talking to the people responsible for managing and building the product, to understand restrictions…
      • Should occur before user research begins
      • Most effective to interview each stakeholder in isolation (avoid individual vires being lost in a crowd)
      • Not longer than an hour
      • Important types of information
        • Preliminary product vision - harmonizing all the perspectives with those of users
        • Budget and schedule
        • Technical constraints and opportunities
        • Technical constraints and opportunities
        • Business drivers
        • Stakeholders’ perception of their users
      • Help develop a common language and understanding
    • Subject matter expert (SME) interviews
      • SMEs are often expert users
      • SMEs are knowledgeable, but they aren’t designers
      • SMEs are necessary in complex or specialised domains
      • You will want access to SMEs throughout the design process
    • User and customer interviews
      • Users and customers are often not the same
      • Customer interview
        • Those who decide to purchase it… goal: make a product viable
      • User view
        • Our main focus
        • Interesting information
          • The context of how the product fits into their lives or work flow
          • Domain knowledge
          • Current tasks and activities
          • Goals and motivations
          • Mental model
          • Problems and frustrations
    • User observation/ enthnographic field studies
      • Users might be reluctant to talk about anything they find problematic or incomprehensible
      • Most effective technique to gather qualitative data: interviewing and observation
      • Man-on-the-street approach: casually observe product-related behaviours
    • Interviewing and observing users
      • contexual enquiry (an ethnographic interviewing technique, by Hugh Beyer and Karen Holtzblatt)
        • context - normal work environment
        • partnership - take the tone of a collaborative exploration with the user
        • interpretation - be careful to avoid assumptions based on their own interpretation of the facts
        • focus - the designer needs to subtly direct the interview

CH3 Modeling users: personas and goals

CH4 Setting the vision: scenarios and design requirements

CH5 Designing the product: framework and refinement

CH6 Creative teamwork

Part 2

A Basis for Good Product Behavior

Design Values: guidelines for successful and appropriate practice of design.
Design Principles: guidelines for the design of useful and desirable products.
Design Patterns: exemplary, generalizable solutions to specific classes of design problems.

Designers should create design solutions that are:

• Ethical (considerate, helpful)
  • Do no harm
  • Improve human situations
• Purposeful (useful, usable)
  • Help users achieve their goals and aspirations
  • Accommodate user contexts and capacities
• Pragmatic (viable, feasible)
  • Help commissioning organizations achieve their goals
  • Accommodate business and technical requirements
• Elegant (efficient, artful, affective)
  • Represent the simplest complete solution
  • Possess internal (self-revealing, understandable) coherence
  • Appropriately accommodate and stimulate cognition and emotion

Principles operate at different levels of detail. Interaction design principles generally fall into the following categories:

• Conceptual principles: what digital products should be like and how they fit structurally into the broad context of use required by their users.
• Behavioral principles: how a product should behave—in general and in specific contexts
• Interface-level principles: effective strategies for the organization, navigation, and communication of behavior and information.

Design Etiquette

P179

Part 3

Appendix Design Principles

Chapter 1
User interfaces should be based on user mental models rather than implementation
models.
Goal-directed interactions reflect user mental models.
Interaction design is not guesswork.
Chapter 3
Don’t make the user feel stupid.
Focus the design for each interface on a single primary persona.
Chapter 4
Define what the product will do before you design how the product will do it.
In the early stages of design, pretend the interface is magic.
Chapter 5
Never show a design approach you’re unhappy with; stakeholders just might like it.
There is only one user experience: Form and behavior must be designed in concert.
Chapter 8
The computer does the work, and the person does the thinking.
Software should behave like a considerate human being.
If it’s worth it to the user to do it, it’s worth it to the application to remember it.
Chapter 9
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.
Chapter 10
Don’t weld on training wheels.
Nobody wants to remain a beginner.
Optimize for intermediates.
Inflect the interface for typical navigation.
Users make commensurate effort if the rewards justify it.
Imagine users as very intelligent and very busy.
Chapter 11
No matter how cool your interface is, less of it would be better.
Don’t use dialogs to report normalcy.
Ask forgiveness, not permission.
Chapter 12
Eliminate excise wherever possible.
Don’t stop the proceedings with idiocy.
Don’t make users ask for permission.
Allow input wherever you have output.
Significant change must be significantly better.
Chapter 13
Most people would rather be successful than knowledgeable.
Never bend your interface to fit a metaphor.
All idioms must be learned; good idioms need to be learned only once.
Rich visual feedback is the key to successful direct manipulation.
Visually communicate pliancy whenever possible.
Chapter 14
An error may not be your application’s fault, but it is your application’s responsibility.
Audit, don’t edit.
Save documents and settings automatically.
Put files where users can find them.
Chapter 17
Visually distinguish elements that behave differently.
Visually communicate function and behavior.
Take things away until the design breaks, and 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.
Chapter 18
The utility of any interaction idiom is context-dependent.
A dialog box is another room; have a good reason to go there.
Provide functions in the window where they are used.
Use menus to provide a pedagogic vector.
Disable menu items when they are not applicable.
Use consistent visual symbols on related commands.
Toolbars give experienced users fast access to frequently used functions.
Use ToolTips with all toolbar and iconic controls.
Support both mouse and keyboard use for navigation and selection tasks.
Use cursor hinting to show the meanings of metakeys.
Single-clicking selects data or an object or changes the control state.
Double-clicking means single-clicking plus action.
Mouse-down over an object or data should select the object or data.
Mouse-down over controls means proposing an action; mouse-up means committing to
an action.
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.
Chapter 19
Most mobile apps have transient posture.
Limit the number and direction of animated screen transitions.
Use guided tours to orient first-time users.
Use overlays to explain gestures.
Chapter 20
Use persistent headers to maintain context.
Breadcrumbs with lateral links help speed navigation.
Auto-complete, auto-suggest, and faceted search help users find things faster.
Make scrolling an engaging experience.
Infinite scrolling and site footers are mutually exclusive idioms.
If you have only one version of your site, make it responsive.
Use links for navigation and buttons for action.
Distinguish important text items in lists with graphic icons.
Avoid scrolling text horizontally.
Use bounded controls for bounded input.
Use noneditable (display) controls for output-only text.
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.
Differentiate modeless dialogs from modal dialogs.
Do not use terminating button commands for modeless dialogs.
Don’t dynamically change the labels of terminating buttons.
Inform the user when the application is unresponsive.
Never use transitory dialogs as error messages, alerts, or confirmations.
All interaction idioms have practical limits.
Don’t stack tabs.
Most error dialogs stop the proceedings with idiocy.
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.