Working, as I do, in a software consultancy, I spend some fair amount of time providing estimates on how much time it's going to take to "do UX" on a project. I think there are as many ways to estimate effort on an activity like this as there are people who "do UX". Some of the most popular methods I find in use around here begin with a question. A question like:

• "How much time do we have?"
• "How much money does the client have?"
• "How much did it cost last time?"

I'm going to start referring to these methods as the Holy Trinity of estimation techniques: The Deadline, The Budget, and The Past Experience. All three are simply accepted by the faithful as truthful, honest, and reliable. But timelines can change, budgets can shift, and previous experience is most useful only when you're building the same damn thing over and over. The foundations of this faith are shaky at best, and reliance on them is merely a matter of convenience. It's just easier to pretend that you can fit a project into a given timeline, or a given budget, or some ill-concieved notion that it's "just like that thing we did last year." And a faith of convenience is an empty faith indeed.

Given that, how to go about providing an estimate of the work to be completed in a field where the work is highly creative, wildly varying, and always "just like that other thing, only different?" It's useful in these circumstances to look at the milestones in a project, and ask some fundamental questions about them. For this, we need an Imaginary Example.

How to estimate this project? Is the answer:

• A. $2 million and six months.
• B. $100 for a copy of FreeCommerceOutOfTheBox storefront software, plus about 4 weeks to "tweak it" until it looks right.
• C. 3453.75 programmer hours @ $150/hour
• D. Ant farmers?

The key things to consider here are that Foo-EI has planned to spend a lot of money, and that they're only able to describe the desired end goal in broad terms. They have budget, and they have a vision. So let's get started!

Whoa there, cowboy.

The temptation to dive right in is almmost irresistable, and that enthusiasm is hard to contain. "We're agile, and we can get something up and running in 3 or 4 weeks - it'll be better than wasting months trying to gather requirements - who even does that anymore?" Lately, there's more and more talk about Getting Real, as if things like strategy, planning, a customer-focus were some how superfluous, or fake.

As software gets easier to write, and easier to deploy and distribute - what happens to quality? Not just in terms of the number of bugs - software can be bug-free, and very low quality - but in terms of the thoughfulness behind software.

What we seem to be facing is a divergence in the way software is developed, and the way interfaces and experiences are designed. (I'll come back to that topic later.) Software development environments and practices have made huge strides in recent years abstracting the process of coding software from the nitty-gritty of moving bits around inside a computer. This isn't always a Good Thing (as Joel Spolsky points out), because sometimes it's important to know the nitty gritty about the insides of the machine when you're telling it to redraw that spinning logo 30, oh what the hell, let's say 300, times a second.

Interface design, and even more so interaction design, hasn't come quite so far. Why is this? Well, I have my theories - it has something to do with the more artistic temperment, to be polite about such things, of your average designer. There is a level of resistance to interaction design patterns which you just don't find with programmers and developers. If you say to a programmer, "Look, here's this piece of code that handles password validation - just use it all the time, and don't worry about ever having to validate a password again, OK?". Do you know what their response would be? &quo;Oh for crying out loud, why didn't you write this a week ago!"

But try saying this to a typical Interaction Designer or User Experience Architect: "Here's this pattern for asking a user to log into a website. Use these two fields with the labels placed thusly and the submit button labeled 'Login', OK?"

Good freakin' luck. Once the eyerolling stops, get ready to answer questions like, "What if the user's already logged in and failed?" and "What if I need to use a different font style for the field labels, or provide the login in 17 different languages?" Bear in mind, the average UXA doesn't want you to answer these questions. They want to convince you that they're the only ones who can get to the right answers, and design the login widget in just the right way, for this particular audience.

So what does this have to do with estimating work, anyway? And what the heck does it have to do with testing?

Good estimates take into account what is known - and explicitly define those things which are unknown. In our fictional example, we could easily have gone with an estimate that would keep us quite busy until something was developed and launched, and/or the money ran out. But it's quite a different thing - and in my opinion, the only honest thing - to say, "Look, this is for ant farmer's, right? What do you know about ant farmers? Is there even any such thing? Are any of them online? Do they have credit cards?"

These are questions - and until we've done some digging, the potential answers are hypotheses. And it's vital to test those hypotheses before anyone starts banging out any code.

And as for that testing... well, that was a tease. You'll have to wait until next time.