Practical Design for Developers

I've been taking some notes as I listen to the various talks at Railsconf 2007. I thought I'd try taking notes live as I listen to a talk. The last one I attended, by Jarkko Laine, was awful. It was a bit too high level. It didn't help to listen to Jarkko's halting speech. I understand he can probably speak a dozen languages, but it is awfully distracting when there are stops all over the place. But beyond that, the content was very light. I thought Matthew Bass's (oh, he's sitting in the row behind me!) was light too, but was at least interesting to follow.

David Verba has started talking. He's working for Adaptive Path, which does some UI stuff.

It appears his notion of design is more visual, rather than structuring code. This is the problem with a vague word like design. He wants to present a framework for understanding design.

Design, in this case, appears to be from the users' perspective. How well does the design work for the users. The application he's talking about is a self evaluation for teachers. It was originally a desktop app, but for whatever reason, they moved it to the web.

Since self-evaluation requires a long time, and teachers lack time, adding features to indicate how far along you are is useful. He says that you really have to understand who your users are. In the case of teachers, they can only work in short breaks.

He uses low fidelity wireframes to give users a sense of what's going on. Know their context, motivations, and challenges. He's referring to a book called "The Elements of User Experience".

Layer 1 is what it looks like. Skeleton, structure, scope, and strategy. These are design issues. Often developers control skeleton and structure.

The idea is to get between your goals and your user's needs. This is the so-called sweet spot. The stakeholders are the people who have an interest in the outcome of the product. Then, find out what they want. It's worth it, he says, to find out what they really want.

Functional spec describes what needs to be built. Companies often distinguish themselves. For example, Flickr emphasized sharing, even to the point of not having printing, which most other sites had. "Don't try to be everything to everyone!".

Launch with a core set of features, then fill out afterwards. This allows changes to occur over time.

So far, this sounds a lot like Matthew's talk. He talks about users and getting feedback. The biggest difference is Matt used a specific example of his own code, where David is covering more examples from all over (also including some stuff he worked on). He's explaining a diagram I've seen before from Jesse James Garrett, the guy that coined Ajax.

What's the interaction going to be like (pages, popups, layers?). It helps to have common UI elements so people get familiar with the site.

Also, worry about granularity. apple, pear, banana, and fruit aren't all at the same level. Think about it from the user's perspective: human resources, employment opportunities, jobs. Jobs is simpler.

Consistency refers to using the same terminology all over the place (e.g. "about us" vs. "who we are").

In many ways, this talk is about interaction design. For example, how do you decrease the amount of work that occurs when errors are made. Farecast, for example, allows for users to use sliders to change options so they can explore.

Overall, there appears to be a lot of good information, at a level that's not too hard to follow. It's a bit difficult to recall all of it, but I'm sure you can just get the Garrett book on user experience.

Robin Williams (no not that one) has the "Non-Designers Design Book".

The "CRAP" principle: constrast, repetition, alignment, proximity. Little changes can make big improvements.

The slides

Overall, a pretty good talk about design.