Editorial Promo Builder

Framing the Opportunity

Our editorial and sales teams shared a strategic need to promote to our users: editorial promoted important content while sales promoted brand partnerships.

At the time, our editorial promo efforts included designing and serving through third-party vendors. Each brand had its own vendor leading to inefficiencies and inconsistencies in the capabilities, design, selling, implementation, and distribution of promos.

We saw an opportunity to improve the entire process by creating the in-house ability to design, build, and deploy promos on our own sites.

Background & Context

Before getting into the design process and solutions, I’d like to share some background and context that heavily influence the design thinking.

Leaf Group, Its Brands, and Their Teams

Leaf Group owns and operates several media properties, or brands, including Hunker, Livestrong, Sapling, and more. Each brand has a dedicated editorial team, while sharing centralized sales, product, and engineering teams.

Some brands have higher budgets allowing for fully featured editorial teams including managers, in-house writers, and dedicated content designers; while brands with lower budgets are limited to an editorial manager, freelance writers, and lack dedicated content design personnel.

As shown above, the level of resourcing that a team has impacted who the primary user would be for each property:

1. In-House Content Designers - Is a skilled and trained designer who manages the brand style guide and branding strategy. These users are exceptionally well-equipped to design effective, brand appropriate promos.
2. ‍Freelance Content Designers - Is a skilled and trained designer who has access to the existing brand style guide, but may not have same influence or investment as an In-House Content Designer. These users are moderately-equipped to design effective, brand appropriate promos.
3. ‍Editorial Manager from a Minimally Resourced Team - Not a skilled or trained designer. This user will use the pop-builder as there is no design resource and will need help to create effective, brand appropriate promos.

Technology and Admin (Our Internal Site Management Tool)

The properties share a codebase and component system. Additionally, each brand has it’s own profile and database within our in-house CMS, Content Lab, and within our in-house site management tool, ADMIN.

ADMIN manages programmable parts of a property's website, like the navigation bar links and behavior, homepage content scheduling, brand partnership management, and as part of this case study - editorial promos.

Resulting Considerations

Given the info above, here are some important things I kept in mind:

1. This feature would be available to all properties as part of Admin.
2. Some properties would have the luxury of a skilled content designer in charge of promo creation, while other brands would lean on non-design personnel to create them.

Design Goal

With the info above in mind, I set for the following: create a promo builder that allows our team to design, build, and deploy promotional promos on our own sites via ADMIN. The feature should balance flexibility for properties with skilled designers with appropriate guardrails for properties without skilled designers.

How I Approached the Task

The feature would require two pages or views:

1. Require a CRUD table page to manage the brand’s database of promos
2. Require a Builder page in which users would be able to design the promos, place copy, and retrieve serve code

I based the initial wires for the builder view on content creation and design software like Figma, Pages, Keynote, and Sketch - a preview panel on the left and settings/editing tools on the right.

Even though this was a desktop-only feature, space was at a premium given that ADMIN's top nav and left rail are fixed/persistent. Some early decisions include:

1. breaking up the preview into separate "Mobile & Tablet" and "Desktop" tabs
2. vertical scroll in the Settings panel to accommodate a growing list of options

The product manager and I did a quick review of the initial drafts and the feedback came down to adding some fields for tracking codes and snippets.

I tested the workflow on our in-house content designers and editorial managers. Tasks included users creating a brand new promo instance, modifying copy, adding a graphic, toggling between device previews, and deleting their test promos. The tests went smoothly and feedback was positive, so there was only minor iteration needed.

Solution

Here's a simplified (happy path) diagram of the workflow:

I'd like to highlight a couple of the UX decisions in the builder page.

Settings Panel

The settings panel was long even in the MVP and we knew we'd likely add more sections to it in the future.

So as part of the MVP we made the panel scrollable with the height of the panel being determined by the user's viewport. We wanted to add expand/collapse controls per section, but opted to move that functionality to a V2.

Color Themes

I want to bring up our design goal of balancing flexibility with guardrails as this was especially important when it came to color. We toyed with the idea of a comprehensive collection of HEX fields corresponding to all text elements, icons, and the background, absolute freedom.

However, there were 3 major issues with this approach:

1. we could only realistically rely on the trained Content Designers to wield that freedom skillfully - they knew how to design with adherence to AA color contrast compliance and could swiftly create color combinations that were brand appropriate
2. not only would it be unrealistic to expect the same from the Editorial Manager user group, but it would also be simply unfair as this was not in their job description or general skillset
3. this approach would be slow, prone to error, and tedious for all user groups

I chose to pitch a new concept for ADMIN called "Color Themes" - it'd be a collection of preset themes hand-designed by either dedicated content designers or myself if a content designer was not available. These color themes would become part of each property's ADMIN profile meaning they'd be surfaced not just in the promo builder, but in future features with color selection components.

In short:

1. All brands get a default set of AA-compliant neutral UI themes provided by either the brand’s dedicated content design resource (if available) or myself if there was none.
2. Brands with content designers had an additional set of brand-compliant color themes.

Get Script Modal

‍We were originally going to opt for a minimal interaction in which the user clicked a "Copy Script" button, had the script saved to their clipboard, and was served a small toast: "Copied!". We decided to expand this interaction for a couple of reasons:

1. We wanted to clearly communicate the existence of any unsaved changes that were not reflected in the script.
2. We wanted to surface the date the script was generated.

The modal design shook out to the following:

In addition to the builder itself, I designed the promo template that the consumer actually saw. I created documentation for users of the builder that included items like the graphic guidelines:

Here are some of the promos the Hunker team created and deployed using our tool:

Dev Notes

The for the builder included the builder view layout, the MVP settings states, and the preview states.

Post-Launch & Wish List

We launched the feature and were happy with the various promos that our editorial teams produced.

Establishing promo UX consistency across brands helped our company in 2 ways:

1. It standardized the design and streamlined the creation process among the company’s various properties.
2. It streamlined sponsorship selling for Sales Team and facilitated cross-selling efforts.

There are 2 items on my V2 wishlist:

Drafts - I would've loved to include draft states as part of the MVP, but Admin infrastructure wasn’t quite ready for it. The product manager had plans to prioritize drafts for several Admin features later down the roadmap.

Versioning - lower priority than drafts in my book, but I’d love to give users access to version history.