The Blind Spot in Digital Initiatives

A few weeks ago, I saw a meme that resonated with me. It had the format of a survey question, and it went something like this:

Who initiated your company’s digital transformation?

A) CIO
B) CTO
C) COVID-19

Cue nervous laughter: all-too-real. Our response to the pandemic has wrought major changes. For one thing, everyone who can do so is now working from home. Businesses are scrambling to figure out how to best serve their customers in this new reality. There’s also a palpable sense that many of these changes will persist after the immediate crisis passes. As a result, many companies are looking for new ways to provide value over digital channels.

Most recognize that there are two aspects to digital initiatives. On the one hand, there are technical considerations: selecting and configuring infrastructure, developing applications on that infrastructure, and so on. We can think of these as the “how” of the initiative: How will we serve these customers? Should we host systems on our premises, in the cloud, or some kind of hybrid solution? Should we develop solutions internally, or should we buy an off-the-shelf product? Etc. These types of questions have traditionally been the domain of IT teams.

On the other hand, there are experiential considerations. These aspects of digital initiatives deal with the experiences customers will have when they interact with our systems. Rather than asking “how,” experiential considerations focus on “what”: What can we offer customers to satisfy their expectations and needs? What will help customers succeed when using our products and services? These types of questions have traditionally been the domain of product and design teams.

These two aspects of digital initiatives inform each other. On the one hand, you want to implement systems and solutions that enable the desired experiences, given the available time and resources. On the other hand, technical infrastructure has capabilities and constraints that determine what’s possible. Organizations must strike a balance between what’s desired and what’s feasible; this calls for collaboration between designers and technologists.

These conversations happen at different levels. At the highest level, there are strategic discussions. These have to do with making decisions that align with overall business goals and approaches. For example, an organization that serves business customers will have different needs than one that targets consumers. The decision of which market to serve will impact the organization’s technical and experiential responses.

At the lowest level, we have tactical discussions about how to execute these strategic decisions. For example, we may be called to deploy a particular software solution within a specific time frame or design a prototype we can test with customers. We can call this the level of execution.

As with technical and experiential requirements, the strategy and execution levels inform each other. It’s easy to imagine how strategy informs tactics, but the reverse is also true. A solution’s implementation particulars will often determine the type of feedback that will guide future strategic decisions.

You could render these relationships in a simple matrix:

2x3 Technology-experience matrix

This chart may seem self-evident. However, the reality is a bit more complicated. You don’t go straight from strategy to tactics; there’s a layer between them where we consider the broader impact of individual decisions, and vice-versa.

You see, we’re not just concerned with creating individual solutions: we also want to drive integrity, coherence, and efficiency on the whole. For example, if you’re on the technical side, you want to select software that plays well with other components you’ve chosen already. These types of decisions are still about executing on the strategy, but they’re not really tactical; they’re somewhere between the two. In this model, we’ll call this the architectural layer.

This architectural layer is understood and valued in IT. Many organizations have roles dedicated to thinking about how technical system components work together to create platforms. A tactical solution that doesn’t play well with the organization’s infrastructure may be cheap to deploy in the near-term but will likely have other — perhaps more onerous — costs in the long-term. System architects aim to achieve security, efficiency, and integrity by looking for opportunities to standardize solutions, while also allowing the infrastructure to evolve in response to changing needs.

There’s an analogous need on the experiential side. We want to create digital experiences that feel coherent to customers as they go from one part of the system to another, and help them achieve their broader goals. New services should reflect an overall direction that considers interaction patterns, language, sequencing, and more. Digitally-savvy organizations that manage large information environments codify parts of these frameworks as design systems.

Note that I said they codify only “parts.” That’s because many design systems focus more on defining individual components than on interaction patterns, semantic structures, and choreography — that is, on how elements come together to create coherent experiences. An effective architectural framework for digital experiences is more than a set of building blocks. Still, design systems are a good start towards driving this level of work in digital initiatives.

However, architectural thinking isn’t the norm. Many organizations aren’t aware this layer even exists. I often find myself in conversations where a prospect has pegged me either as a strategic consultant (i.e., one who will help them align their design initiatives with business goals) or a “UX designer” (i.e., one who will help them design touchpoints that customers will find usable and engaging.) Lacking widely-understood models to talk about this type of work, and examples to envision it, many lapse towards what they do know: UX design = wireframes. Squarely on the execution level.

Organizations that ignore the architectural level are poised to miss key project considerations. More often than not, the result is underperforming solutions that require expensive and time-consuming re-designs. I can help these organizations by designing architectural frameworks that enable successful digital experiences. The challenge is that they don’t know to ask for it.

2x3 Technology-experience matrix

The coronavirus crisis has nudged more organizations to look for ways to offer value to their customers over digital channels. Many of these companies aren’t “digitally native.” Still, they want to respond to the changing market, fast. Regardless of their level of digital maturity, all want to create digital experiences that create value for their customers while respecting financial, legal, and technological constraints. Organizations can only succeed at this by approaching digital initiatives not just as sets of screens to be designed, but as systems to be architected.