Introduction

• Refinement of design concepts is about:
  • making smart, deliberate choices about how the concept would work and could be built given the known constraints
  • using the known laws of interaction design to guide design choices
  • putting in the right affordances and feedback so that users can create the right mental model of the product in order to properly use it.
• "Constraints define the product more than one cares to admit. The best designers are those who can juggle the most constraints." Some of the constraints can be: time, money, technology, business needs, user needs, context, tools, teams, you.

The Law and Principles of Interaction Design

All projects should follow general principles and fundamentals of Interaction Design:

1. Direct & Indirect Manipulation.
   Digital objects can be manipulated 2 ways:
   1. Direct manipulation - introduced by Ben Schneiderman in early 80s. Manipulation directly on an object (with mouse, fingers). Mimics an action from similar object in physical world. More easily learned and used.
   2. Indirect manipulation - manipulation through other means that isn't directly a part of the digital object to alter that object (menus, keyboard shortcuts, etc.)
2. Affordances.
   Introduced by James Gibson in 1966, spread into design by Don Norman in 1988. Propert(ies) that provide(s) some indication of how to interact with an object or feature. Interaction design - providing affordances so that the features and functionality of a product can be discovered and correctly used.
3. Feedback & feedforward.
   1. Feedback - indication that something has happened. Designer's task is to design the appropriate feedback, how quickly the product or service will respond and in what manner. Latency - the time between an action and the product's response. Responsiveness of the product can be: immediate, stammer, interruption, disruption.
   2. Feedforward (called by Tom Djajadiniiigrat) - knowing what will happen before you perform an action. It allows users to perforin an action with confidence. Examples - messages ("Pushing this button will...") or cues such as hypertext links with descriptive names instead of "here".
4. Mental Model.
   User's internal understanding of how a system works, which may or may not reflect how the thing actually works. Mental models are constructed by users from cues provided by the designer in the form of affordances, feedback and feedforward. More info in Don Norman's book "The Psychology of Everyday things".
5. Standarts.
   Interface standards. "Obey standards unless there is a truly superior alternative" - Alan Cooper.
6. Fitt's Law.
   Introduced by Paul Fitts in 1954. The time it takes to move from a starting position to a final target is determined by two factors: the distance to the target and the size of the target. Three implications for interaction design:
   1. Clickable objects must be reasonable size (esp. true for touchscreens - the smaller the object, the harder it is to select.
   2. Edges & corners are huge targets and good place for menu bars & buttons.
   3. Context menus next to object can be reached more quickly than pull-down menus.
7. Hick's Law / Hick-Hyman Law.
   The time it takes for users to make decisions is determined by the number of possible choices they have: "..user will more quickly make choices from one menu of 10 items than from two menus of 5 items each". Decision time depends on number of choices, familiarity with choices, format of choices.
8. Magical number 7.
   Introduced by George Miller in 1956. Short term memory works best with 7 items +/- 2. If exceeds - cognitive overload - people begin to make mistakes.
9. Tesler's Law of the Conservation of Complexity.
   There is point beyond which you can't simplify further. Designer's goal - shift complexity to the software. (ex: autocomplete)
10. Poka-Yoke Principle ( = "avoiding errors").
    Introduced by Shigeo Shingo in 1961. Put constraints on products to prevent errors, forcing users to adjust their behavior and correctly execute an operation.
11. Errors.
    System should present error message only when the system failed. It should provide a way to fix the error, or provide information why the error occurred.

References and further readings

• Dan Saffer, "Designing for Interaction: Creating Innovative Applications and Devices", 2nd Edition, (2009), chapter 7
• The rest of the summary of Chapter 7 "Refinement": Frameworks, Documentation and Methods of Refinement, Controls and Inputs
• Human-Computer Interaction & Cognition: reading list