This is why people freak out about user experience design, or UxD, these days. We can define and justify and normalize everything we do during the course of a web project by referring to the user experience, and we can keep this experience in mind as a theoretical model to help us make decisions along the way.

But the user experience is only just that — a theoretical model — until you get real users. This is why we can’t begin a project with all the answers.  The answers to many important questions are provided by the users.  But the users don’t come until we’ve actually designed and built something.

Oh, the Catch-22!

The way out, of course, is by agreeing to launch with something that’s in some important way unfinished.  Knowing that our users will provide us with feedback that will shape the future site — that we plan and build the site in phases, and that these phases are informed by an ongoing engagement with the user experience.

As an agency, you need to go to great lengths to get your clients to understand this.  They can’t provide a spec, like a blueprint for a shed, and get a quote and schedule based solely on the blueprint, and then expect the actual shed to look exactly like the blueprint.  This is what they’ll want, because it’s easier to plan, and easier to budget for, and just generally easier to think about.  But it doesn’t comport with reality, so you’ll have to make a strong case for agility throughout the process.

And as a client, you need to go to equally great lengths to factor this fluidity into your own plans.  Remember the great triangle of software development: one side is budget; the second side is functionality; and the third is schedule.  You can’t fix all of these sides, because you’ll end in horrendous failure (the great triangle of pain and disappointment).  If you must, try to fix two; but leave the third one agile.

Say you’ve got a project with some fairly well-defined requirements, and pegged to a particular real-world date.  You’ve got your functionality and schedule fixed.  This means you must remain agile with your budget.  In practical terms, you’ll need to provide the agency with a budget range that is acceptable, and trust them (Trust them! Seriously!) to keep their costs down.

(Side note: if you can’t trust your agency to keep their costs down, you should find another agency.  This shouldn’t be an antagonistic process, but one where both sides share common goals.)

A second example, one that we see very often at HM: Say you’re a not-for-profit institution that secured funding for a particular project proposal from a big foundation.  You may see all three sides of the triangle as fixed: you promised a set of functionality in your proposal.  You also received a fixed amount of funding, and have a delivery date as part of the funding timeline.

In truth, though, one side of the triangle has to be flexible in this situation.  Chances are the foundation won’t increase the budget, so one of the other sides needs to be subject to change.  This may require some advocacy on your part to get the flexibility you need from the funder, but the big selling point here is the main goal: a beautiful, functional, memorable web experience that users will visit again and again because it was built around their needs.  If you can’t get it all done in the budget and timeline provided, consider this a first phase.  Phases are good!

Part of our job is to focus this enthusiasm into disciplined decisions about how best to serve a particular client and a particular project.  We have a lot of healthy arguments that start with, “Wouldn’t it be cool if…?”  The question is often followed by, “I agree, but we shouldn’t do that in this case because….”  Or, just as often: “That’s great — but let’s consider that for phase 2.”

We go through this in order to avoid three big pitfalls: building more than the client needs or can immediately use, rejecting new approaches or techniques because we’re unfamiliar, and committing to unreliable approaches or techniques because the coolness factor affects our judgment.  We wrestle with these issues so you don’t have to.

(There are a lot of interactive technologies that are the equivalent of a two-seat Lotus Exige: extremely cool, but maybe not what you need.)

You may have done your own research before you even found us, however, and decided that your new site absolutely has to include X, or be built on Y.  We often meet with potential clients who say, “We want our new site to be built on [insert trendy platform or poorly-understood technology here].”  Why, we ask? “We’ve read about it, and it looks like the best new technology for us.”

This is an ideal point to ask us what we think of the idea, and whether we have other recommendations.  That’s the beginning of a great conversation that will help you to educate yourself about your options, learn something about us and our experience, and save money in the long-haul by making the right decisions when you have the most flexibility – i.e., before you start down any road.

You’ll be able to meet the overwhelming majority of your project’s critical strategic needs with proven, industry-standard design and interface practices.  Your agency, if they’re up to snuff, will have a toolbox of information design, user interface, and technology solutions that apply in some manner to almost everything that can come up.

Your first contact with an agency should be a great learning experience.  I know that I love talking to potential and new clients about the broad strokes of planning and building a web application.  I call it Everything You Always Wanted To Know About The Web But Were Afraid To Ask.  For you, the client, it’s free advice; for us, it’s a chance to show you how we think and work.

1. What was it about Obama’s web strategy that helped him win?
2. What does this mean for the web?  (And: How can I take advantage of it?)

We heard a great answer to the first question from Judith Freeman, an Obama campaign strategist and co-founder of the New Organizing Institute.  The interactive strategy wasn’t based in a one-to-many communications paradigm, where the campaign’s top dogs disseminate information and calls to action to the masses.  It also wasn’t based in a lower-tier, peer-to-peer approach, where the masses communicate with each other in some feverish cloud of messaging whose collective wisdom never bubbles up to the leadership.

Instead, the campaign adopted a multi-tier, anyone-to-anyone strategy.  They wanted a local organizer’s ideas to be able to percolate up the chain to the national strategists.  They wanted Latinos across the U.S. to be able to form an ad-hoc “Latinos for Obama” group, and to have an online space for this group to share their ideas and enthusiasm.  They wanted mobile phone aficionados to feel connected through their iPhones.  They wanted national, brand-name staffers to communicate as directly and personally as possible with individual voters.  And they wanted everyone, every last person, to fund the campaign.

In technological terms, the campaign was outrageously ambitious.  Judith Freeman was able to look back on the election season and synthesize an approach, but it was clear to technology watchers that one key to the campaign’s success was that it built adaptation into its core strategy.

Think about this: if you start a two-year political campaign with any well-researched, beautifully-implemented, and expensive set of interactive tools, those tools will almost certainly be completely outdated by Election Day.  Twitter was not a year old when Obama announced his candidacy.  The iPhone wouldn’t hit the shelves for four months.  And yet, by the time the campaign entered spring 2008, Obama was tweeting like a madman, and by the fall he had a (pretty sick) iPhone app.  And everything looked fantastic, too–the Obama campaign brand translated across platforms, screen sizes, and interfaces.

The lesson for the rest of us?  Have a strategy.  Make explicit plans to express this strategy through your visual identity, your technology platforms, your user interfaces, and your communications.  And give yourself a framework to adapt to changing trends.

(Also, make sure someone’s paying attention to those trends.)

Now, what does this mean for the web?  Our not-for-profit clients don’t usually have, say, a hundred million dollars to toss at their problems.  Projects are generally funded by grants, which mean that there’s a hard cap on the funding, and often on the timeline.  It can seem that there’s no time and no space in the budget for strategy and research–just get it done!

This can lead to a technological panic response: your project needs all of the free, or cheap, tools and platforms you’ve read about in the last few months (never mind those from a year ago), because you need to show that your organization is on the cutting edge.  You need a blog, a Twitter account, and a Drupal site.  Stat.  You also need a new logo, and a hundred other things you haven’t had time to think through.

The best salve is a strategy.  Don’t get bogged down in technologies, products, or design elements until you’ve put some basic goals on paper–and made everyone in your organization agree on the goals.

1. Our project is about X.
2. We are trying to reach Y.
3. We’ll know we’ve succeeded when we see Z.

The point of  your project, your audience, and your measure(s) of success.  These are what you use to build a design and technology strategy.  These are what you can look to when you feel the need to adapt your approach or reconsider an initial decision.

Set aside time at the beginning of a project for everyone involved to consider these points–and if you don’t have the answers in front of you, do research.  You probably won’t be able to carve this time out of your project schedule if you didn’t put it at the beginning.  It may seem like an unnecessary delay and expense to put your people in a room and make them think, but it will pay huge dividends over the course of the project (or, you know, presidential campaign).