Are you about to take on a big website redesign? How about rebuilding that clunky-but-critical software application? Before you dive in, remember that the final arbiter of quality is not you, it’s your users. Here are a few steps to better understanding their needs and behaviors before you spend any precious programming dollars:

Do your user research

Start with any quantitative data, such as analytics, that you already have to see what your users are (or aren’t) doing. For additional insight, you can user-test the current site or software to see firsthand what delights and what frustrates your users. Talk with colleagues in sales or customer service to learn current and persistent user issues. Even if this research data already exists in a report somewhere, make the time to talk. The empathy engendered from an actual conversation with people “in the trenches” will naturally equip you to make more user-centered design and development decisions.

Build a prototype

Actually, make that “prototypes” (plural)— no one creates a perfect prototype on the first try. But that’s the idea: to fail as quickly, as cheaply, and as often as possible knowing that each iteration gets you closer to a solution worth building. Certainly you can build effective prototypes with HTML or Flash, but Acrobat, Powerpoint, and even paper and pencil are still excellent tools to get your ideas into a tangible format. In doing so, you can better communicate, evaluate, and test your ideas. Speaking of testing…

User testing

When some think of user testing, they imagine white lab coats and clipboards. Unfortunately, many also imagine delays and extra expenses. When forced to choose between this and no user testing at all, most choose the later. For shame! On smaller projects or those with a wicked-tight deadline, take the guerilla approach: find 6 to 10 coworkers, parents, spouses, neighbors (whoever is willing to help) and observe them individually as they complete one or two of the most important tasks on your prototype. This won’t give you all of the insight or fancy reports that formal usability testing provides, but testing even just one person is 100% better than testing no one. The results might surprise or even frustrate you, but better to know these things now than after the project is otherwise done.

The right design

It’s true that we human beings like shiny, pretty things. In technology, nicely designed interfaces are perceived as easier to use than non-designed ones. This doesn’t mean your project should be a beauty contest, however. For example, imagine if Google’s screen design utilized rich imagery and elaborate screen transitions. While this might be appealing in another setting, it would be a complete nuisance on a search screen. For Google, and indeed many others, the most “beautiful” screen design is often the simplest.

It’s worth it

We know very well the pressures on a new project to quickly “get to work” building something. It’s unfortunate when steps like user research, prototyping, and user testing are the first things to go when budgets and timelines tighten. The irony is that these will often save time and money in the long run, and ultimately keep you from unwittingly rebuilding a merely better-looking version of what doesn’t work.

I’m sure you’ll all be excited when I reveal that my husband gave me a humidifier for Christmas. It’s not a sexy gift, but I was genuinely happy to get it (my static-laden cats were happier than me– in theory, at least). The humidifier is lovely – tall and thin, and fits subtly into any room. It keeps the upper floor of our house nicely humidified (to the cats’ delight), and only goes through a tank of water per day. Despite all these wonderful features, I discovered a huge usability flaw the first time I went to fill the tank.

It has a lovely handle on top, as you can see:

But when I removed the tank to fill it, my user experience became a lot less delightful. The bottom handle is actually the lid to the opening for filling:

When I remove the lid to fill the tank, where do I grip it? Instead of a convenient handle to hold while I fill the tank, I’m left with a few less-than-ideal options. I can hold it by the water-delivery stem, and pray that it won’t get wet and slip – or become overly stressed by the weight and snap off. I can set it in the bathtub to fill, resulting in a great deal of overspray (to the cats’ dismay). Or I can hold it by the lip of the opening (which is kind of sharp). I generally opt for the later, resulting in less mess than option 2 and less danger than option 1. (That’s not entirely true - I generally opt to have my husband fill it, but that really is how he holds the tank.)

Perhaps the humidifier’s designers believed all their users would set this tall tank in kitchen sinks to fill. Nice idea, but I’d have to carry the tank downstairs every day to fill it. And like most consumers, I’m inherently lazy; an extra trip down the stairs every day isn’t appealing. That leaves me to choose between a deep bathtub and a shallow bathroom sink.

Grumble.

So aside from being irritated daily, what can I take away from this humidifier lesson? Requirements.

If a project team doesn’t fully flesh out requirements in the early stages of a project, and doesn’t keep revisiting requirements as the project progresses, that team will end up with an unfillable humidifier.

Or an unusable website.

When starting a project, it’s imperative to take the time to fully consider requirements. Most project teams are eager to get a project rolling – to jump right in and start seeing results. That’s great; we all love results. More importantly, though, we love successful results. Without fully identifying the objectives, scope, and end users, any project’s risk of failing to meet the project’s goals skyrockets. The impact of missed requirements can be huge, and that impact only increases as the project moves through its lifecycle.

That’s why it’s key to hold a team kickoff meeting. To document objectives, scope, personas, and site architecture. To review every deliverable with the team. And to test the product with end users. Because without knowing requirements, how can any project team accurately build any product for anyone?