(Note: This ended up being more of a “design basics for non-designers” type of talk, rather than a talk aimed toward designers.)

Opening Thoughts
“We learn to describe the things we see, but we also see the things we describe.” - David Womack
As developers, we can tell often good from bad design but have a hard time articulating why, especially in visual design. (Bri’s opinion: This is true.)

“Is design the new black?” (aka it’s everywhere, but often used in a really vague way)
Fields of design: visual, interaction, information, service

What a “good” design is depends on the perspective of the user. “Good for whom?”
Have to know who your users are, and design for all of them. Prioritize users.

He used that layer diagram from Jesse James Garrett that we’ve all seen a million times.

Strategy
- what the heck are we doing?
- find the overlap between user needs and company/developers’ goals.
- know your stakeholders & site objectives
- traditional demographic methods (demographic profiles) don’t really give too much help in designing web apps
- Have to talk to/observe users
- Write a mission for your site or app that is not too general and not too specific

Scope
- what features go in
- don’t try to be everything to everyone
- avoid an algorithmic or voting-based approach to feature selection; have to select initial features as a coherent set that makes sense together, in context
- old model: first the cake, then the filling, then the icing
- new model: start with a cupcake, grow into a birthday cake, evolve into a wedding cake
- providing an API allows you to draw upon the efforts of passionate users

Structure
- how the pieces fit together; interaction design and information architecture
- interaction model needs to be consistent throughout the site; think modular/reusable when thinking about interactions
- have navigation elements at a consistent level of granularity
- use the language of the customer, not internal language
- use labels consistently across the site

Skeleton
- discoverability: make finding things easy
- use non-intrusive invitations to access more information
- provide helpful, contextual information based on what the user does
- recoverability: make actions without cost
- don’t lose any information upon errors
- provide error notification as quickly as possible, and clearly associated with the site of the error
- provide ability go back or change options without having to redo things that remain the same (live filters, etc.)
- prevent errors when possible by helping the user with just-in-time, contextual information (autocompletes, live password checkers, etc.)
- context: use time, place, and actions to add meaning
- tell users where they are in a process
- help them see where they came from and where they can go next
- feedback: let users know you saw what they did
- don’t include extraneous information in feedback (internal error numbers, etc.)
- keep feedback minimal, “just enough”
- use added item indicators, progress indicators
- ajax allows action at a distance (parts of the page affecting each other), but be careful with it
- make sure that updated areas are going to be visible to the user (could they scroll down and not see it? etc.)
- “not-suck-ability”
- many little annoyances are worse than one big annoyance
- minor annoyances that the user interacts with a lot can kill the user experience

Surface
- design is not just cosmetic, but visual design is also important
- attractiveness bias exists, might as well take advantage of it for your web app
- first impressons are important! people make a judgment in 1/20th of a second
- What is the personality of your site? How can the design/content of the site reflect that?
- recommends on visual design: “The Non-Designer’s Design Book”
- CRAP: contrast, repetition, alignment, proximity

A note on documentation:
- wireframes used to work really well for conveying layout
- what about when a page can have 27 different states?
- dev/des have to work more closely together
- some options:
- storyboards
- frame-by-frames
- wireframes with key frames of the interaction
- D.V. recommends “something more like a prototype”
- lo-fi animations (basic Flash, etc.)
- working prototype on which designers and developers are acting closely together

Prototype flavors:
- HTML/CSS/JavaScript with no backend
- working frontend drawing on xml/json instead of a “real” backend
- functional backend with a non-production backend language/architecture (e.g. Rails)

Have to work with the team that you have - what works best to increase/enable communication?