Controls

Most designs have some sort of visible controls to manipulate the features of the product (exception: voice and gestural interactions). Controls provide both the affordances needed to understand what the product is capable of, and the power to realize that capability. Some basic controls:

1. Switch - toggle on / off
2. Button - toggle button or that automatically resets (ex: keyboard)
3. Radio button - allows users to select items in a set - used to constrain selection
4. Dial - allows users to select a setting along a continuum or to choose between different settings or modes. Dials can move freely, or simply turn from an established point to other established point on a wheel. These points are called "detents". Some dials can be pushed in / pulled out (on / off).
5. Latch - opens an otherwise tightly closed area. Useful for keeping some parts hidden or safe until needed. (ex: to open a battary compartment on a phone.
6. Slider - like dials (but linear) - used for subtle control. Sliders with more than one handle can be used to set a range within a range.
7. Handle - a protruding part of an object that allows it to be moved or resized (ex: handle on digital window).

• Physical-only controls: jog dial, joystick, trackball, 5-way.
• Digital-only controls: checkbox, twist, scroll bar, drop-down menu, multiple-selection list (or list box), text box, spin box. The combination of controls and the system response is called a widget. All applications and devices are made uop pf widgets.

Non-traditional Inputs

1. Voice - (ex: Siri) A device typically has to be redy to receive voice commands.
2. Gestures - (ex: Wii, smartphone accelerometers, Microsoft kinect) Issues to be aware of:
   • physiology and kinesiology - limitations, such as "gorilla arm"
   • presence and instruction - letting users know a gestural device is there and how to use it (ex: hands-free paper towel dispenser)
   • avoiding "false positives" - avoiding unintentional human movements
   • matching gesture to talk - figuring out the best motion to trigger an action
3. Presence - (ex: automatic lights). Challenge: determine how and when a user can become "invisible" to presence-activated systems.

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

Documentation and Methods of Refinement

Each document produced should take the project one step closer to completion. Methods to refine (improve) the design of a product:

1. Scenarios - stories about what it will be like to use the product or service once it has been made. Protagonists - personas. running each persona through a "fist-time use scenario" can reveal how to tailor the final design to appeal to and work for each persona.
2. Sketches and Models - visualizing concepts and ideas (currently - with physical tools and drawing surface). Most helpful when the ideas are still being formed to help clarify and communicate them.
3. Storyboards - image panels with accompanying text that can be drawn directly from scenarios. Helps to illustrate the product/service in use and key moments of an action.
4. Task Flows - putting tasks (defined in task analysis) into a sensible order/flow. Helps to see where the users will have to perform certain actions, where the decision have to be made and helps to clarify implementations of controls.
5. Use Cases - UML (for developers). Explains in plain language what a certain function does and why. Time consuming, but good for breaking down tasks and showing what the system will have to support. Form of a use case:
   1. A title - should be descriptive
   2. The actors - who is performing the function? (ex: user, system)
   3. The purpose - what is this use case meant to accomplish and why?
   4. The initial condition - what is happening when the use case starts?
   5. The terminal condition - ...ends?
   6. The primary steps - discrete moments in this piece of functionality.
   7. Alternatives - other use cases that may consider the same functionality.
   8. Other use cases used - the ones that this use case is built upon (if there is).
6. Mood Boards - means for designers to explore the emotional landscape of a product. Collage of images, words, colors, typography and others (audio, video..).
7. Wireframes - set of documents that show structure, informations hierarchy, controls and content. The most important document that interaction designers produce when working on product. Designers need to accomodate the needs of various audiences, who want to see different things in the wireframes:
   • Clients - how design meets their business goals.
   • Developers - how the product works (ex: what happens when an error occurs, so that they know what to code).
   • Visual/industrial designers - what visual/physical elements need to be designed (ex: types of buttons).
   • Copywriters - what they need to write (ex: help texts, manuals..)
   • Designers - to remember details (ex: why there are two buttons instead of one for a certain feature).
   Wireframes have three main areas:
   1. The Wireframe itself - a detailed view of a particular part of a product. Three factors:
      1. Content (ex: text, movies, images, icons, "placeholders" if the content is not ready yet)
      2. Control / functionality (ex: buttons, sliders, input boxes, knobs and accompanying labels and feedback to those controls)
      3. Navigation (ex: methods, such as hyperlinks, drop-down menus, toolbars with widgets and complex manipulations)
   2. Annotations - brief notes to understand not just what the feature (ex: button) does, but also why it is there. Wireframe objects that should be annotated:
      • Controls (ex: what happens when a button is pushed)
      • Conditional items (objects that change based on the content)
      • Constraints (anything with a business, legal, logical or technical constraint, ex: the longest length of a password allowed)
   3. Wireframe Metadata - information about the wireframe. Every wireframe sould include the following:
      1. The designer's name
      2. The date the wireframe was made or changed
      3. The version number
      4. What has changed since the last version
      5. Related documentation (ex: business requirements, technical specs, use cases.. with specific page number)
      6. Unresolved issues
      7. A place for general notes
8. Service Blueprint - "wireframes" for services. Two major elements:
   1. Service Moments - discrete moment that can be described (ex: customer pays).
      • There can be multiple designs for each moment (ex: pay with cash, debit, credit).
      • Which touchpoint is or could be used during each service moment? (ex: a sign listing the costs of services and an attendant who takes the customer's money). All of these elements should be designed.
      • Each moment should have visual representation (sketch, photograph).
      • What service elements are affected: the environment, objects, process, people invilved.
      • Designers should especially look for service moments that can deliver high value for low cost.
   2. Service Strings - putting concepts for various service moments together to form "storyboard / scenario" that demonstrate what the pathways through the service will be. Big idea for the service in written and visual form.

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

Frameworks

"Every product needs a framework: an actual or metaphysical structure that defines the product and integrates the content and functionality into a unified whole." There are three main kinds of frameworks that can be applied to a product:

1. Metaphor.
   A way for users to understand abstract concepts (ex: GUI, dashboards and control panels)
2. Postures.
   Common types of structures for the design of software (called by Alan Cooper):
   1. Sovereign: for complex, large and that take up a large portion of the screen when in use (ex: Ms. Word).
   2. Transient: for temporary and light applications that use only a small amount of screen estate (ex: installers, widgets, calc)
   3. Daemonic: for the ones that mostly run in the background (ex: anti-viruses, Growl). The controls are mostly limited to setup and configurations.
   4. Parasitic: for applications that supplements another application or service. (ex: Tweet-Deck)
3. Structure.
   Layout of panels in the application, interplay between hardware and software. Methods to determine the structure:
   1. Functional Cartography: determine the location of functional pieces of the product. Designers need to decide on if the controls for the functionality are analog (ex: physical buttons), digital (onscreen controls) or a hybrid (ex: soft keys). It should be documented in order to help designers with sketching, modeling and prototyping. Factors considered when deciding on the cartography:
      • Context: where and when will the functionality be used?
      • Priority: how important is this functionality?
      • Cost: how much is it gonna cost?
      • Ergonomics: what is the easiest to use for the users?
      • Aesthetics: does it match the overal design?
      • Tangibility: how tactile does it need to be?
   2. Site / Screen / State Maps: determine how the pieces of functionality flow and how users navigates between them (ex: site maps on the web - accessed by hyperlinks) in order to unify the product.
      • The organization of the content is the discipline of Information Organization.
      • State - particular moment in the interaction:
        1. Initiation: default state - how does it look like, what to do in order to change it?
        2. Activation: what happens during the action (ex: while the item is dragged)
        3. Updates: state after the user finished an action.
      • Mode - general condition that allows for different functionality / states to be accessed. (ex: "editing" mode)

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

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

• Generate MANY concepts as rapidly as possible.
• Sketch - "..because of the limitations of today's available technology, brainstorming should never be done digitally; it should be done with paper, pencils, pens, markers, and possibly whiteboards and sticky notes."
• Doesn't have to be limited to designers only. All othere stakeholders should participate.
• "Rules" of brainstorming:
  1. There are no bad ideas.
  2. Stay focused.
  3. Don't spend a lot of time on any one idea.
  4. Use the whole room.
  5. No multitasking.
• Start with a warm-up exercise - association game, mind maps. Point is to get brains, hands, and mouths engaged.
• Set aside a fixed amount of time. Allow breaks. Ideal to spread brainstorming over several days.
• Set aside most of what you know about the technical, user, or business constraints.
• Focus points to brainstorm around:
  1. Pain Points: part of the process or activity is problematic or difficult.
  2. Opportunities: known places for innovation
  3. Process Moments: known steps in the activity
  4. Personas: focusing on addressing the direct expectations, motivations, and behaviors of one particular persona.
  5. Metaphors: sometimes, the oddest metaphors will uncover a previously unthought-of direction for the design.
Brainstorming techniques for interaction designers:
1. Brainwriting: one person writes down or sketches the beginning of an idea. Others continue the idea one by one.
2. Break the Rules: figure out how to break the constraints.
3. Force Fit: distilling the problem down to two words that are in opposition, ex "intense peace."
4. Poetry: reduce the problem down to a short poem. Makes you figure out what is most important.
5. Questioning: start with a very general concept and keep asking two questions: how and why.
6. Laddering: moving "up" to a level of abstraction or moving "down" to something concrete
7. Swiping: stealing the best ideas from another field or domain.
8. Bizarro World: inverting everything: opposite product, good is bad..

• Organizing the concepts: cluster, name, and sort all the ideas you've created so that it is easy to examine and discuss them.

Design Principles

• "Mantras", "a set of phrases designed to help guide design decisions throughout the remainder of the design process - and even beyond, after the product launches."
• Almost as design requirements, except they are general statements that should apply across the project. If you can't apply it to more than one feature, it's probably a requirement, not a principle.
• Design principles are a combination of:
  1. What is known about the users, the context of use, and the design strategy.
  2. The best ideas that emerged from brainstorming.
  3. What the designer thinks is necessary for a successful project
• The best design principles are:
  1. Pithy: a short phrase.
  2. Memorable: funny, witty, and provocative statements
  3. Cross-feature: should be applicable across the product
  4. Specific: easy to Use is not a design principle.
  5. A differentiator: if they can be applied to a competitor, then they probably aren't specific enough.
  6. Non-conflicting: with each other
• You can use design principles as a measuring stick against the concepts you've generated to see which ones best fit.

References and more info

• Dan Saffer, "Designing for Interaction: Creating Innovative Applications and Devices", 2nd Edition, (2009), chapter 6
• Ideation and Design Principles Workshop slides by Dan Saffer.
• Design for Interaction: Ideation and Design Principles chapter as a blog post by Dan Saffer.
• Human-Computer Interaction & Cognition: reading list

All sciences require evidence based on careful observation and experimentation. To collect data systematically and objectively, psychologists use a variaty of research methods:

• Multimethod Research: Studies often combine several methods
• The Importance of Sampling in Research
  1. Sample: Small representative subset of a larger populationpopulation
  2. Random sample: Every subject had equal chance of being selected
  3. Representative sample: Characteristics of participants correspond to larger population

Ethics and Psychology

• The first code of ethics was published in 1953
• After Milgram's Obedience to Authority Experiment (1963) a new code of ethics on psychological experimeentation was approved.
• The APA code of ethics requires that:
  1. Researchers obtain informed consent from participants
  2. Participants must be informed of nature of research. Deception about the goals of research used only when absolutely necessary.
  3. Risks and limits on confidentiality must be explained.
  4. Deception cannot be used about aspects of research that would affect participant's willingness to participate
  5. If participation is a course requirement in an academic setting, alternative activities must be offered
• Researchers are required to follow goverment's set of regulations conserning the protection of human participants in all kind of research

References and more info

• Milgram's Obedience to Authority Experiment videos: 1st part, 2nd part, 3rd part
• Morris & Maisto, "Understanding Psychology" (2007), chapter 1 pp. 26-35
• Human-Computer Interaction & Cognition: reading list

1. Understanding the current state of a design
2. Understanding key competitors
3. Conducting Stakeholders* interviews
4. Conducting Heuristic analysis

Heuristic analysis

Notes

• *Stakeholder: anyone who has a significant interest in an enterprise. For example:
  1. Your bosses (Specialists in UXD, ID, HCI, psychology; Investors; Project Leaders)
  2. Development team (Programmers, engineers, etc.)
  3. End users (People who use the interface the most)

References

1. Russ Unger and Carolyn Chandler "A Project Guide to UX Design: For user experience designers in the field or in the making" (2009), pp 70-73: Heuristic analysis
2. Human-Computer Interaction & Cognition: reading list

My inspiration for the last couple of years has been Sheryl Sandberg, Facebook COO, internet entrepreneur and an awesome visionary woman. I would highly recommend watching her TED talk entitled "Why we have too few women leaders" where she gives 3 powerful advices for women who want to "make it to the top" of any profession they are in.

Here are a few links for more interesting and inspiring information:

• "A Woman's Place: Can Sheryl Sandberg upend Silicon Valley's male-dominated culture?" New Yorker [article]
• "Facebook's Sheryl Sandberg on what makes women succeed" Fortune [interview]
• "Sheryl Sandberg And Motherhood: Why Kids Help Us Become Better Executives" Forbes [article]
• Sheryl Sandberg Wikipedia [bio]