Your website is a window into your business
How a 50 year-old engineering principle makes the case for consultative design today
A few years ago, as part of the preparations for a CX mapping workshop with a new client, I was carrying out a heuristic review of their customer onboarding journey. Halfway through the process, apropos of apparently nothing, the user was required to choose whether they were a sole trader, a small/medium enterprise (SME) or a large enterprise. It was an awkward fork in the journey and it seemed to serve no purpose.
When I raised it in the workshop there was a groan from one corner of the room and someone wearily explained that this was because the three types of customer were onboarded by three different helpdesks, and so the user needed to be routed to the right one.
The different customer types were served by different departments and these were separate internal trading entities. Each one funded its own helpdesk and, understandably enough, none of them wanted to take on the overhead of funding anyone else’s. And so the user needed to choose which of the three isolated teams to talk to.
When your org chart defines your product
In other words, the experience that the customer got was a direct mirror of the structure of the business. I’ve singled out that particular client, but in fact it’s something that you see everywhere.
Telephone helpdesks in general are often good examples of this. If you’ve ever pressed one if you’re a new customer, two to renew your policy or three to make a claim, you’ve literally navigated that company’s org chart using their telephone exchange.
Elsewhere, content gets shoehorned into carousels and popups because no one will make a decision about which single campaign to feature, so why not feature all five? Each department gets its own page on the site, and so the content tree becomes a mirror of the company structure. Or they each have a corner of the homepage to call their own and every update becomes a battle over screen territory, an exercise in getting many stakeholders to agree which usually lapses into design by committee.
Conway’s law
I came up with my own way to describe this effect:
Every website is a window into the business which owns it. Many usability issues are really business problems surfacing through the UI.
I thought this was rather clever until I discovered that a guy called Mel Conway beat me to it in a paper he published in 1967, about half a century before me. His theory acquired a name 7 years later when Fred Brooks, in his seminal book the Mythical Man Month, nicknamed it Conway’s Law:
Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.
Nigel Bevan add more of a web spin in his update:
Organisations often produce web sites with a content and structure which mirrors the internal concerns of the organisation rather than the needs of the users.
Design it away
Going back to my client from earlier, the temptation is to treat things like that as design issues but that doesn’t really get to the heart of the problem. To understand why, it’s time to invoke another old but lovely bit of thinking, Tesler’s Law of Conservation of Complexity:
Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.
In other words, once you’ve simplified a user journey as much as you can, you’re left with some residual friction which you can’t get rid of. If you don’t own it yourself, then you’ll pass it on to the user.
Passing it on is exactly what my client had done by making users identify themselves as a certain type of customer. In a conventional design process, we would try to design around the problem — maybe find a more logical place to fork the journey. That might ease things a bit, but rather than getting rid of the complexity, it just moves it somewhere else. New customers would still need to understand what differentiates an SME from a large enterprise, or a sole trader from a small one.
We could go a step further and try and deduce the type of user based on their browsing behaviour. That might serve most people well, but there are still going to be some who refuse cookies or behave in ways we can’t resolve to a type of customer.
Fix the business, fix the experience
So really the only way to truly fix this problem would be to combine the helpdesks into one. Or at least get them talking to each other so that prospective customers can be routed to the right desk without ever knowing that there are three to choose from.
In other words, fixing the experience means fixing the business problem that broke it. This is the basis of service design, and it’s the combination of these two which will fix the issue.
Good design will get you so far, but some things will need a more profound change. Optimising user journeys goes hand in hand with optimising business processes. Generally where I’ve worked with companies in this situation, there’s a lot of work to do, beginning with working on design maturity.
In an agency-client model, the relationship moves increasingly into consultancy as we the look at the ways of working, business process and goals that are really shaping the experience map.
In some cases it can even be helpful to embed the design team in the client’s office to really get to know the business and its challenges. That’s not always true, just as a consultative process isn’t always the needed for every problem. If you’re not sure if it’s right for your business, here’s a few questions to consider:
What do we really do?
As W. Edwards Deeming (who knew a thing or two about business process improvement ) once said:
If you can’t describe what you do as a process, then you don’t know what you’re doing
Which is a bit harsh, but you can turn it around to make a positive — mapping out your business model as a set of processes will help you understand what you really do. It’ll uncover all the knots and tangles in your way of doing things that are harming your customer experience. Or shine a light on those things you do but can’t really explain why, it’s just sort of always been done that way.
Ask yourself: Which pages of my app or website annoy or embarrass me? What do my employees complain about in the pub after work? If I had a magic wand, what would I fix about my business?
Do you know who your users are?
It’s easy to mistake data for insights. NPS scores, site analytics, demographics and suchlike are valuable, but they mainly speak about the things your customers are doing. They won’t necessarily tell you what they’re not doing, or anything about the people who aren’t your customers.
Often times the best use of data is to identify questions for further investigation. Analytics might tell you that traffic to an important page is low, but won’t tell you if people aren’t going there because they can’t find it, or if they just don’t see it as being important to them. To understand things like that you need to hypothesise some possible causes and devise ways to test your theories.
Ask yourself: Who is using my service and why? Are they doing things I didn’t expect them to do? Or not doing the things I do expect? Can I see patterns in usage — time of day, location, exit points— that might give me clues to follow in deeper research?
Do you know why they come to you?
Consider everything that’s competing with your product. Really everything. The thing is that your main competition is often not your market competitors. It’s all of the things that your customers could be doing instead of using your product or service. Netflix CEO Reed Hastings observed that if his business model depends on content bingeing, one of his main competitors is people having an early night.
These kind of ‘ghost’ competitors are where your real value can lie. You’re not growing market share by poaching customers from someone else, you’re adding new customers or retaining existing ones by understanding the true value of your business to them.
Ask yourself: What would my customers be doing if my product or service didn’t exist? What are they doing when they’re not using it? Who are the people who never use it? What’s stopping them?
If you’ve worked in an agency, you probably know the feeling when your client stops coming to you with problems to solve and starts presenting you with solutions to implement.
And if you’re the client, are you still using all of those things that made you choose this design partner at the RFP stage? Or would any agency do because the relationship has become a one-way process of pushing business-led requirements?
If either of the above apply, then it’s probably time to have a long, hard look at Conway’s law and ask yourself whether your user experience is really designed for your users.
