Started 6:47pm

Chapter 1: Defining the Obvious

Intro The Web World is divided into people/interface/data

What is the Obvious Easy to learn, well-organized Interface elements should be intuitive, streamlined, and uniform

How Do You Design the Obvious Turn qualities into goals

The Framework for Obvious Design Know what to build Know what makes it great Know the best ways to implement it

Chapter 2: Understand Users, Then Ignore Them

Understand How Users Think They Do Things ^^

Understand How Users Actually Do Things

We tend only to use 20% of what the application is capable of doing Mental model ("what I believe to be true")

Know How to Uncover Reality Assume nothing (about users) Use surveys (to find users)

Contextual inquiry (ethnographic research in which the researcher lives and works with people in a particular culture) Shadowing (quietly hover over

Remote-user Research: Skype, or vid conference to understand stuff about your users persona: user profile focused on goals and activities, rather than demographics Goal-Directed Design: used to help designers better understand the goals of users so systems can be designed to help them meet those goals

Design for the Activity people adapt to technology

Activity-Centered Design: technology is not good because of deep understanding of users, but activities Task-flow diagram: flowchart that details how a user will complete all the task in an application from beginning to end

Write Use Cases faster than code and capable of producing real results

writing exceptions(sub-use cases that detail what happens when the main use case cannot be followed end to end) kaizen: "change for the better", constant improvement

Chapter 3: Build Only What Is Absolutely Necessary

Intro more features, more frustration

Think Different Blinksale example (nice dashboard etc..)

Drop Nice-to-Have Features The unnecessary test: ask yourself questions and take out unnecessary features The 60-second deadline: given 60 seconds, write down a list of features most important to an application; the rest aren't important less is more use interface surgery reevaluate nice to have features later let users leave feedback

Chapter 4: Support the User's Mental Model

Intro mental model: what we believe to be true, based on our experiences implementation model: something that has been designed to reflect the details of a system

Design for Mental Models use pretty features making metaphors work (backpack physically and the app) converting implementation model to mental model

Eliminate Implementation Models create wireframes to nail things down three r's: requirements, reduction, regularity kaizen, applied to wireframes

Prototype the Design paper prototyping html click through mockups

Test It Out browserless self-test (don't use back and forward buttons)

five second test (ask users to write down what they saw after looking at app for five seconds) product) interview testing (user testing) contextual usability testing (watching users interact with your

eat your own dog food (use the products you make)

Chapter 5: Turn Beginners Into Intermediates, Immediately

Use Up-To-Speed Aids use "up-to-speed aids": get a user up to speed in Web applications

wizards: screen sequences designed to get a user acquainted to settings of an application know Provide inline tips (quick, unobtrusive access to info) lens: Squidoo content page Welcome screen gives information for features users will need to

instructive design: design used to instruct user within current task without being intrusive (ex. default value within form field Interface surgery is necessary for applying instructive design (ex. default value in text fields, required fields, disabled buttons, inline error messages)

Choose Good Defaults choose good defaults because users don't want to customize them settings can be seamlessly integrated in the main application

Design for Information Methods of Seeking Information and How to Design for Them:

1) known item: (users know what they are looking for) 2) exploratory: (users know what they are looking for but unable to put it into words) 3) don't know what you need to know: (users think they need to find one thing, but need to find something else) 4) re-finding: (users are attempting to find something they already found before)

 Card sorting: features on index cards organized by users (diff. type of users); see how they place features by importance

Stop Getting Up to Speed and Speed Things Up reuse the welcome screen as a notification system use one-click interfaces use design patterns to make things familiar

Provide Help Documents, Because Help Is for experts provide help docs only for people who need them like experts

Chapter 6: Handle Errors Wisely

Prevent and Catch Errors with Poka-yoke Devices poka-yoke is the japanese term for "mistake-proofing"; a device that is used to prevent an error (ex. Irons auto shut after a while to prevent fires) prevention device: prevents errors from occurring (ex. a Dashboard that makes it impossible to mess up when adding new content) detection device: let users know when prevention doesn't work (ex. if you are editing a Dashboard, write a code, device, to show the error message to the user immediately) use quality error pages

use inline-validation to real-time check & verify that an action is being completed correctly (ex. new password) screw up) turn errors into opportunities (ex. Google Suggest when people

help users feel smart (-_______________-)

Ditch Anything Modal 1) modeless: change anything in a dialog while still interacting with the document 2) document-modal: prevents user from doing anything else within a document, can switch 3) application-modal: prevents user from doing anything else within an application, can switch to another application

redesigning rude behavior (mean error messages)

replace it with modeless assistant (nice gmail messages asking to undo at the top of screen)

Write Error Messages That Help Instead of Hurt use nice language "we're sorry that"

inline-expand design pattern for FAQ pages: when you click a question, the answer expands

Create Forgiving Software Good software promotes good practices.

Chapter 7: Design for Uniformity, Consistency, and Meaning

Design for Uniformity

Be Consistent Across Applications

Leverage Irregularity to Create Meaning and Importance

Chapter 8: Reduce and Refine

Intro

Clean Up the Mess

Practice Kaizen

Eliminate Waste

Put Just-in-time Design and Review To Work

Chapter 9: Dont Innovate When You Can Elevate

Innovation

Elevate the User Experience

Seek Out and Learn from Great Examples

Elevate the Standards

Take Out All the Good Lines

Get in the Game