Marketing Automation Platform

Overview

Apteco builds marketing analytics and campaign management software used by mid-market and enterprise clients in retail, travel, and financial services. The automation module — which allowed marketers to build multi-channel campaign journeys — was the product’s most powerful feature and its biggest source of churn.

The workflow had been built over several years by engineering teams responding to feature requests. It had grown into something that was technically capable but practically unusable for new users. Experienced users had built workarounds. New users were leaving.

My task was to redesign the automation workflow from the ground up while maintaining backwards compatibility with existing customer configurations.

Business Context

Apteco was competing with established marketing automation platforms — HubSpot, Salesforce Marketing Cloud, Marketo — that had invested heavily in user experience. The product had strong analytical capability, but in sales conversations, the UX was consistently raised as a concern.

Churn analysis showed that customers who failed to build a working automation in their first 30 days had a significantly higher churn rate at 90 days. Fixing the automation UX was a retention problem, not just a usability problem.

Problem

The existing automation builder had two structural problems:

Complexity without clarity: The builder exposed every possible configuration option at every point in the flow. Users were confronted with decisions they didn’t understand at stages they weren’t ready for them. There was no concept of “just getting started” — every campaign started at maximum complexity.

No mental model alignment: The builder was built around Apteco’s internal data model, not the way marketers think about campaigns. Marketers think in audiences, messages, and timing. The builder was built around data selectors, broadcast types, and execution parameters.

Constraints

• Backwards compatibility was non-negotiable. Existing automations had to work without modification after the redesign
• The engineering team was small and committed to other product work. The UX had to be achievable within 4 engineering sprints
• Apteco’s component library was limited. I had budget to add new components but needed to justify each addition
• Several enterprise customers had trained their teams on the existing workflow. A complete redesign required a migration plan and customer communication

Research

I ran a research programme over 6 weeks:

• 8 contextual observation sessions with marketers using the existing tool, in-situ at client offices
• 18 interviews with customers across 3 segments: power users, occasional users, and churned users
• Analysis of Intercom and Zendesk support tickets related to the automation module (3 months of data)
• Competitive analysis of HubSpot, Braze, and Klaviyo campaign builders

From observation sessions: Power users had developed a set of pre-built “template” automations they duplicated and modified. They were working around the tool’s complexity rather than using it as designed. Occasional users were frequently stuck at specific decision points — particularly around timing configuration and audience selection.

From support tickets: The three most common support topics were: (1) why a campaign had not sent, (2) how to add a condition to a journey branch, and (3) how to duplicate an existing campaign.

All three mapped to fundamental usability failures, not training gaps.

Insights

Insight 1: Template-first is the right mental model for new users. Almost no marketer starts an automation from scratch. They have a campaign type in mind — welcome series, re-engagement, cart abandonment — and they want to start from that structure.

Insight 2: Progressive disclosure was missing at every level. The tool exposed all configuration options immediately. A step-by-step approach, revealing complexity only when needed, would reduce the initial cognitive load without limiting capability.

Insight 3: Visual feedback was almost absent. After setting up a journey branch or adding a condition, there was minimal feedback that confirmed the configuration had worked. Users were unsure whether their actions had been registered.

Product Thinking

My most significant product contribution was arguing for a template library as the primary entry point. This was not in scope when I joined the project. The PM’s plan was to redesign the existing canvas-based builder.

My argument: a redesigned canvas would be less confusing, but it would still require users to know what they were building before they started. The research showed that most new users came to the tool with a campaign outcome in mind, not a data configuration problem to solve. Starting from templates would let them begin with a working structure and learn the tool through modification, not through blank-canvas construction.

The PM agreed to a reduced version: a template library that launched the builder pre-configured, rather than a full guided experience. This was achievable in the existing engineering budget and had the same effect for new users.

Key Decisions

Decision: Visual campaign canvas over form-based configuration. The existing tool used a form-based configuration panel for all campaign steps. Testing showed this was the primary source of disorientation — users couldn’t see the campaign as a whole.

We moved to a visual canvas where each campaign step was a draggable node. Users could see the full campaign structure and click into individual nodes to configure them. This aligned with how marketers drew campaigns on whiteboards.

Decision: Separate “what happens” from “when it happens.” One of the most common points of confusion was the combined timing and trigger configuration. We separated these into two distinct steps, each with its own vocabulary and default states.

Decision: Ship with 8 templates, not 30. There was internal pressure to launch with a comprehensive template library. I argued for 8 well-documented, well-tested templates rather than 30 mediocre ones. Users needed confidence that templates would work. Quantity without quality would erode that confidence quickly.

Design Process

I started with a low-fidelity canvas prototype to test the structural concept — visual nodes versus form-based configuration. This was validated quickly: every participant in the first test session preferred the canvas.

The majority of design effort went into three areas:

1. Node design: The visual representation of campaign steps had to be scannable at the canvas level and configurable at the detail level. I went through 11 iterations of the node component.
2. Condition builder: The logic for branching conditions (send message A if X, send message B if not X) was the most complex part of the tool. I designed a structured, sentence-based condition builder that avoided the raw logic expression syntax used previously.
3. Validation and error states: Users needed to know when a campaign was incomplete or incorrectly configured before they tried to activate it. I mapped every possible error state and designed a pre-activation validation summary.

Validation

I ran three rounds of moderated usability testing across 18 participants (6 per round):

• Round 1: Identified that node labels were insufficient — users couldn’t tell the difference between an Email node and an SMS node at a glance. Added channel icons. Also identified that the condition builder’s “Add condition” button was too far from the node it modified.
• Round 2: The template library was well received, but 4 of 6 participants wanted to preview a template before selecting it. Added a preview modal.
• Round 3: Validated the full flow. 5 of 6 participants completed the primary task (build a 3-step welcome series using a template and modify one branch condition) without assistance.

Final Solution

The redesigned automation builder has three layers:

Template library: 8 campaign templates covering the most common automation types. Each template launches the builder pre-configured with example nodes, placeholder audiences, and default timing. Users can use the template as-is or modify any element.

Visual canvas builder: A drag-and-drop canvas where campaign steps are displayed as connected nodes. Each node shows its type, configuration summary, and status. Clicking a node opens a configuration panel without leaving the canvas.

Pre-activation validation: Before any campaign is activated, a validation summary checks all required fields, flags configuration issues, and shows a campaign summary (audience size estimate, message count, estimated send schedule).

Collaboration

The relationship with engineering was constructive but required careful management. The engineering team had built the original tool and had strong views about which parts of the existing architecture could be changed. I spent time in the first two weeks understanding the constraints from their perspective rather than arriving with a finished design.

The most productive sessions were joint design-engineering workshops where we explored what was technically feasible before committing to design directions. This caught three features early that would have required architectural changes I hadn’t accounted for.

The condition builder was the most contested feature. Engineering preferred a rule-based syntax similar to the existing tool. I had research evidence that this was the biggest source of confusion. We ran a 2-day design sprint to explore alternatives and test them with users. The structured sentence format I’d designed performed significantly better. Engineering built it.

Outcomes

Three months after launch:

• Campaign build time reduced from an average of 4 hours to under 45 minutes
• 90-day retention among new users improved by 28%
• Support ticket volume for the automation module fell by 67%
• Usability score (System Usability Scale) improved from 51 to 76

Three enterprise customers who had been flagged as churn risk renewed their contracts after the redesign.

Failure and Risk

The migration path for existing customers was more disruptive than I anticipated. Customers with heavily customised automations needed to re-validate their configurations in the new interface. We underestimated the number of configurations that used non-standard combinations.

The customer success team absorbed a significant amount of one-on-one migration support. In retrospect, I should have built a migration validator tool that customers could run themselves before the cutover.

The template library was also too limited at launch. The 8 templates covered the most common use cases but missed several vertical-specific patterns. We shipped 12 additional templates in the following quarter.

Reflection

This project taught me more about the relationship between product positioning and UX than any other. The original tool was positioned as a powerful, flexible platform. “Power” and “flexibility” had become excuses for complexity. Rethinking the entry point — template-first rather than blank-canvas — was a product decision as much as a UX decision.

I also learned the value of making a clear case for scope changes with evidence. The template library wasn’t in scope. Without the research data showing that new users were leaving because they didn’t know where to start, the PM would have had no reason to accept the scope change.