Building a scalable DXP - Part 2

Let’s start with a shared definition of the territory. Gartner has a nice definition of a digital experience platform (DXP): “A digital experience platform (DXP) is an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.” 

There are three main aspects of this definition, each of which can vary depending on the specific needs of an organization: 

1. The set of core technologies

2. The content management processes

3. The digital experience context

Let’s unravel each of them separately.

Core technologies of a DXP

The core technologies of a DXP consist of things like a content management system (CMS), customer relationship management system (CRM), digital asset management system (DAM), inventory management system, website, web host, payment processor, mobile application and so on. Core technologies also include any code you write or maintain, DevOps, backups, redundancies, and the technical support required to maintain them. 

The technologies that make up any given DXP typically take center stage in an organization, and staff can usually list several of them by name even if they aren’t on the digital team because, collectively, these technologies tend to touch almost every person in a modern organization in some way.

Content management processes of a DXP

Content management processes are a mix of automated and manual steps that transform, augment and assemble media from ideation to publication. These processes will vary widely from one organization to another, but they typically include things like selecting and editing images, writing and editing content, and updating and maintaining inventory data, like prices and product descriptions. Depending on the size and configuration of your digital team, content management processes can span across multiple teams, each providing their own expertise and applying their craft along the line from ideation to final publication. 

While these processes are typically powered by people, they will also often include automated steps leveraging the core technologies mentioned above. For example, a photographer may manually capture several images for an upcoming article. When the photographer uploads the images to the DAM, the images are automatically resized, tagged and optimized for their publishing context, and an automated message is sent to an editor letting them know the images are ready to be used.

The digital experience context of a DXP

The contextual domain of the DXP refers to where the assembled content is published. Contexts include websites and parts of websites, social media, mobile applications, the Internet of Things (IoT), extended reality (XR) and more. The publication context is one of the more complex components of any DXP because of the variety of contexts in which a piece of content can appear, the amounts and myriad formats of data insights available for each context, and the limited visibility into the minds of individuals who are the end consumers of DX, where the content, context and technologies all come together to provide some sensory experience. 

For example, one piece of content, like a blog or product entry, may appear in a mobile app, mobile website, desktop website, and digital display simultaneously, each with slightly different and nuanced requirements.

Now that we’ve defined the space we’ll be exploring, we’re ready to begin building our scalable DXP. Most companies already have a DXP, so this process focuses on evolving your existing DXP to make it more scalable. The same principles apply to building a scalable DXP for a brand-new organization, but some steps you will need to come back to once you have your team in place. In general, it’s a good idea to come back to this process periodically because even subtle systems or structural changes can unlock new — or hinder existing — scalability over time.

The 5 principles of building a DXP

1. Define your content and its components

Taking a content inventory is the first step in implementing a scalable DXP. Your end-to-end DXP is a pathway for content to come together and be presented for your audience to experience, and ignoring the realities of the individual pieces that make up your content or that are needed to make it successful will ultimately inhibit scale. Think of content as anything you want your audience to encounter independent of the context in which they will experience it.

Start by listing out each type of content, such as static pages, blog entries, product pages, etc. Then, list out the components that make up each of those types of content. Here, you want to capture details that show how the media is assembled for the end user. For instance, if a blog entry has a hero image, body text, excerpt, author and other metadata, document it. Likewise, if a product page includes five photos, a video, a 3D walkthrough, a price, a SKU and a call to action button, note these details, too.

If your organization has a lot of existing content with a lot of variation, which is often true of large and growing companies, then you may want to consider creating one version of your inventory document reflecting your current content and dependencies and another version reflecting a more ideal and streamlined state. Similarly, if your business maintains hundreds of websites, you may only want to focus on one specific content segment in your organization, like your corporate newsroom or product catalog.

A good rule of thumb is to try to keep your content inventory documentation simple and clear. At this step, you don’t need to list things like social media posts if those posts would just be redistributing content you originally published elsewhere, like on your brand website. The purpose of this step is to assess the breadth of your content and the components that comprise it, and to create an anchor for your team as you work toward a shared understanding of context and process.

2. Define your contexts

Now that you have an idea of the content your team will be publishing, it’s time to document the contexts in which it will appear. In this exercise, start by writing down everywhere your content may appear to your audience. This document will likely include publishing destinations like the web, mobile apps, digital signage, social media, ads, mailing lists, voice UI, podcasts, etc., and it may also include subcontexts if there are important distinctions that affect content production for any given context, such as differently sized mobile devices, accessibility tools, and the variety of social media experiences.

Contexts can become overwhelming very quickly; they include how content is presented through any device and how and when individuals interact with it, like in the morning or while driving. Because of this reality, the goal of this step is not to exhaustively list every possible context you can think of. Instead, focus on the contexts you can directly control that require significant differences in content assembly. For example, it might make sense for your list to include individual contexts for Twitter and Facebook because you actively craft different and unique content for each platform. But it may not be important for you to list iOS and Android as different contexts for your mobile website if the same technologies and content power both experiences.

Referencing your content inventory, note which content appears in which contexts. While it’s common that most content appears in some fashion across each context, that’s not always the case. A voice UI app may read a blog post to your users, but the context doesn’t allow for images. Similarly, you may post blog entries that feature products to your social media accounts but opt not to post actual product page content on its own.

The important insight to gather at this phase is the variety of contexts in which your content appears. This is important because content needs to be optimized for its context. For instance, the same blog hero image may appear across multiple contexts, but it may require different sizes when presented in each context to provide the best experience. It is a fundamental necessity to understand the content moving through your DXP to this level of detail. By having a firm grasp on your content’s components and the variety of contexts in which your users experience that content, you will be well equipped to design efficient systems and processes to create and publish that content.

3. Walk a mile

Human-Centered Design (HCD or “design thinking”) is a powerful philosophy and rich set of tools that can empower any digital or technology team. One such tool is called a “walk-a-mile immersion”, which is the simple process of walking a mile in someone else’s shoes. Envision an assembly line where every step contributes some value to the end result of your content being published in a variety of contexts. The assembly line has stations where certain processes are performed by your team as components are created, put together, and modified before final delivery.

In this step, you talk to each team involved in creating, editing and managing each content component. You get to know the systems in use, the scope of their functionality, and how the individuals on your team use the tools. If you are creating a new DXP or building a new team, then envisioning and jotting down hypothetical teams and content handoffs can work just as well. The goal of this step is to document each of the key steps and tools used along the path of creating your content, from ideation to publication.

For example, if you maintain an inventory database, a DAM, a CMS, a CRM — or if you use desktop tools or a monolithic system — document all of them along with the nature of the work and effort involved in completing each step to produce your content. If ideation starts on a whiteboard and your content is published in five different places, document the steps, systems and effort required from the beginning to the end.

At the conclusion of this step, you should have a clear understanding of your content and its components, the many and varied places your content appears, and the processes and systems your teams leverage to create, edit and publish content.

4. Analyze your assembly line

By now, you’ve documented your content and contexts and have a map of the systems and processes required to take your content from ideation to publication. In this step, we analyze the content assembly line to highlight steps with high effort and low added value to set the stage for scalability.

Start by looking for duplicative effort and content. For example, if your team has to create multiple different sizes of an image to publish in each of your contexts, or if your team has to perform manual, repetitive tasks that add low value and require significant effort, then these are opportunities for improvement. Look for how upstream ingredients, like product pricing and inventory systems, feed into your CMS and are married to descriptions, images, reviews and more. 

In legacy DXPs, many of these steps and processes can occur in one or just a few systems, but modern DXPs will typically have various systems, allowing for specialized focus by team members at discrete touch points along the content assembly line.

Identify steps and processes where teams typically report being blocked by other teams. Any team or process blocked by another team or a previous step in the assembly line often indicates that optimization is needed upstream. If the content publishers in the final step of your publishing process are always waiting or having multiple conversations for images to be resized, for instance, this step of the process is a potential opportunity for improvement. 

Once you highlight areas with high effort, or “friction”, shift your focus to steps and processes that are efficient. For example, if you have a backlog of ideas that are waiting to be realized into articles or a backlog of products in need of descriptions, these surpluses likely indicate high efficiencies at these steps, which means other steps and processes could potentially improve to meet these efficiencies.

At the conclusion of this step, you should have a clear picture of the end-to-end assembly line for creating and publishing your digital content, including all elements, assets, texts, metadata and other media coming together for final publication in each given context. You should clearly see each individual system used for each step in the assembly line, as well as every human process and general level of effort required along the way for a piece of content to be published. 

For e-commerce DX, this might mean understanding the processes in the back-of-house where pricing and inventory levels are kept up to date, combining in a subsequent step to add ancillary product metadata and media, being checked in a following step for accuracy and legal compliance, and finally being deployed to a live site, where it is cached on a CDN for low latency access. For a media organization, your assembly line may instead start with ideation in a Trello board, followed by an outline, and then a draft, and finally combined with image assets and published in a CMS that feeds into a newsreader app. 

The number of potential combinations of steps in creating an assembly line is virtually limitless, and at this time there is no single right way to structure these systems and processes. Though, as you may now be able to see in your assembly line, the number of wrong ways to do it is also myriad.

5. Strategies for scale

Honing in on your digital experience assembly line and locating areas for improvement is enlightening, but without instituting real and intentional change, the friction remains. Now that we know where lie the strengths and weaknesses in our existing processes, how do we prioritize and implement changes that scale?

If you’ve successfully completed each previous step, you should be able to readily identify two or three places in your assembly line that clearly stand out as higher effort or higher cost of input than other steps in your publishing workflow. In some cases, friction is expected, such as in the actual writing of articles or sending teams out in the field to gather photos or raw audio that must be edited by hand. In other cases, you may identify a step in the process that always seems to be blocked, such as a publishing team waiting on transcripts, translations, file format changes, image resizes, SEO metadata, and so on.

Begin by prioritizing repetitive tasks. Any high volume of repetitions performed by a human often indicates that there is a more optimal process available. Examine the systems used at this step and determine if they provide the most up-to-date tools to perform these operations. For instance, many DAM and CMS solutions automatically resize images and store them in multiple formats optimized for various contexts. There are also very good tools that automatically transcribe audio and translate text into almost any language, which could significantly reduce these high-touch steps in your assembly line. 

Optimizing your assembly line for scale will typically involve a combination of reorganizing processes and workflows to improve the pace of handoffs from one step to the next, along with updates to the core technologies your team uses to realize your digital experience.

Composable DXPs are on the rise

In recent years, there has been a trend toward composability, wherein digital teams are looking deeper into their publishing workflows in order to combine the best set of tools for each step of the process. 

Composing a DXP is the opposite of purchasing one single off-the-shelf system. When you adopt a composable approach, you accept the reality that your business needs are unique, and it’s unrealistic to expect one or two products alone to offer everything your team needs exactly how you need it, given the variety of content and contexts your digital experience can take on. 

The most essential need for the systems that make up your DXP is interoperability, which is often referred to as “API-first”. Application Program Interfaces (APIs) allow systems to talk to one another and share information in a safe and secure manner. For your business, this unlocks the possibility of automating hand-offs and removing blocks where content components are manually delivered to the next team for assembly. Webhooks and automation tools leverage APIs and are extremely handy to let you remove rote human-powered processes and exchange them for more efficient machine-driven processes. 

Headless CMS is another popular solution, which focuses the content management in a single-purpose powerful solution designed for managing and shipping your content to virtually any context without needing to make any changes to your core systems — you simply deploy a new app, website or other technology that safely consumes content via your APIs.

Where you find one single product doing most of the work in your assembly line, chances are that there is high friction between it and any adjoining steps in your publishing workflow. These systems also sometimes lead to siloed teams and ivory tower cultural friction between those with access to the monolith and those without access. 

Benefits of composable solutions

By replacing a monolith with a multi-product platform with focused independent interconnected tools or a variety of API-connected solutions that focus on doing one or just a few things extremely efficiently, you hedge against siloing and begin to move in the direction of more streamlined processes. 

Moreover, many composable solutions are extendable, meaning that you can integrate them with other systems in a few clicks or lines of code. And if one solution becomes too costly or fails to unlock the efficiencies you are looking to gain, then it can be relatively easily replaced without the need for a wholesale migration or hugely disruptive technology change.

What’s next? Unlock the scale of your DXP

When you complete this step, you ought to finally have the complete picture of your end-to-end digital assembly line, along with each system, team and process that must work in concert to create and deliver your digital content across your chosen contexts. From this vantage point, you can easily identify where scale is blocked and where it is already well established, as well as which areas stand out as the highest priority to optimize first. You will be ready to begin taking action to unlock the scale of your DXP.

In part three, we will cover the only question left to answer: Why should you scale? Stay tuned!

To read part one, click here.