Targetbase
Marketing Platform

At a Glance

A B2B platform that gave marketing operators a 360° view of their customers, role-based BI dashboards, and predictive scoring they could act on. Built on Neolane (now Adobe Campaign). Designed for four operator roles. Configured for multiple enterprise client tenants without fracturing into separate products. Ran in production for five years and anchored most of Targetbase's new business in that window.

My role: Co-led the platform with Targetbase's CTO. I owned UX, IA, and feature definition. He owned engineering and data architecture. We overlapped in the middle, made tradeoffs together, and shipped together.

Team: Led a design pod inside a larger creative organization. Partnered directly with a third-party engineering team and Targetbase's data analysts. Attended all technical reviews.

The Problem

Targetbase's business model depended on running marketing programs on behalf of enterprise clients using their first-party data. Every new client engagement reinvented its own dashboards, reports, and operator tools from scratch. It was expensive, inconsistent, and didn't scale.

The bet was to build one platform that consolidated customer 360, business intelligence, and predictive scoring, and could be configured per client without splintering into five different products under the hood.

The IA Challenge: One Product, Multiple Tenants, Four Roles

The platform served four distinct operator roles. Each role had a different job to do, saw different data, and made different decisions.

On top of that, multiple enterprise clients were live on the platform. Each client had its own first-party data, business rules, brand surface, and operating model. Each client also wanted to feel like the platform was theirs.

That's the trap in multi-tenant design. If you say yes to every client's "we need this to work our way," you end up maintaining multiple products. If you say no to everything, clients leave. The discipline is figuring out where configuration ends and customization begins, and holding the line consistently.

The model we landed on:

• Shared IA, configured surface. The information architecture, the structure of what data lived where, how operators moved between customer view and campaign view, how roles gated access, was the same across every tenant. What changed per client was which features were turned on, which data sources were connected, and how the brand surface presented.
• Role-based, not tenant-based, variation. Differences in what operators saw came from their role, not from which client they worked for. A brand manager at Client A and a brand manager at Client B saw the same shape of experience, with their own data inside it.
• Configuration, not customization, by default. If a client wanted something genuinely new, the question was: does it belong in the product for everyone, or is this a request that should be solved with services rather than software? Most of the time the honest answer was the second one.

Design System and Engineering Partnership

The platform had a design system appropriate to its era: a style guide and a shared component library, with pattern documentation that engineering consumed. It wasn't a tokenized system in the modern sense, those didn't really exist yet, but it was the foundation the platform was built on, and it stayed coherent across five years of feature work.

I worked directly with the engineering team. I attended most technical reviews. I don't write or read code natively, but I sat with engineers in their environment and walked through implementations with them to evaluate the resulting UX. When something didn't match design intent, I could describe the behavior precisely enough that the issue got fixed without translation.

Research

The platform was persona-led. We built personas with input from internal stakeholders who worked with clients daily, then validated key workflows with targeted user research. In hindsight, I'd push for more direct operator research earlier, shadowing marketers and admins in their environment, not just interviewing them.

What I Took From It

• Many of my decisions were about where to flex and where to hold the line. Configuration vs. customization is the question that defined the product's long-term shape.
• Data insight outputs need to live inside the operator's existing workflow, not in their own dashboard. A score that requires a separate review screen is a score that doesn't get used.
• Engineering partnership is a daily practice, not a milestone. Sitting through every technical review, walking through implementation in code, and being precise enough to file issues that don't need translation, that's the work.