Service Design: We Built All These Apps. Now What?

Over the past couple of decades, companies have spent an incredible amount of time and money building digital products. We have customer-facing websites, mobile apps, employee applications, dashboards, reporting tools, portals, workflow systems and just about anything else you can imagine. Most of these products started with a legitimate business problem that needed to be solved, so a team was formed, money was allocated and something was built.

There is nothing necessarily wrong with that approach. The problem begins when you repeat that process for 10, 15 or 20 years across a large organization.

Eventually, you have a lot of stuff.

One business unit may have built an application to solve a problem without knowing that another business unit was already solving a very similar problem. One team may be using Salesforce while another has built something internally. Another team may have hired an outside vendor. Each application may have its own database, business rules, authentication, reporting and ways of defining what essentially amounts to the same information.

Individually, each decision may have made perfect sense at the time. Collectively, however, you can end up with an organization that has built the same thing twice, sometimes three times, and created an enormous amount of technology that doesn’t necessarily talk to itself.

This is where I think service design becomes increasingly important.

We designed products instead of designing the service

For a long time, UX has primarily been associated with what happens within a digital product. We research users, understand their needs, create user flows, prototype ideas, test them and hopefully build something that makes their lives easier. As our design teams matured, we also created design systems to bring consistency across products. All of this is valuable and I certainly wouldn’t argue otherwise.

But there is a larger problem that UX alone cannot solve.

A customer doesn’t care that your billing application belongs to one department and your customer service application belongs to another. An employee doesn’t care that inventory was built on one technology stack and fulfillment was built on another. To them, they are simply trying to accomplish something.

The organizational structure behind the experience is invisible until it gets in the way.

This is something I have seen repeatedly while working within large organizations. Different teams are often solving different portions of what is really the same service. Everyone is working hard and everyone has good intentions, but each team naturally views the problem through the responsibilities they have been given.

Product sees a product problem. Technology sees a technology problem. Operations sees a process problem. Business sees a financial or performance problem. UX sees an experience problem.

Who is looking at the whole thing?

That is the opportunity for service design.

The problems aren’t always on the screen

Let’s say an employee needs three applications to complete one task. They start in one system, find a piece of information, copy it into another system and then go into a third application to finish the process.

The immediate UX reaction might be to improve those three applications. Maybe we can reduce clicks, improve navigation or create a better dashboard.

But why are there three applications?

That question can lead you somewhere very different.

Perhaps one system contains customer information while another contains transaction information. Maybe they were built by separate teams five years apart. Perhaps the systems can’t communicate, so employees created a manual process to compensate for the technology. That manual process then became part of training, which eventually became accepted as simply “how we do it.”

Now imagine that process multiplied across thousands of employees.

One extra minute doesn’t sound like much until 10,000 employees perform the same task 20 times a day. A few unnecessary clicks suddenly become thousands of hours. Add duplicate data entry, training, support, maintenance and licensing for overlapping systems and something that initially looked like a minor employee inconvenience becomes a significant operational expense.

At that point, redesigning the button isn’t going to fix the problem.

You have to go further down.

The backend is part of the experience

Designers naturally spend a lot of time thinking about the interface because that is where people interact with the product. But the interface is only the visible portion of a much larger system.

What happens when someone clicks that button?

Where does the information come from? Who owns it? What business rules determine what happens next? Which system receives the request? Does another employee need to do something? Does the information move automatically or is someone copying it somewhere else? What happens if something fails?

Those questions start moving us from product design into service design.

I think this is especially important because interfaces will always change. I’ve been designing digital products long enough to watch countless visual trends, interaction patterns and technologies come and go. We redesign navigation. We update components. We create new design systems. We move from desktop to mobile and now into conversational and AI-driven experiences.

That will continue.

A good foundation gives you the ability to change what is on top of it.

If the underlying operation is well designed, you can change the interface without rebuilding the organization behind it. If your data is structured correctly, your systems communicate and your business rules are understood, you have options. Today’s mobile application could become tomorrow’s AI assistant and the fundamental service can continue to work.

If the foundation is fragmented, every new experience inherits the fragmentation.

Service design needs to go below the journey map

Journey maps are useful tools, but service design cannot stop at documenting the customer journey. If anything, that should be the beginning of the conversation.

We need to look underneath it.

What people are involved? What systems support them? What processes have developed around those systems? What policies influence those processes? Where is the data? Who owns the decisions? Where are the handoffs? What happens before the customer enters the journey and what has to happen after they leave?

A service blueprint can begin exposing those relationships. When you put the customer experience on top and then begin layering employees, processes, systems and technology underneath it, some interesting things usually start to appear.

You find duplication.

You find gaps.

You find manual workarounds.

You find two teams solving almost the same problem.

You find information being collected multiple times.

You find employees who have become the human API between two systems that don’t communicate.

And sometimes you discover that the application everyone wants redesigned isn’t actually the problem at all.

Someone needs to work between the pillars

This may be the biggest opportunity I see for service designers today.

Most large organizations are divided into pillars for good reason. You need people responsible for technology, product, operations, finance, customer experience and the many other functions required to run a business. The difficulty comes when the customer or employee experience crosses all of them.

Someone needs permission to move horizontally.

A service designer should be able to sit with an employee and observe how the work is actually being performed, talk with product about what the application is trying to accomplish, work with technology to understand the systems and dependencies underneath it, and then bring those findings back to business leadership in a way that makes the entire problem understandable.

That does not mean the service designer becomes the architect, engineer, product manager or operations leader. Each of those disciplines has expertise that needs to be respected.

The service designer helps everyone see how their decisions affect the service as a whole.

There is a management component to this as well. Once you discover that five products depend upon the same capability, someone needs to determine how that capability is governed. If two teams are building similar functionality, there needs to be a way to recognize that before both teams spend the money. If changing one system creates downstream problems for three other teams, those dependencies need to be visible.

Otherwise, we continue doing what got us here: solving local problems while unintentionally creating enterprise problems.

Maybe we don’t need another app

This is a question I think organizations should become much more comfortable asking.

Every new application carries a cost beyond the initial project. It has to be maintained. Supported. Secured. Updated. Integrated. Documented. Governed. Employees may need to be trained on it and customers may need to understand it.

Before building another one, perhaps we should first understand what we already have.

What capabilities already exist within the organization? Where are they duplicated? Which systems are foundational? Which should eventually disappear? What information should be shared? Where should business rules live? What does the ideal service actually look like if we stop thinking about the organizational chart for a moment?

These are not particularly glamorous questions. There may not be a beautiful prototype to show at the end of the first week.

But answering them can save an organization from spending millions of dollars solving the wrong problem.

The next horizon of design

I believe this is where our industry is heading.

We spent the early years of the web figuring out how to get businesses online. Then we spent years improving usability and building better digital products. We developed UX practices, research teams, product organizations and sophisticated design systems.

We became very good at designing the pieces.

Now many organizations have enough pieces.

The challenge is understanding how those pieces work together.

Service design gives us a way to zoom out far enough to understand the entire service while still being able to zoom in and understand the individual experience. It connects what the customer sees with what the employee does, what the business requires and what the technology makes possible.

The UI will change. The technology will change. Even the applications themselves will eventually change.

The foundation is what gives an organization the ability to absorb that change.

Perhaps the next major design challenge isn’t figuring out what else we can build.

It’s finally stepping back and designing how everything we’ve already built should work together.