Skip to main content
Webflow 2026 Content Designer

Unifying terminology & UX across interoperable products

  • Audited conflicting terminology across two newly merged products and determined the root cause of confusion
  • Defined a unified terminology system that replaced six overlapping concepts with one clear structure
  • Validated new terminology with users via survey before bringing it to stakeholders
  • Content strategy
  • Information architecture
  • Content design

Problem

In 2024, Webflow acquired Intellimize, an A/B testing platform that would later become Webflow Optimize. The same year, Webflow also introduced Analyze, its native solution for site analytics. Both products let users define and track “goals” — conversion objectives like button clicks, form submissions, etc. — but they had been designed independently.

Bringing them together was a larger interoperability effort that involved closing feature gaps between standalone Optimize (aka Optimize for sites not hosted on Webflow, fka Intellimize) and integrated Optimize (aka Optimize for Webflow-hosted sites), improving the IA connecting Analyze and Optimize, and adding goal reporting where it didn’t yet exist. My work spanned terminology and the overall goals UX.

A working document outlining the goals interoperability initiative's objective and existing terminology issues.
A general outline of the interoperability initiative across Analyze and Optimize.

Key challenges

Terminology that made sense in the context of Intellimize didn’t hold up in the integrated Webflow Optimize product, and Analyze had developed its own separate vocabulary for the same underlying concepts.

Several terms that described a goal’s state or designation (e.g., account goal, primary goal, optimization goal) were treated in the product as distinct types of goals, but none of them actually described what the goal tracked.

Goal

Define unified goals terminology across Analyze and Optimize that accurately reflects how goals are defined and tracked, while remaining familiar to marketers who previously used Intellimize or comparable analytics and A/B testing tools.

Process

Auditing existing terminology

I mapped where every term in use had (or hadn’t) been established across integrated Optimize, standalone Optimize, and Analyze.

A spreadsheet-style audit of every goal-related term in use before this project.
The starting inventory of every goal-related term.

Reframing types vs. designations

I decided that a goal’s type is what it tracks (e.g., clicks, page views, form submissions, custom events) while everything else — its importance, scope, and reusability — is a modifiable state rather than a distinct category. The name for each type needed to work as a plain answer to the question: “What does this goal track?”

If “site goal” is a state rather than a type of goal, the reporting view needed to introduce it without introducing another filter option next to the true goal types. I proposed a separate, pinned section for site goals within the reporting view instead, which let users view their most important goals quickly.

The 'Create new goal' modal had three goal types (i.e., clicks, page views, forms) and a separate link to create a custom goal.
The first step in the goals creation flow, where users choose the type of goal they want to create. Designations don't appear on this screen.

Naming the designations

Rather than reconciling six overlapping categories, I named a single unifying concept (goal), a small set of types, and a small set of designations or states.

Goals proposed terminology showing one goal concept, a set of types, and a small set of designations.
The proposed structure, before individual terms were finalized.

Account goals became site goals to reflect how the Webflow product actually works. Goals are set and tracked at the site level. Optimization goals became temporary goals, an internal-only designation; the product already communicates scope through behavior, so customers didn’t need a dedicated term for it. Primary goals became targets, which clarifies that this is a designation applied to an existing goal, not a type of its own. It also works as a verb (“Target X goal in this optimization”) to reinforce its behavior.

Custom goal and offline conversion goal had opposite problems — “offline conversion” was too specific for what it actually was, and “custom goal” was too broad. I tried renaming custom goal to advanced goal first to reflect the setup required, but “advanced” read as a difficulty level, rather than a type, so I reverted it. Custom goal stayed as an umbrella term instead (“What does this goal track?” → “Custom events”), and on-site and off-site conversion became two paths inside it. The fork in the UI, along with descriptive help text, helped customers find the right setup instructions for each.

The custom goal creation modal offers a choice between On-site conversion and Off-site conversion.
Two goal types with different setup requirements within the custom goals modal.

I cut two legacy terms – “tracking goal,” which was redundant (all goals are tracking goals), and “AutoGoal,” which existed only in Optimize and wasn’t applicable in the interoperable product.

Show the finalized interop terminology
New termPrevious termDefinition
GoalTracking goal (sometimes)A desired action taken by a site visitor
Site goalAccount goalA key objective for a site, tracked site-wide and across optimizations
Temporary goal (internal only)Optimization goalA goal scoped to an active optimization; not reusable, deleted when the optimization is archived
TargetPrimary goalThe designated goal an optimization uses to measure success and declare a winning variation
Click goalA goal that tracks clicks on an element
Page view goalPageView goalA goal that tracks visits to specific pages as conversions
Form goalA goal that tracks successful form submissions
Custom goalA goal that tracks complex events not captured by other types
Off-site conversionOffline conversionA server-side conversion synced from a CRM, matched to the original visit
On-site conversionOffline conversionA client-side conversion captured by code running on the page

Validating the direction

I checked “target” against competitor conventions. Most similar tools use some version of “primary metric,” and in every case, it’s a designation applied to a metric rather than a distinct object, which matched my reasoning.

A competitor research table comparing how five A/B testing and analytics tools name the 'primary metric' concept.
Where 'Target' landed relative to five comparable tools.

I co-designed an unmoderated study with my product design partner, reviewed by the user research team, to validate the proposed terminology before finalizing my recommendation to stakeholders.

Results

The study came back at 100% comprehension across 12 participants. The final proposal resolved the type vs. designation confusion that made the pre-interop model difficult to reason about both internally and externally.

Goal creation modal with a 'Track as site goal' checkbox and help tooltip.
Users could track goals as 'site goals' when creating a new goal.

Reflections & learnings

One difficult call was deciding what to surface to customers vs. keep internal. “Temporary goal,” for example, needed to exist as a concept for the team to build, reason about, and discuss, but surfacing goal lifecycle would have added unnecessary cognitive overhead.