Consistent Builder Initiative

One of the areas I lead design efforts for at ActiveCampaign is our landing page builder, Pages. While powerful, this tool offers a vastly different experience than other builders in the platform, both in functionality and UI. In April of 2021, recognizing these shortcomings, I created two new layout options that would better organize existing functionality; provide a solid foundation for new features; and align with our design system, Camp. I then tested these two layouts using Maze, the results of which can be seen here.

Around this time, I also started noticing how these disparate experiences contributed to declining NPS scores and detracting user feedback. Consider the following quote, which speaks to unnecessary cognitive load and decreased efficiency:

“The first time I attempted to build a landing page, there was a bit of a learning curve since the builder is different from the designer for Campaigns.”

-Anonymous Maze participant and ActiveCampaign user

The screenshots below illustrate exactly what this user describes: four different builders with four different experiences. It became clear that we needed to prioritize a solution for these variances.

These observations prompted an idea: given the broad variance in ActiveCampaign’s builder experiences, what if we created a library of builder components that would be transferrable across the platform?

Introducing the Consistent Builder Initiative (CBI), a yearlong effort that audited existing builders, produced 45 new components and documented those components for our Camp engineers. While I led this initiative, I also worked with an incredible team of designers who represented other builders and our design system. This project wouldn’t have been nearly as successful without their support and collaboration.

Continue below to learn more about this initiative.

Step 1: Audit Existing Builders

To determine whether the CBI was worthwhile, we began by auditing existing builders to gauge what functionality was unique, versus what could be reused in another area. The greater the overlap in functionality, the more apparent the need for reusable components became. Our audit spanned four builder experiences (Automations, Campaigns [our email builder], Forms, and Pages) and identified over 50 pieces of functionality required in two or more builders.

Step 2: Create Figma Components

To prevent this initiative from stalling, our team adhered to a weekly cadence that addressed one audited item per week. The schedule went as follows:

• Monday: Our team would meet for 90 minutes to address the next item in our audit. Each designer would review their assigned builder and identify critical functionality, then collaborate on an initial design that accommodated each experience.

• Tuesday–Wednesday: This design would then be “componentized” in Figma and allow for variants and multiple use cases.

• Thursday: Designers would meet for 30–60 minutes to review the component(s) and make necessary iterations.

• Friday–Sunday: Component(s) would then be documented in Figma. See more about this documentation below.

Step 3: Document The Components

While component documentation varied in complexity, we tended to follow a similar structure. First, we introduced the component and showed it in the context of a builder. Multiple mockups were included if we needed to show various styles. We’d then dissect the component and detail its anatomy, showing additional states or interactions as needed.

Components often had two parts: sidebar functionality and canvas functionality. Sidebar functionality allows users to determine how a given object (i.e. countdown timer, image, video, etc.) will appear on the canvas. The countdown timer below is a perfect example. Not only did we have to account for the various styles and interactions on the canvas, but we needed to determine how that object would be manipulated from the sidebar. As such, a section was often included to define sidebar content and structure.

Lastly, we’d redline each part of the component(s) using Camp tokens, simplifying the handoff process between our team and design system engineers. See below for a dissected document detailing the countdown timer.