As developers, we sometimes forget that to our users, the interface IS the application. We love to geek out on the latest techno-wizbang technology that we added to our code library but we often neglect to examine how easy it is to actually USE our app. As a usability advocate, I try to encourage developers to employ an interface-first method of design. Of course, the underlying code has to be elegant and do what is expected, but jumping into the deep end technical problems as you start a project tends to place the value of the application on the technology, not the people that should be benefiting from it.
Employing an interface-first approach takes a little getting used to in the beginning, but pays huge dividends in the end. How many times have you gathered specifications from a user, built the functionality and delivered it, only to have the user tell you that it's not really what they wanted? Be honest...it's probably more times than you'd like to admit. Have you ever thought up a cool design feature that you were sure they would LOVE, only to find out that they don't use it, or worse, don't LIKE it? I'm sure this has happened to the best of us. By using an interface-first design method, you can avoid many of these problems. It's not fool-proof, but it gets you a lot closer to the desired end result a lot faster than traditional methods.
So what does using an interface-first approach actually mean? By using this method, you actually build the interface for your application BEFORE you write a lick of code. This can take many different forms, but essentially involves drawing out what all of the screens will look like as a first step. I use low-fidelity prototyping for all of my projects. This is just a fancy name for sketching out the interface on paper...using pencil, pen, crayons...whatever you have handy. Some people prefer to use HTML or a graphics program to design screen layouts. This is fine too, but takes more work (see aside below). After I have gathered enough requirements so that I feel I have a good grasp of what the user is looking for, I grab a stack of fresh blank paper and jump into the design process. I draw out the fields, sections, graphics...everything that I expect will be a part of the application interface. This doesn't have to look good. In fact, I encourage you to not spend a lot of time drawing these screens. They're very likely to change and you might have to do this several times.
Hint: If you are designing an application in which you will have several static elements that will always be visible (such as a page header or footer), draw these elements out first and then make a stack of them with your photocopier. This saves tons of time since you don't have to draw a placeholder for each element on all of your prototype pages.
Here's a couple of examples of the paper prototype I developed for my machine forecasting application. I ended up using an embedded editor for this functionality, but I didn't have this in mind when I drew this...I just mapped out what I thought was the most logical interface based on what the users described to me. The first shot is my initial sketch and the second is after a meeting with users...they wanted to add a new field and also thought of an additional requirement they hadn't relayed to me before.
After your paper prototype is complete, schedule another meeting with your customer. Ask them to look at the screens and give you feedback. This can be formal (conducting a full-fledged usability testing session) or very informal...whatever you are more comfortable with. Take time to explore different scenarios. If your database is for entering customer complaints, ask the user to take the role of a customer service representative and have them walk through what they would do while looking at your paper prototype. Ask them to talk out loud as they do this, explaining each action. You'll be amazed at the insight this gives you into the mind of the user. When you find something that doesn't belong on the form, cross it out with a marker. Need to add some new fields? Just draw them in with a new color. See why it's good not to spend a lot of time tweaking your prototype? You'll end up changing them a lot.
When you come back from your initial paper prototype session you may be surprised at how much has changed. If you nailed it the first time, good for you! More often than not, however, you've got some changes to make. Quite literally, you should go back to the drawing board and build the next iteration. For a typical application, I will build about two or three paper prototypes. This may seem like a lot of work, but in reality doesn't take too long.
Aside: There are a few reasons low-fidelity prototypes are best sketched out fast and work even better than mock-ups built in Photoshop or HTML. First, from your point of view, you don't feel nearly so invested in the design when it's a bunch of scribbles on blank paper. Since you haven't written any code yet, changes are no biggie. The flip side of this is good from the user's point of view. When presented with a polished looking mock-up or prototype, the user may not reveal their true feelings. They may think you've already put a lot of effort in and have decided that this is how the application will work, even if it is less than desirable. They don't have any problems, however, criticizing a paper prototype...trust me! :-) In fact, they often enjoy grabbing the pen and being an active part of designing the application they will use. This is probably a secondary benefit, but many users have mentioned to me how much they enjoyed the interface design phase.
So...you've built your paper prototypes, gone through some iterations with your users and have a pretty good feel for what the interface will look like and how the application will function. Now what? Now, go about your business...doing what you do best. Start slinging your code, basing it not only on the business requirements, but also on the interface requirements that you've collaboratively developed along with the user. By designing the interface first, you are already halfway to user acceptance and in my experience, have also made the users more passionate about the application. They feel invested in it much more than in traditional programming methods, where you may have only met with them once or twice. When you finally deliver that application, I guarantee it will be almost exactly what the customer asked for...and that, my friends, is exactly why we do this!