How do we make Sitecore Personalize more approachable for the digital marketer?
Better empowering the marketer in Personalize looks a lot like empowering content authors in the content management system (CMS). It requires a combination of development best practices and design system planning to create the best authoring experience and consistent user experience. In my mind, these are the primary goals for any effort to improving the authoring experience for marketers in Sitecore Personalize.
Goals
1
Keep the marketer out of advanced edit (HTML, CSS, & JS)
A good “authoring” experience for the marketers involves keeping them out of code and still allowing them to iterate and design quickly, with flexibility.
2
Keep the marketer out of the Developer center
Personalize’s “Developer center” is equivalent to the “Template” or “System” folders in Sitecore’s Content Editor. “Authors” should not be in those sections, period.
3
Minimize the development effort needed per user story
The development needed for each new personalization journey is high. We can cut back on this not just with development best practices, but with being thoughtful about our data template definition for the “components.”
Development best practices
Let’s talk about that will help to empower marketers through ease-of-use and performance optimizations.
Naming
Be thoughtful about your template and variable names to ensure maximum usability. Remember the people that need to use this every day and use their language to increase understanding.
Returning code early
Execution speed is important. JS Module code needs to execute as quickly as possible. As soon as you have the information you need, return it. Don’t iterate through all the data first. Execution speed is important in decisioning, so be sure to keep execution time in mind. If long execution time will create a choppy feeling user experience, marketers won’t use it.
Minimize looping
In the same vein of increasing execution speed, are you retrieving multiple data points from the same set? Do this in the same loop through the data to shorten execution time.
Usability
Make use of forms in decision templates and web templates to keep the marketer out of code. One of our primary goals is to keep the marketer out of Advanced Edit and forms are the primary mechanism for that. Forms are key to marketer usability. It will ultimately be better to have a form for the component with 3 dozen fields on it than to have to develop multiple templates for each variation in color, text, or link. You will hit a critical mass here at some point though where the template becomes too complicated to be reasonably usable. Think of your authors when planning the data template. Tokenize parameter names if you suspect a decision template might be used more than once on a canvas. For Decision Templates, tokenizing parameter names will allow reuse on a canvas where parameters need to be unique.
JS Modules
Think of these as a “library” of useful JS code function snippets to be used in decisioning. Create a different JS Module for each reusable function for code maintenance. Once they are in use, a JS Module cannot be updated. Rather, a new one needs to be created and the existing references updated to point to the new one before the old one can be deleted or archived.
Shared styles
Although we can create instance-specific styles, consider class names and structures defined on the site for consistency and ease of maintenance. An update of CSS class on the site, should affect the Personalize components as well instead of having to update both locations. Ideally, if we update as CSS class on the site, we’d want that to affect the Personalize components as well instead of having to update both locations separately.
Form improvements
Form Help Text
Pre-populate fields in the form with help text and/or an example of an appropriate value. Providing help text is an essential element of a good authoring experience. Without a separate definition for form field help text, we can use the default values to provide insight into the expected value and purpose of the field.
Flexibility
Flexibility is important, but so are guard rails. Think strategically about where it makes sense to enforce the design system and where you can be flexible.
Instead of allowing the user to set any value for a font size, use an enumeration to provide set options.
Like Multi-Line vs Rich Text for same reasons.
You wouldn’t want an “author” in Personalize to be able to specify any font size for an h3 when there are only two allowed sizes for one in the design system, for instance.
Use the design system
Use friendly names for enumerations to add brand colors as options instead of using a color field.
[[ Bar Background Color | enum(White, Black, Brand Red) | #fff | {required: true, values: [#fff, #000, #E40032]} ]]
A color field allows the “author” to set any valid hex code value for a color, but an enumeration allows you to limit that selection to preset options that align with the design system. This still allows an “author” to select a color but prevents them from being able to easily break the established designs.
You can use all of these suggestions to help increase the usability of Sitecore Personalize for you marketers.