Acknowledgments -- Author biography -- Defining the obvious -- What is 'the obvious'? -- Qualities of a great application -- 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 -- Understand users, then ignore them -- Understand how users think they do things -- Understand how users actually do things -- Mental models -- Know how to uncover reality -- Assume nothing -- Use surveys -- Contextual inquiry -- Remote-user research -- To persona or not to persona? -- Design for the activity -- Task-flow diagrams -- Write use cases -- Faster than code and capable of producing real results -- Writing exceptions -- The argument against use cases -- My advice.
Build only what is absolutely necessary -- More features, more frustration -- So what's a geek to do? -- Think different -- The dashboard and new invoice screen -- The finished invoice -- Goodies for experts -- The result -- Drop nice-to-have features -- The unnecessary test -- The 60-second deadline -- Less is more -- Interface surgery -- Reevaluate nice-to-have features later -- Let them speak -- Support the user's mental model -- Design for mental models -- Making metaphors that work -- Interface surgery : converting an implementation-model design into a mental-model design -- Eliminate implementation models -- Create wireframes to nail things down -- Prototype the design -- Test it out -- Turn beginners into intermediates, immediately -- Use up-to-speed aids -- Provide a welcome screen -- Offer tips -- Fill the blank slate with something useful -- Give instructive hints -- Interface surgery : applying instructive design -- Choose good defaults -- Integrate preferences -- Design for information -- 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.
Handle errors wisely -- Prevent and catch errors with poka-yoke devices -- Poka-yoke on the web -- prevention devices -- Detection devices -- Turn errors into opportunities -- Feeling smart -- Ditch anything modal -- Redesigning rude behavior -- Replace it with modeless assistants -- Write error messages that help instead of hurt -- Interface surgery : using the inline-expand design pattern -- Create forgiving software -- Good software promotes good practices -- Design for uniformity, consistency, and meaning -- Design for uniformity -- Be consistent across applications -- Understanding design patterns -- Intelligent inconsistency -- Leverage irregularity to create meaning and importance -- Reduce and refine -- Cluttered task flows -- Clean up the mess -- Reducing the pixel-to-data ratio -- Minimizing copy -- Designing white space -- Cleaning up task flows -- Practice Kaizen -- The 5S approach -- Eliminate waste -- Cleaning up your process -- Put just-in-time design and review to work.
Don't innovate when you can elevate -- Innovation -- The problem with innovative thinking -- Elevation -- Elevate the user experience -- Elevation is about being more polite -- Elevation means giving your software a better personality -- Elevation means creating "On-demand interfaces" -- Seek out and learn from great examples -- Inspiration -- Elevate the standards -- Take out all the good lines -- Get in the game -- Index.
|
