Workflow - Substitutional Query // BloomReach CMS
Improving the Content Selection process for admins
Lead product designer
ROLE
Mar 2024 - May 2024
TIMELINE
The challenge
Content curators and admins have been using the BloomReach CMS to manage pages, modules, and sections of the Audacy platform. When new content blocks were added or edited, there was a lot of manual work being done to select Stations, Shows, Podcasts, and Episode entities due to an under-utilized and advanced feature: Substitutional Queries.
One of our Product Managers identified this problem, and saw an opportunity to improve the console experience.
Understanding the current flow, and what needed TLC
Admins had to make hundreds of content-specific blocks to use on pages in the existing CMS. This was obviously archaic, unnecessary, and could be streamlined. For example, each Podcast Show needed it’s own Content Module to pull newest episodes.
Sidenote: while on this project, there was no Bloomreach design system access. This was one of those scenarios where screenshots had to be pulled from the CMS directly, and new components / design elements were built separately to hand off for engineering. Material 3 libraries were used as a foundation to match the BloomReach interface.
Choosing filter parameters to Substitute
If a Filter Type in an Episode Query was selected as “Substitutable”, then the content blocks could be used more generically by allowing the admins to use the base parameters set up in these Content Blocks, then substituting the default Filter with custom Filters of their choice, allowing flexible use of Queries.
Potential use cases:
New (ESPN) episodes related to (Boston Bruins), with the (Boston Bruins) value to be substituted by other (Teams)
Any Podcast episodes filtered by Genre Tag (Sports) with the Leagues filter (NFL) substitutable.
Shows entity (Boomer & Gio) substitutable, always mentioning Team (Buffalo Bills).
In the screenshot you see on the bottom-right, the original Substitution CMS consisted of an editable searchTerm field, where admins had to manually input code to override the original Filter... and they never used it.
Problems to solve:
Filter parameters
How do we determine all the possible Substitution options for common Filter parameters?
Allowing Include and Exclude rules
How do we create flexible Queries for admins to select (Include Content) and (Exclude Content) in the clearest way possible?
Improve usability and save hours of work
How do we design and build an improved experience that admins will be excited to switch to?
Error checks
How do we empower admins to confidently use Substitutional Queries without return errors?
Avoid duplicates and redundancies
How do we avoid redundant or duplicate Queries from being created in the future, so that the CMS isn’t bloated?
Enhanced content previews
How do we give admins the tools they need to effectively preview content after using Substitutional Queries?
Starting with most common filter: Show entity
In order to solve for all Substitutable content types, I took inventory of Objects for the most common and complex scenario: Show entities. These were the Query types our admins worked with the most, and could return the messiest results due to the amount of content that could be returned.
Initial design & follow-up edit
After a few conversations with the PM and Eng, the design phase kicked off. Despite there being unanswered questions for edge-cases etc, we wanted to review overall direction with Admins. These review sessions would be extremely valuable for first impressions and whether we missed anything that hasn’t been considered.
Version 1 Feedback (Left image)
The addition of Exclude rules was desired.
Information pills in the Filter container were useful and appreciated by the Admins and Eng team.
Selection Preview was well-received, but could be simplified.
Heading text felt redundant, especially for Queries with multiple Substitutions (as pictured above.)
Version 2 Edits (Right image)
Exclude rules were added
Information pills were edited to reflect Query Parameters more effectively
Only essential items were displayed in Selection Preview.
Heading text was adjusted to remove redundant information.
Columns were edited to display information more clearly and allow the UI to be more flexible for complex Queries.
Use case sample design: Admin is selecting [Shows] based on [Team Name] to display on [Team Page]
In the first round of designs, I sampled the hypothetical use case of an admin selecting sports shows from 2 competing teams to display on a team page.
Previewing selections
One of the problems to solve in this project was to give Admins the confidence in knowing their selections will return desired results on the pages of their choice. Therefore, a new screen was designed with a preview section, a recap of the query, and selectable pages to generate previews on, especially if the Query is generic and will use the Parent page as the primary data source.
Avoiding duplicate and redundant Queries
In order to not bloat the CMS and slim down the list of Show Queries, naming guidelines were proposed. The naming of these Queries should be descriptive of Substitutable Values, content parameters included in the Query, and would ideally display pills for easier scanning.
Tooltips & info modals
We can’t expect our admins to know the meaning of every term used in this new workflow. Of course, informative modals and tooltips should be available for users, so that they understand the queries and settings using simple language.
Setting number of results to display
Admins should also be able to select how many items would be displayed in the content modules. Whether a module is going to be a long scrolling vertical list, or a short horizontal display of cards, they need the flexibility to decide the minimum and maximum # of objects that will appear.
Samples of other Substitution Filters with varied content types
Feedback from admins and engineering
We ran a demo and test session with our engineering and product team, as well as admins, to understand the usability and value of this new approach.
The good stuff:
Admins were excited about this new workflow and enthusiastically wanted it built, asking “When can we have this?”
Admins appreciated the validation screens presented, and expressed this would take out the guess work out of using Substitutional Queries.
Engineers saw greater potential in high-quality results for populated content.
The admins loved the quality of life improvements on the UI, and really liked the color-coded selection previews.
Other feedback and findings:
Engineers and admins ended up being uncertain about the use of Exclude rules, and thought about reverting that setting.
Engineers needed to investigate deeper into edge-cases and potential errors that could come up while applying Substitutional Queries on potentially conflicting content.
Admins were unsure of how they would replace the hundreds of existing manual Queries, and realized it would take time to adopt the new workflow.
Engineering intake design
The designs that were set as the foundation had [Exclude Rules] removed due to additional complexity and unclear user value. The engineering team’s plan was to start with Show, Episode, and Genre entities in a beta testing environment. Then, as additional scope and requirements were discovered, the project would evolve and so would the workflow.
During this time, the admins were briefed on these future workflow changes, along with new Query naming conventions, to ensure they were ready to adopt the feature when it was fully fleshed out and ready for use.
