Agility and the User Experience

It’s easy to think of a web site in terms of the teams who participate in the project: content, design, information architecture, hardware, platform, application development. But it’s the user who ties all the parts together: the user experience is the end-product of a web application.

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!