When we’re designing products, applications and services, we always bang on about how important it is to consider the customer, or user (I’m going to use those terms interchangeably in this post). But just how much do we really consider them? And how often do we compromise in favor of some product or business limitation?
While I realise (abundantly so) that we can probably never create the perfect product or service, I’d like to argue in this post that the primary consideration we need to focus on as user experience designers, service designers, marketers or whatever, is the voice and view of the customer.
I don’t think it happens nearly enough, nor well enough. And, truth be told, I’m as guilty as anyone of this.
Let me set the scene.
You’re designing, or redesigning your product or service or your web site or your bricks and mortar store (or doing it for a client). You’ve been given the imprimatur to “focus on the customer” and you start sketching out what you believe is the ideal experience.
You focus on flow. On creating delight in the user’s mind. On achieving the desired outcome with the least inconvenience, fastest path and fewest number of hurdles you can. You ensure any limitations of the business or technology or infrastructure are hidden with helpful smoke and mirrors so the customer gets the job done.
Then you present your design to the project team, or key stakeholders, or someone else with a vested interest and it all goes to crap. You hear things like:
- the legacy systems don’t work that way
- the price is wrong because you haven’t factored in the development costs or costs imposed by some other factor
- the order of fields in the form is wrong because the way the code will be written is easier if it’s this other way
- you haven’t considered factor X which is the primary business concern of a particular stakeholder business unit
And there are any number of others.
But where’s the voice of the customer in all of this?
Of course, in any project you need to balance the business requirements against what’s actually deliverable to the customer or user. But I’d argue that at no point in the project should business requirements outweigh or force a compromise in the experience you deliver to the customer. You should never expose your problems, limitations or issues with the business to the user or customer. If you do, you’ve failed in delivering the best experience.
Of course, this doesn’t mean that those issues don’t exist and that you don’t consider them very carefully. But you don’t expose them to customers. You use whatever smoke and mirrors you can. You do clever things under the hood. Or you even change the business to remove the problem so it’s no longer a problem at all.
Here are a few real and virtual world examples I’ve come across lately to show what I’m talking about:
- banks increasing interest rates outside or in excess of official increases because the GFC has made their part of the business (trading and moving money around) more expensive
- justification for a higher-priced product than competitors because the R&D, innovation and rollout costs had to be offset somewhere
- a request to change the order of fields of a web form because it would be a hassle to code and pass messages to legacy systems in the order that was best for customers
- an inability to deliver a new web-based product to customer expectations because of an unwillingness in the business to adapt or change old practices
While these are all valid business concerns, and absolutely need to be addressed, they need to be addressed and resolved on the business side of a project. They are issues that should never be exposed to the customer. Not least because as customers, we just don’t care what your business issues are.
So, here’s a quick list of voice of the customer concerns you should ask yourself every time you encounter an objection to delivering to customer expectations:
- am I exposing a business concern to the customer?
- am I delivering the product, service, whatever at the best possible price that’s competitive with the alternatives?
- am I making it as easy as possible for the customer?
- if there’s a barrier or process I’m exposing, does passing it offer the customer a tangible benefit?
This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.