The dangers of one-sided spec work

Working purely to spec can also be really soul-sapping for the designer/developer - we are wired to solve problems, not bang out code or designs mindlessly - the best solutions come out of being given problems/guidance and iteratively working collaboratively with people to solve them, not a one-sided list of requirements delivered in a big-bang approach, holing up for weeks before a big reveal.

Failed software projects are not just the ones that aren’t delivered on time to-spec, they’re the ones that just don’t deliver any meaningful value.

The thing is, this is not always the customers' fault. For some customers, this shopping list/big-bang delivery approach is all they have known, so of course they are going to go ahead with that mentality.

I’ve seen customers who were dead-set on a complex forum software implementation as help for their website because they have seen it elsewhere, when really what they needed were a simple FAQ and searchable curated knowledge base, however, it was only asking “Why?” several times and speaking to real users that the real problems and requirements emerged.

It's our responsibility to educate on the most suitable process for the best end result.

Customers are experts in their domain, and you are yours, and they should be paying for your skills, not just your time. We should be guiding customers to what’s best, using a combination of their expert domain knowledge, and your expertise in both the coding and design of the web.

If we want it to work, it is down to us to set expectations upfront as to our process, and stick to them, helping guide the customer to a better solution. As we know, time is money, and while there is never an unlimited budget for a project, having some small exploratory time up-front looking into how best to achieve the customers' goals can really reap rewards, making the process more collaborative and easier, with often a better outcome.

So how can we improve the software delivery process? Through asking Why, getting to the root of the problem, agreeing on a solution and feeding back during project delivery, doing some user research, and measuring what success really is.

A side-benefit of this is that you might be able to spot the potential challenging customers early on - if they are not willing to discuss the problem with you openly upfront, then they might pose further communication challenges later in the project.

Develop a tried and trusted process, learn how to explain why you do it and the value it brings, and stick to it.

Now if you'll excuse me, I've got to go and do my annual read of Design is a Job by Mike Monteiro - one of the best books on this subject out there.

“Now, it’s easy to laugh at clients and say they’re bad clients. But the truth is that no one is born knowing how to be a good client, just as no one is born knowing how to be a good designer. And look how hard you have to work at being a good designer!

By and large, most clients want to be good clients, and they’re trying to do the right thing by their business.

Clients will always ask you to make their logo bigger, prescribe solutions, and ask you to do things that will make you smack your forehead. You can roll your eyes at how much they don’t understand about design or you can roll up your sleeves and begin practicing your craft by helping them clarify what they need.”

Mike Monteiro. “Design Is a Job”.

Next: Design for when it goes wrong

Previous: Getting unstuck

Like what I write? Subscribe via your RSS Reader or email below.

An occasional email with my most interesting posts and links of note, sent monthly.