Archive for the 'User Interface' Category

Should web developers also design?

Thursday, March 5th, 2009

A couple of months ago, The Pragmatic Programmers announced a new book. Web Design for Developers is described as,

how to make your web-based application look professionally designed. We’ll help you learn how to pick the right colors and fonts, avoid costly interface and accessibility mistakes—your application will really come alive. We’ll also walk you through some common Photoshop and CSS techniques and work through a web site redesign, taking a new design from concept all the way to implementation.

My question is this. Should a developer be trusted with design? It is definitely a profitable skill to have. I believe that developers should at least have a basic idea of what goes into design. I also believe that designers should have a basic understanding of web development. However, if someone is at one end of the spectrum or the other, how do they acquire the necessary skills?

There are several books written for each audience, but very few that are targeted at both. To my knowledge, this is the first book attempting to make a developer more capable as a designer. It appears to approach design in much the way a “logically driven”, coding brain works. It breaks down the fundamental components of design. Layout, color theory, spacing, mockups, etc. All are laid out with a logical process. In some ways it only scratches the surface. Entire books are written on color theory, or typography alone.
Read the rest of this entry »

Users don’t want to think, and they shouldn’t have to.

Wednesday, February 14th, 2007

Steve Klug, author of Don’t Make Me Thinkamazon.com, has some sage advice for those of us who create user interfaces. When putting ourselves in the users perspective, realize that no matter how nicely we craft something, the user isn’t going to look at our presentation. He will glance at it for cues directing him to where he wants to go. She’ll scan it for relevant information. But no matter how flashy the page is, no matter how much time and effort went into positioning everything, no matter how long we took writing out the content, the user won’t look at it. Don’t get me wrong… content and presentation are extremely important, and should be given plenty of attention. But when the user hits your webpage – or application for that matter – they have a specific task in mind. They probably have a few keywords in mind that they are scanning your page for. As soon as they find a word that could be interpreted as relevant, they’ll click it, or the closest seemingly relevant link. In order to demonstrate this, go over to a casual computer users house, and watch them browse the web, or use email. They will probably drive you crazy… not use any keyboard accelerators, type instead of copy & pasting, click through the menu instead of clicking the toolbar button, etc.

What does this mean to us, the software developers? Should we drop all of the nicely crafted stuff that we work so hard on? Should we limit our pages to one or two links, and a picture? Should we hang it all and go bag groceries? I’d hazard a guess that the answer lies somewhere between the groceries, and no. Specifically I think that the hand crafting is important on pages that are end points. These are the articles, blog posts, help screens, etc. Navigation pages, or task screens should probably have a lot less content on them than they do now. The content is being wasted, in time, pixels, downloads, and everything else.

Don’t Make Me Thinkamazon.com discusses several tips and tricks for handling the dillema, and is worth a read… but the easy and obvious tips are:

  1. Limit the amount of information the user needs to scan
  2. On navigation pages, keep link descriptions to one or two clear, non-gimmicky words.
  3. On content pages, give the user a hand… break the content up, leave plenty of whitespace, and have bold keywords sprinkled throughout the content to help identify potentially relevant areas of information. I.e. don’t force the user to read the entire page – or really, any of it.
  4. Adapt, adapt, adapt. Go watch someone use your app, or website. Don’t have them test it, but have them use it. You may be surprised at how differently they react to the interface. Remember, they are heading over there for a reason, you probably don’t know that reason, but as you learn it, alter your site to accommodate it.
  5. Realize that the user is going to click on the wrong thing, give them a clear way to get back, using the back button, and otherwise.
  6. Read Don’t Make Me Thinkamazon.com, to learn how to get into the users head.

Ultimately we, as developers, need to create something of value and use. Unless we are the ones using it, we have to accommodate the quirks of human nature. Our users time is precious to them, and they will only give you what they feel they have to spare. In order to maximize the value you provide, that time has to be well spent. An intuitive interface is the best way to ensure that. The only way to make an intuitive interface is to know what intuition drives people to do. Given some small changes in how we design applications and websites, we can make life easier for our users, and that can make life easier for us.