Why are bottlenecks in Customer Experience development so common?

The Customer Experience has been identified as one of the most crucial factor for digital business development. But why are there still so many bottlenecks in the way for customer value and experience?

The Customer Experience has been identified as one of the most crucial factors for digital business development. Still, many companies move much slower than they could due to completely unnecessary bottlenecks in experience design. How they create these bottlenecks will tell us how to get rid of them and shorten the time to market for high-quality Agile Customer Experience development.

Customer Experience is more crucial than ever

When developing a digital business, regardless if it’s a new, digital-only startup or a traditional organization transforming its operation, Customer Experience is now more crucial than ever. According to Gartner, 81% of Fortune 500 companies were committing their main focus on experience development last year. In business development, methodologies like Design Thinking and Service Design are crucial together with Business Agility in order to attain profitability.

Simultaneously, the upfront tech investment needed to get a digital service launched has never been lower on a feature by feature comparison. Even counting complex capabilities like machine learning. Most of the infrastructure you had to build yourself is now available in the cloud on a subscription model. In other words, you only pay for the infrastructure you need when it’s being used by your customers. So if you have a business model, you just fork over a part of the money you’re making.

Since the cloud solutions also include a lot of functionality, this drives the customer experience as a competitive advantage even further. In large user groups, we can now see previously unheard of behaviours like changing bank when a competitor releases a new app, even though there are no new products, no change in the offering except a better and more convenient way to handle your affairs. These are prime examples of customer-led, behavioural changes and of the fact that we have entered an era where people are changing their digital habits faster than we are creating ‘theories’ about them.

Many successful disruptors are in fact ‘just’ a new and better customer experience compared to the traditional offering from industry incumbents


Riddled with bottlenecks

We could go on with ‘evidence’, but just the fact that the customer experience is the first thing we ‘see’ and the interface that we use to interact within any digital product, should tell us how important it is if you want your product to succeed. Still, the development of the customer experience is riddled with bottlenecks in a majority of organizations. For instance, we all recognise the common blocker in a sprint planning: ‘But that user story needs UX!’.

The fact is that releasing new code often happens easier and faster than releasing crucial updates to design. And before you go nitpicking on us: Yes, of course, design is code as well, but that just makes the situation more interesting. Because why should we be slower when it comes to one type of code?

Actually, Harvard Business Review, as well as many others, have identified time to market for experience design as the most important gap to close for any digital operation. So why is there a gap in the first place? Why do we have more bottlenecks in CX than in any other digital area right now?

Common CX pitfalls

The slightly embarrassing but simple answer is that design hasn’t really been part of the ways of working that have evolved for our other digital crafts. The early Agile movement was very developer-focused and many of the methodologies, like continuous delivery and DevOps, didn’t even mention the customer experience that they are supposed to deliver. Now, with a greater focus on the system as a whole, things are changing.

But the situation has been very similar on the other side of the fence. Designers often emphasize that they belong to a completely different and more ‘creative’ tradition than developers. And even though we now have real-time user feedback available for anyone who wants to see it, user experience practitioners have a tendency to hark back to heuristics and academic tradition like creating personas we no longer need since we have real customers real data, live. Just look around on Medium and you can see all the different UX articles that actually tell you how something should be designed.

In an age where we can have immediate feedback on new experiences, only those organizations that harness that knowledge as it materializes become winners. At the same time, it’s often the organizations that have created the bottlenecks themselves.

bottleneck creators

The top five bottleneck creators

In many companies, the cultural divide between the different professions is perpetuated through an antiquated organization. Specifically the upholding of separate design departments, which of course is the opposite of the Agile idea of cross-functional teams. Or make them very/unnecessarily difficult to set up.

Maybe we don’t even have to describe how this creates bottlenecks, but having a piece of work being moved step by step between different departments results in a multitude of those pesky handovers that we want to avoid and, more than anything, it creates queues. A word that clearly tells us that time to market has been increased. (Design departments without developers are as stupid as cross-functional development teams without designers!)

You’ve heard and we’ve heard it ad nauseam. When people talk about designing an app or a site and really mean that they are going to do all the design for the whole product upfront, this can sound right if you come from the olden days of design and it can also have the ring of a non-queue approach. After all, there’s just one big handover of the design to the developers, right? So no queue, right?

These organizations are missing the whole idea of continuous improvement and why we break down the work in as small batches as possible. They are missing the core of why almost all instances of developing now are doing their work in increments: Because the other way turned out to be very costly. If you work for a long while on something before you let it interact with the real world, there will be much more that needs to be changed then if you work a shorter while.

The creation of this bottleneck isn’t always only the fault of organizations. Unfortunately, a lot of UX people and designers also think that they should do all of the design first as we did in the past.

Almost the opposite of massive amounts of upfront designing is when people are skipping or going around the design work that needs to be done. There are lots of different explanations. From the classic that the change is so small that the user won’t notice the difference anyway. To the supposedly modern idea that we can go straight to code now because so much design is done in the front-end layer of a product. Well, it always was.

And it doesn’t matter what tools we use. Be they fancy versions of PageMaker or sophisticated CSS coding, we still need to do the work of designing the experience, i.e. someone with professional knowledge of developing good experiences needs too…

This one is as sad as it is common. The work of developing the digital product is organized in cross-functional teams and there might even be continuous delivery capabilities. But the teams don’t have all the functions they need to be cross the crucial skills. They don’t have UX developers or designers in the team.

In other words the team has to go somewhere else to get design; to ‘send’ for it. And we know what that entails. Handovers and queues.

This is a collective term for bad behavioural patterns. And what they all have in common is when more time is spent on dividing and organizing what is what within Customer Experience development than actually doing something. When someone tells you off for saying UI when you should’ve called it UX, you know you’re in one of these contexts. Yes, technically there’s a difference — or, at least — there used to be.

But the days when UX people first spent a lot of time on doing wireframes for the whole product and then designers spent as much again before anyone started to code and release something are long gone. At least for successful companies.

Basically, erecting walls between different skills and competences is equal to creating bottlenecks. And newsflash: Designers who right now already have a career, have grown up digitally and for them, the user experience is in their blood.

Don’t read this the wrong way; we’re not ‘anti-UX’. Quite the opposite. But because this is the fastest moving domain in the professional world right now, it’s a bottleneck all by itself to uphold divisions that held true ten years ago. The question is how we work better together, not how to divide and conquer.

bottleneck crushed image

  • Admit that you actually have bottlenecks, see the diagnose for what it is.
  • Don’t let different groups argue differentiating ideologies — Don’t subscribe to the UX religion, nor coding practices that treat design as something that has to be done before development starts..
  • Accept that you have to change the way you work in order to increase the speed to market of awesome customer experiences!
  • Accept that a lot of the popular buzzwords (Rapid Prototyping, Paper Prototyping, Design Systems, Design Thinking) were cooked up separated from the rest of the multi-functional team, in a design first world. So tweak them to your cross-functional way of working.
  • Take action and implement a time to market perspective on customer experience by following the following five steps.
  • Stop all ‘design first’ work and habits. Don’t allow the designers to sit and work on large design scopes themselves. As much as developers need to work with designers, designers need to work with developers.
  • Instead, introduce a new ideation and explorative way of working that includes all functions (front-end, backend, copy/editors, animation, tile maker — whoever you have in your teams). If the whole team is working together from the start, everything becomes much faster.
  • At the same time, slice down the scope of what is to be done. Let the ideation and subsequent experience development deal with a smaller slice of what you offer customers. Instead of redesigning your web, remake the start page, or whatever part you have the most problems with. Instead of improving the whole customer experience of an app, manufacture parts of a new experience first.
  • Get user feedback into the loop already in the slicing and ideation. Let behavioral data and customer interviews tell you which parts of the experience are burning the most.
  • Let the ideation sprint include all the functions and competencies that are part of delivering the flow of things that make up the customer experience for the part you have decided to remake. At the end of the ideation, define what modules your part could be built from. Then let the team loose on developing these volumes and do it in parallel. While you design one module, someone could do front end on it, or on another module. And someone else could be writing UX copy for another module. Et cetera, et cetera.

//Magnus Westerberg