Want to get the most from your technology? Start with user experience, not IT.

Designing your technology stack is a challenge, but many organisations do themselves no favours by forgetting the customer and trying to construct their entire stack around one or two ‘tent pole’ systems. These systems market themselves as grand, unifying platforms with everything an organisation needs in one neat package (which, in reality, is rarely the case). This approach leads to scenarios where adding new capabilities to the organisation’s technology means either accepting whatever modules your core vendor(s) can offer, or replacing the entire platform (a very painful process). Neither option is great so organisations end up dithering and innovation becomes painfully slow.

We find ourselves in these situations often because technology choices were made on the premise of most-features-wins — selecting platforms which tick the most checkboxes — and designing our organisation around the structure of the grand, all-encompassing platform(s) we select rather than selecting technology to fit us. During this process the experience and needs of our customers (or donors, in the case of charities) is forgotten. The job of designing how people interact with our organisation ends up being, in effect, delegated to the IT department.

These all-encompassing systems also restrict our ability to change. Having swathes of customer data, identity information and personalisation data stuck in a sprawling marketing automation platform, originally picked because it “did everything we’re ever going to need”, means adding new applications and new customer touchpoints becomes difficult or impossible, depending on how much data that technology vendor lets you get out of their ecosystem.

So, instead of traditional enterprise architecture approaches which focus on the technology we prefer to start with the human at the centre of all this — the customer, supporter or user.

How to design your technology stack from the customer experience out

The idea is this: the people our organisation serves have needs, and there are things we’d like to help and encourage them to do. Start with those things and design the customer experience (or the donor/beneficiary experience for charities) first.

From there, think about the journeys those customers should take and identify the touch-points and tasks along those journeys (we do a lot of customer journey mapping with clients to facilitate this). These touch-points and tasks are served by applications which should be owned by and continually refined and experimented with by the business, not IT or your technology vendor. Then, and only then, consider the platforms and enterprise services that support those applications. This is the layer IT should own, and this is the place where you will slot in your larger pieces of vendor technology. Those business-level applications are often smaller and shorter-lived whereas the enterprise services change more slowly and require more governance. For more on that dynamic, see McKinsey’s “A two-speed IT architecture for the digital enterprise”.

In terms of responsibilities, the business knows the customers so they own the applications which fulfil those customer needs. IT owns the platform that those applications runs on, but the platform serves the application needs rather than the platforms dictating what applications are possible.

You can think of this approach as a stack, each one being defined by and supporting the one above:

1. Customer experience
2. Customer activities/journeys
3. Business applications
4. Enterprise services

Critically, the user experience is central so we start there and work our way out (top to bottom in the list above). This guides and informs your enterprise architecture choices so your core technology platforms serve the customer experience, not the other way round. It’s the antidote to the all too common mistake of choosing technology first and cobbling together whatever customer experience your prematurely-selected technology allows (see sidebar, “common mistakes when choosing technology”).

You ultimately have to morph your processes and customer experience to fit whatever your technology inherently ‘wants’ you to (and no matter how flexible a vendor says their technology is, every system ‘wants’ to behave a certain way — see sidebar, “Selecting for scenario fit”).

Hopefully it’s clear that this is a job for business/product people and designers in collaboration with IT, not just IT by themselves.

This approach also simplifies the selection process since it provides a functional map of what your technology needs to do for you and to what end. You know what criteria you’re choosing technology for which may well mean you can get away with choosing simpler technology. By designing your own customer experience you’re not relying on a grand orchestrating ‘do-everything’ system to give you one out of the box (which never yields a best-in-class experience). You can instead design your own collection of technologies, each best at what it does, working together to deliver your desired experience.

It’s also easier to swap out technology since you’re not putting everything in one place. Anyone who’s ever had to migrate away from large enterprise systems knows how painful it is to leave technology which has multiple areas of functionality together in a homogenous silo. Also, when you do come to swap out technology, having smaller pieces which a clear reason for existence in your customer experience map means you know precisely what any individual tool needs to do in each ‘slot’ — you already have a spec for any given piece.

This applies to internal systems too

Just because an application is internal doesn’t mean it shouldn’t be led by user experience design. Most obviously, your teams are people too and UX design pays dividends in staff satisfaction and efficiency. But more importantly, internal systems do affect external experiences.

How many times have you spoken to one person at your bank, energy supplier or insurance company only to find they don’t have access to half of your information? How many times have you complained to a company only to have your complaint passed between multiple teams, none of whom appear to know about each other?

Customers interact with your organisation directly through externally-facing applications, indirectly through your employees who use your internal applications, and through the experience of the products and services you ultimate deliver. Their customer experience is the sum of all of those parts, so the UX of your internal technology contributes to what the customer experiences.

Are you saying I shouldn’t involve my IT team at all?

Absolutely not. If anything, our engagements with clients often aim to build processes and culture that develop a stronger collaboration between IT and other areas of the business. IT teams have the potential to act as internal consultants, driving innovation by bringing their knowledge of new technology to bear and contributing to business strategy (in particular, helping develop customer-centric rather than product-centric strategies).

As all organisations become increasingly software organisations, your technology staff will become increasingly embedded across the organisation to bring product and service visions into operational reality. They also have a key role to play in overall customer experience — increasing digitisation means they will have influence over every area of your work so need to be part of more conversations, helping shape business strategy to take advantage of technologies and being guardians of the customer experience.

This last point is important. Since IT will touch every part of your organisation they’re well-positioned to drive user experience and prevent design becoming yet another silo in your organisation. This is also why we work so closely with IT teams — our design and development work is most valuable when we get to work closely with your organisation’s IT department and jointly build out the customer experience and underlying capabilities and technologies.

We’ve already got systems in place. Is it too late?

We often speak to organisations who have a number of different concerns bundled together in an array of vertically integrated pieces of technology. Their marketing automation platform contains customer data, personalisation rules and has some form of identity management. At the time this all looked great — we get all these features neatly integrated in one platform they said.

The trouble is that their web content management system was selected by a different team and it also has customer data, user profiles and a different form of identity management, and their digital asset management system has integrated customer analytics… you get the picture. These platforms all try to be that grand, unifying platform that orchestrates the whole organisation’s activities. From the vendor’s perspective, you can see why — having an organisation shape themselves around your software is commercially brilliant — but it leaves you, the customer, in an inflexible position.

This is a tough (albeit common) situation to find yourself in, but it’s not impossible to move away from. It will take more time, effort and executive attention than if you were starting afresh, as does any change programme or transformation. Start by outlining the ideal future, then form a plan to move from where you are today to there. (User experience teams do this all the time when reshaping an organisation’s services and customer touch points.) The ideal future acts as a programme map to keep the project on track. Your process is then simply one of gradual transformation rather than upfront design. Work through the design stack and then compare your existing architecture with the ideal. This gives you a plan for migrating away from your current stack and into one that better fits your ideal customer experience.

That plan, in its essence, should be to disconnect core capabilities — identity management, customer data, personalisation, analytics, etc. — from the customer-facing systems which they’re currently jammed into and convert them into enterprise services in an orderly way. Make no mistake; this is likely to be a multi-quarter or multi-year process, depending on the complexity of your technology stack.

Not all vendors will let you do this, mind. After all, it’s in their interest to hold you hostage to their platform. These are vendors you should leave. Replace them with a suite of best-in-class, interoperable tools which you can recompose cheaply.

It’s not all bad

The future’s bright. Thankfully, partly due to the increasing power of developers in organisations, we’re seeing more and more services marketed on their interoperability. Payment platforms like Stripe, e-commerce platforms like Shopify, content management platforms like GraphCMS and identity management platforms like Auth Zero all do one thing brilliantly and make it easy for you to build them into your stack alongside other best-in-class technologies. The onus is now on you to create a stellar customer experience and then select the correct components to build out your technology stack.

If you’d like to discuss how to compose your organisation’s technology stack from these smaller, flexible components and regain control over your customer experience, get in touch on email hidden; JavaScript is required to arrange a 30 minute phone call. We’ll be happy to give advice around how to get started, appraise any planning or architecture design you may have already started, or discuss how we could help you.