Campaign Intelligence System Building Rex Black's in-house content operation
We helped clients run successful growth campaigns. Rex Black had never done it for itself. I built the system to change that — inside our own CRM, from scratch.
ROLE
Founding Designer
TIMELINE
April 2026 - Present
The Problem
We knew how to run growth campaigns. We just weren't doing it for ourselves.
Rex Black has helped clients grow through content for years — LinkedIn, newsletters, articles. We had the playbook. We just never applied it internally. When that became a priority, I took on building the whole system from scratch, inside our own CRM.
My Role
What I designed
A full campaign management system inside our existing CRM — LinkedIn, newsletter, and articles, all in one place.
What I built
Production code using Cursor + Claude + Git. I wrote the prompts, reviewed the output, caught errors, and shipped it.
Key Challenges
Keeping it running without a content team
The whole point of this system was automation — AI handles the drafting, humans handle the judgment. But that raised a harder question: where exactly should AI act on its own, and where should it stop?
I built a system where the AI evaluates its own output after generating. High-confidence drafts surface quietly. Low-confidence ones get flagged. Anything clearly off gets rejected and regenerated automatically. Only the genuinely hard calls reach a human.
Making AI behavior visible and adjustable
Handing content decisions to AI only works if you can see what it's doing. So I designed a Pipeline view with four columns — from L1 (agent drafts, human decides everything) to L4 (agent runs fully autonomous). Each post lives in a column based on how much trust has been established. You can move it. You can pull it back.
Trust becomes something you can see and change, not just feel.
Result
Rex Black now has a content operation that didn't exist before
0 → 1
inbound channel, built inside the existing CRM
3
channels (LinkedIn, newsletter, articles) in one system
~10 min
daily review time vs. 45 min writing from scratch
The bigger thing: because content behavior is tracked inside the CRM, we can eventually connect what someone read to how warm they are as a lead. That's the data advantage of building this natively instead of buying a third-party tool.
The system also validated a way of working — design in prompts, build with AI, own the output — that Rex Black can use for everything it builds next.
The Hardest Problem: When the Technical Constraint Becomes a Design Problem
About midway through the project, we hit a wall.
To support the Salesforce migration, the team had integrated Stripe Elements for payment processing. Stripe's architecture uses secure iframes for its input fields — an intentional security measure that prevents external scripts from accessing sensitive financial data. That's correct behavior. But it created a conflict with our custom UI logic.
Our accordion collapse system — the contextual progressive disclosure pattern described above — used JavaScript event listeners to detect user interaction and trigger section animations. Stripe's secure iframe blocked the event propagation our logic depended on. The animation would trigger incorrectly or not at all. For a moment, it looked like we might have to abandon the entire interaction model.
The decision I made:
I reframed the problem. Instead of treating the Stripe constraint as an obstacle to our design, I started asking: what does Stripe actually need to stay intact, and what can we build around it?
Working daily with the engineering team, we built custom wrapper components around Stripe's secure containers. The payment input fields themselves were untouched — Stripe's security handshake remained completely intact. But the surrounding UI — the section header, the collapse trigger, the visual affordances — was rebuilt to work with the iframe boundary rather than against it.
We also made a deliberate trade-off: we deprioritized custom animation fidelity in favor of checkout stability. If a design choice risked the integrity of the Salesforce–Stripe security layer, we chose the stable path. Every time.
Why this matters beyond the solution itself:
This decision established a working principle for the project: for high-transaction, high-trust products, functional security is the highest form of UX. A broken payment experience is not a UX failure. It's a business failure. A slightly less animated transition that processes payment reliably is worth infinitely more than a beautiful transition that introduces any doubt.
The Result: This trade-off proved that for a high-scale transactional system, functional security is the highest form of UX. By embracing the technical constraint rather than working against it, we maintained a 100% secure checkout without sacrificing the streamlined momentum of the user journey.
Results
The redesigned checkout shipped to 100% of ZO Skin Health's user base in August 2024.
Metric | Outcome |
|---|---|
Revenue increase | +17% |
Support tickets related to checkout | −82% |
Rollout coverage | 100% |
The 17% revenue increase, measured against the post-migration baseline, translated to a recovery — and growth — that brought digital revenue to $50M for the platform. The 82% reduction in support tickets was an unexpected secondary outcome: when users stopped getting confused in the checkout flow, they stopped contacting support about incomplete orders.
What I Learned
Data narrows the problem space. Judgment still closes it.
The analytics told us where users were leaving. They didn't tell us why trust was breaking down, or why the mobile experience felt heavy, or why users were abandoning right at the payment step specifically. Those answers came from sitting with the user journey, reading it as a sequence of emotional states, not just a conversion funnel.
Working with constraints is a design skill.
The Stripe conflict forced me to think about what was actually essential versus what was preference. Custom animations were preference. Payment security was essential. Once I was clear on that hierarchy, the solution became obvious. Constraints often make the design better by forcing that clarity.
