Increased Content Productivity with XM Cloud

This blog is the follow on from my talk shared with the Sitecore Community. It comes from my experiences working alongside the wonderful team at BDR Thermea and my colleagues at Avanade/ Accenture Song. With that said, issues and recommendations in this post can relate to any organization/ client.

Understanding the problem

So it is worth noting down some of the factors at play. 

• Several sites in play, all on differing versions of Sitecore
• Installs were mostly independent of each other so “sharing” code is challenging
• Teams (both developers and content editors) differ greatly. From inhouse to outsourced, from small to big
• From the top there is unity, however given the above points, it becomes a challenge to plan globally or act with agility

As mentioned these are very common to big global organizations, which tends to lead them to a switch/ upgrade in tech stack (to solve the problem). But it’s worth noting, tech alone won’t solve this, we also need to consider modernizing the ways of working.

When it comes to the jump to XM Cloud (more so the decision) we hit on 2 common themes as to why. 

First was that balance of costs vs a standardized tech stack. 

• Multiple sites/ instances, whilst needed, often mean inconsistencies in approaches technically. XM Cloud gives us that ability to have standardization at a global level, but equally allows configuration at local level. Win Win
• Logically one instance helps manage efforts and costs. It also helps when it comes to upgrades and the efforts needed to migrate given the volume of sites as individual configurations.

Second was the improvement to experiences of those that use the tools. 

• XP, from a content perspective is often perceived as complex and not easy to generate content at speed. We knew instantly that the pages interface would help with this. But we knew that other component features of XM Cloud would positively impact the editing experience.
• Having one instant, with that standardization would also drive content editor experiences through knowledge sharing, an activity often lacking due to individuals using custom setups. XM Cloud lets us harvest that community aspect, bringing editors around the globe together driving their knowledge. 

Working with design systems and design tokens

So whilst XM Cloud out of the box would give us massive improvement to the editor experience, the challenge of multiple brands, design systems and how they worked alongside Sitecore components was still to be solved. 

Enter Figma and design tokens. 

For those that don’t know. 

Design systems are a collection of reusable elements, starting with foundations (fonts, spacing, iconography…), components (interactive elements to create the user interface), building blocks (collection of components into a focussed space), and finally page templates (the underlying content structure of a page). The system is connected as one, so when a brand changes so does the system.

Design tokens are that design system, broken down into small design decisions. (rather than locked in static values.) It is the token we add to the code, hence the ability to seamlessly update the design system, update the token and thus update what the user sees at speed. FYI this still goes through releases to ensure QC, however is much quicker than individual tickets to amend static values. 

Design tokens also help with multiple brands. We can (at the flick of a toggle) jump from brand A to brand B, styling all design system elements in one go. 

What did this mean to this project?

• When creating a new site, users would assign a brand. This then leveraged that set of tokens and applied it to all the components in seconds
• With a design system available, editors could familiarise themselves with it pre Sitecore. Work out which templates will be available, which components work with others, how components will work… All helping that upskilling and content creation velocity
• They were supportive of the brand and the design system; knowing it was something they could largely “leave alone”. No more custom CSS hacks or worrying if the right styling was picked. 

Building for content

With the power of XM Cloud and Figma, content migration was a go. But there are some things to consider to make content creation as efficient as possible. 

Information Architecture

Utilizing scaffolding allowed us to preload an IA to speed up content migration.
TIP Work early to define your IA along with key templates/ components

Page designs and partial designs

These are handy features, but their use is a balance. Freedom to build anything (basic templates) vs speed to deploy (use of partial designs/ component rich templates).
TIP Find out what components will be the most reusable. Structure around them

Component options (manage items, layout, styling, advanced styling)

This is where we can enhance the tool and align it to a design system. For example using styling options to manage the components variants.
TIP Language is key, but also functionality. Think content editor first!

Work the system not the editor

Make the editor do less, not more.
TIP Deal with those challenges such as alignment, heading hierarchy, leaving fields empty… Remove them or just leave the minimum needed.

Component naming/ grouping

When we add components or options, tie this back to the design system by using the same words/ language. This has been their playground so keep things familiar

Build for the future

“Components” is coming (a bridge between the Editor and FE roles). Think now on how this will be of value.
TIP Ensure brand/ design system is in place!

Observations

1. Sitecore Pages is not Experience editor

When developing for XM Cloud it is important to build for Pages as it does not offer the same options as Experience Editor. Keep the editor in mind both in what they see and how they can interact with it. 

2. Early involvement important

Whilst internal teams are discussing brand and the development team are building infrastructure, it is important both play with the tooling.

3. Share experiences

With a limited knowledge base, you have to create your own. Make sure devs and content creators alike are talking

4. Manage expectations

We know some functionality is missing (forms etc). You might have to think out the box or use XP solutions in certain situations

5. Logical releases

Sounds obvious but build and release templates/ components in the right order using thought out user stories. Pointless to release something an editor can’t use due to a dependency in a future release

6. Work with the Sitecore Product teams
Again, sounds obvious, but we are all learning and improving the tool together. And together we will make this better

Outcomes

To date we have some amazing results

• +790% Productivity increase in page creation
• +50% Performance increase – back office activity
• +79% Page speed improvement (desktop)
• +390% Page speed improvement (mobile)
• Very Happy Content Editors and Developers alike

We have built something that has the “Build Global, Configure local” at it’s heart. One design system, One Sitecore instance, but equally a design system with multiple brands and a Sitecore instance with 100’s of permutations from the globally built templates/ components.

For more information on the project is on Sitecore’s Blog or at a DX Event near you!