Stuck in a waterfall?

“User Centred Design? No thanks, it just costs more money”

Tackling apathy toward User Centred Design

Steve Attewell

--

In 1996, having been in the Internet industry for only a year, I can remember sitting on a borrowed chair in front of a borrowed desk in front of a foot-deep CRT monitor. I was halfway through building a website in Microsoft Notepad (the web developers’ tool of choice back then) and wondering if the people visiting the site would need all the features my client had requested.

Maybe if they’d asked some of their customers what they needed they could have saved 50% of their budget by not building things that people didn’t want. Or could they have spent that 50% on creating and crafting brilliant, focused content for the parts of the site their customers were crying out for?

I didn’t know what a Lean Startup was 20 years ago, nor a user experience methodology, and there wasn't a user centred design community of which the fledgeling web development community was aware. If I could have fully understood and articulated that feeling of inefficiency within the project I was working on back in 1996 I would have sounded a lot like a lean startup advocate or the user experience designer that I am today. Alas, that 20-year-old was not insightful enough to give birth to the UX industry. But still, he‘s thankful for the subsequent, relentless proliferation of the UCD concept onto which he can hang his enthusiasm for User Centred Design.

The problem was the same then as it is now; that of projects being defined by the client making assumptions as to what their customers want rather than interviewing their customers to gain an understanding of what they need.

Another problem is just how challenging it can be to explain the advantages of user centred design to those not familiar with the concept.

So, partly as advice to my younger self, let’s look at the differences between a client-led project and a user-centred project and consider how we might persuade others of the value in User Centred Design.

The client-led project

In this theoretical example our client comes to us with, what they consider as, a well-formed set of requirements. But as soon as the project starts, the proliferation of end-user-aware designers and developers begin to ask questions about the focus of the project and how well it serves the end users’ needs. Even the client will often revisit their initial assumptions during the project. This unclear and shifting focus can lead to a level of confusion (and sometimes disillusionment) in the project team.

The upshot of such a set of assumed features is that, although many of them may be correct, there will be a percentage which are partly wrong, completely wrong or not needed which means that time and money will be wasted on developing features the end user neither wants nor needs.

The difficult truth is that, by the time you hear about this particular type of project, your client will already have a fixed view of the functionality needed and be coming to you expecting you to quote for delivery of those features. The most challenging part for you as a product owner or user experience designer is to interrupt that process and encourage your client to begin again; this time from the user’s point of view.

In the same way that Lesley Phillips’ advice on approaching the opposite sex is, “Never take a step toward a woman until she’s taken one step toward you,” even Jared M. Spool is not a fan of selling the user centred design process to executives unless they already understand the value of great user experiences.

So therein lies a serious challenge for those of us who encounter apathy toward the User Centred Design process in our daily working lives.

How might we tackle apathy toward the UCD process?

When advocating the User Centred Design process consider that the following misconceptions are often at the forefront of your client’s mind:

  1. This person is asking me to extend the timeline of the project by adding a load of research.
  2. I am being asked to spend more money up front.
  3. Why should I spend more time and money in up-front user research when I already know what I want to build?

These initial misunderstandings of UCD are, I think, the major reason why User Centred Design is not the focus of more projects. We, as advocates, must be able to clearly articulate how UCD assists a project, and that it enables you to spend your money more wisely.

Where is time and money wasted in a client-led project?

Two places where time and money is often wasted in this kind of project are in the development of unneeded features, and specification changes during the project.

Superfluous features are developed because some of the initial assumptions were wrong. Specifications change because the reasoning behind the requested features is not crystal-clear.

Let’s be generous and say that up to 25% of the cash is misappropriated this way over the course of a typical project. Keep that 25% in mind…

So what are the advantages of User Centred Design?

What if we could spend the same amount of cash developing our product or website and end up with something that generated more revenue?

The sleight-of-hand that UCD achieves so well is to shift a portion of project budget that is often wasted, reapportioning that cash into the development of a more tightly focused solution that more people want to engage with.

Spending more time and effort on crafting fewer features pays dividends

One way to tackle a client who comes to you with a pre-packaged feature-set is to talk to them about other projects they’ve been involved in where the budget was blown, or it overran, or they found that people didn’t like or didn’t use features. How much money could they have saved if no-one had had to define, specify and build redundant features?

Do they have any analytics of their system that indicates redundant features? Have they asked users what they need? How did they go about making sure all the features were necessary (just to be sure they’re not building something that’s redundant)? Have they heard about the 80/20 rule which states that:

“80% of the effects (happy customers) come from 20% of the causes (features in your product)”

At some point, you’ll hit a nerve because everyone has been involved in a particularly pear-shaped project at some point in their lives. Once that nerve has been struck, begin to suggest a more focused specification can mitigate these potential points of pain.

A user-centred project will be easier for them and better for their customers.

And the best way to achieve this success is to open a dialogue with customers who will tell you, through good research, what they want from your system and which of the things on their list of wants is most important to them.

Your client is not spending more money. They are taking all the wasted time and money from a typical project and spending it to build a better product that generates more revenue.

In a simplistic sense, at the end of a user-focused project you’ll get the following:

  1. A reduced set of features, each of which has had more time and effort put into making it an awesome feature, rather than just another line item crossed off the requirements specification.
  2. A set of features that customers want.
  3. Development time and money is not wasted on unnecessary features.
  4. The project is less susceptible to scope-creep (or outright scope-change) because the list of objectives is focussed and has been qualified by asking the users.
  5. More engaged users who are more likely to stay with your product.

This is what we should be selling to this particular kind of client.

Postscript

I hope I’ve given a sense of the kinds of things people may have in their mind when they are introduced to the UCD process for the first time, a few clues as to what to be aware of, and how to approach changing these kinds of thought processes. If you know of other relevant resources that might assist, please comment as I’d be interested to read them.

If a mantra helps, have mine:

“10 well-crafted features are better than 20 crappy ones.”

You might want to rephrase it.

--

--

Responses (2)