What was Experience Cloud called when you were first introduced to it? Whether it was Sites, Portals, Communities, or the latest Digital Experiences, it’s a powerful product on the Salesforce platform, allowing you to leverage the data in Salesforce in custom websites. This is one complex product, it took me 3 attempts to pass the certification exam, the only one I broke down and purchased study notes for!
As a Salesforce UX designer with a background in web development, I naturally gravitated to Experience Cloud as it provided many creative design opportunities. As you might expect, many skills were easily transferable. In this blog, we’ll look at best practices when designing communities in Experience Cloud. I’d like to focus on 3 categories specifically:
Design planning
Design systems and branding
Design optimization
Naturally, let’s talk about planning first.
Design Planning
During the design phase, it’s important to plan out as much as possible. Of course, in an agile environment, even the best planning won’t account for everything, but here are a couple of design planning considerations that will greatly avoid future technical debt.
Customization
Right off the bat, when creating a community, we’re asked to select a template.
This is an essential decision because it not only defines how the experience looks but also the features that are supported. Furthermore, it will be much harder to change this template once we’ve developed some content. This selection determines two templates, the Experience Template and Theme Template. If you select a Lightning Web Runtime (LWR) template, this cannot be changed. All content will be lost if an Aura Template is changed. Here’s a list of customizations we’ll lose if need to change the Theme Template later1:
Branding sets
Theme regions (settings for common elements across pages like headers)
Theme settings
Custom theme layouts
Custom theme layout assignments for pages
Custom CSS overrides
That’s why it’s paramount to plan out the level of customization early on. For example, deciding between using a pre-built template or the "Build Your Own" template. Check the resources at the end of the blog for some great articles on how to decide which template you need. Make sure to test the template in a scratch org or sandbox first before you ever create the site in production.
While we’re on the subject of customization, I’d like to debunk a common myth. Most Experience Cloud projects I work on start out with as few customizations as possible, thinking it will be cheaper to stay completely “out-of-the-box.” However, every Community needs some level of customization at some point, and it’s very often more expensive to add later. Why? Because it ties the developer's hands from using robust components where they would have the most control and forces them to attempt “hacky” solutions. For example, using custom CSS overrides in the builder instead of clean styles from within a component’s stylesheet, which are much easier to develop and maintain.
How to Deploy Design Changes
Something else that should be planned before creating any content is how design changes will be deployed to sandboxes and production. Do you want to enable and use the ExperienceBundle Metadata API? This API allows configurations of an Experience, such as branding, themes, and layouts, to be deployed as an ExperienceBundle via the Metadata API rather than through the old Site.com Studio. This feature can be enabled at any time, but it makes things much less complicated if turned on at the start of the project. This API may be more appealing for teams with a sophisticated deployment strategy like Continuous Integration. Of course, Admins can also make design updates declaratively.
Design Systems and Branding
Next, let’s talk about branding. Salesforce has one of the best design systems I’ve seen, but chances are, you want your Experience Site to look like your brand, not Salesforce. Salesforce even goes so far as to make common components like buttons and tabs look different in Experience Cloud.
Internal Experience Cloud
For most companies, it’s not enough to not look like Salesforce, but there needs to be a consistent look and feel across multiple external channels. You don’t need a large design team to start creating your own design system; start small and build it over time. Even a one-page document is better than nothing. Don’t wait until it becomes painful to start! Here are some initial key topics:
Let’s start with the obvious ones: Logo, font, and colors. These simple elements can be controlled with branding sets. You can edit branding sets directly in the Experience Builder, or you can be savvy and deploy them via the ExperienceBundle Metadata API. They can also be assigned to specific audiences. This is a great way to apply personalization to your site and drive user engagement.
Branding sets, however, only give you limited control over the branding. Some color settings control multiple features, and you’ll need to employ some custom code to change that. For example, in the “Ember” template, the active menu item, action color, button color, and tile menu header are all controlled by the “Action Color”
And what about other style properties such as rounded corners, color, and hover? Looks like we're going to have to get some CSS involved.
Your design system should also include patterns for the most reusable components, such as buttons, inputs, and prompts. A great reference to start with is the Salesforce Lightning Design System Component Blueprints page. In my humble opinion, two components that give away Salesforce under the hood faster than any other are illustrations and spinners. Speaking of spinners, remember best practice is to use stencils for preloading entire pages.2
Finally, provide guidelines around typography (as opposed to simply font), sizing, and spacing. For example, do the standard SLDS font sizes3 work for you, or do you need to define your own font hierarchy? In addition to body and headers, consider component text as well, such as buttons, input labels, and card titles, just to name a few.
Design Optimization
In today’s mobile-first world, everyone is aware of the importance of website speed. From a quick search at the time of writing this blog, 40% of visitors will abandon a page after 3 seconds of loading4. While performance is usually more reliant on the underlying code than the design, there are some ways designers can contribute to improved performance.
Most commonly, design assets should be optimized. Images should be reduced to the smallest possible size to prevent distortion. File format is important, too, as JPEG is generally more optimized than PNG, but even better is a vector graphics file such as SVG. SVGs are not compatible everywhere in an Experience Site, and unfortunately, this format cannot be uploaded as the site logo.
The next thing is to minimize the amount of CSS that needs to be loaded on every page. This means striving to add CSS to individual pages or components rather than the overrides in the theme. While CSS doesn’t seem to contribute much to performance, this is a slippery slope, and styles can add up quickly.
The last tip here involves designing components with hidden or dynamic markup. Postpone server calls or other slower processes until the user takes an action to request that feature, rather than when the page loads. For example, let’s take a chart that makes an external callout to retrieve data. You could postpone the callout until the user clicks a button rather than on page load while other elements may be rendering.
Example: Chart is built on button click to avoid running callouts on page load
Conclusion
Well, there you have it, my short list of Experience Cloud best practices. Remember to give careful consideration to customization and deployment early on. Get started on that design system before it becomes painful. Finally, we looked at optimization from a design standpoint. Make sure to check out the resources below. Until next time!
Resources
Which Experience Cloud Template Should I use?
Considerations for Changing Your Template
References
