Removing the design bottleneck from transactional email

01 · Problem

Every transactional email was a one-off

The business need was simple: ship transactional email faster, on-brand, without designers as the bottleneck. The system was the only way there.

At LinkSquares, every transactional email was a one-off designer ask. Password resets, invitations, receipts, status updates. Each one pulled a designer in, and each designer interpreted the brand a little differently. The result wasn't bad design. It was inconsistent design, which is its own kind of brand damage.

• [LinkSquares] [Action Required] Your status changed from Active to Pending
• [LinkSquares] You've been invited to join the team
• Here's your weekly events update
• Password Reset Request

And it scaled badly. Every new transactional surface meant another designer ticket. Engineering couldn't ship an email on their own without breaking the brand, and they didn't want to. Designers were the gating function for a class of work that should never have needed design review in the first place.

02 · Decision

A code-first system, designed to pair with LLMs

Most design systems live in Figma. But every transactional email at LinkSquares already passed through engineering, so a Figma source of truth would mean someone (usually a designer) translating into code every time. That recreates the bottleneck I was trying to remove.

Code-first flipped the model. If components lived where engineering already shipped, designers came out of the critical path by default. The system was built in three layers: foundations, components, templates. It was also structured so an engineer or PM could paste the style guide into an LLM like Claude, describe the email they needed, and get back something on-brand by default. The LLM became the generation layer the system was designed to be used with.

Designers extend the system when something new is needed. Everyone else composes from it.

03 · Argument

The architecture call I had to defend

My manager pushed back on the architecture. He wanted the system to live in Figma, because he worried that if it lived in code, no one outside engineering would be able to edit it.

I argued the opposite. The problem we were solving was precisely because the brand and the components only lived in Figma. Designers gatekept. Engineers couldn't access the source of truth. The brand drifted at every handoff. Putting the system in Figma would solve nothing.

The second piece of the argument was timing. AI coding assistants like Cursor had just made code accessible to anyone who could write a prompt. The "only engineers can edit code" objection had stopped being real. I made the case that the architecture should be built for where teams were heading, not where they had been.

The system shipped in code. About a year later, the company rolled out Cursor accounts to every designer at LinkSquares. The architecture had been waiting for them.

04 · Adoption

How teams used it

In practice, the handoff that used to require a designer stopped requiring one.

• Engineering composed transactional emails directly from the components, without designer review.
• Product managers paired the style guide with an LLM when they needed new copy and shipped the result.
• My design manager (the one who wanted it in Figma) used the system in code.
• Designers extended the foundations when something new was needed, instead of shipping one-offs. My manager added a table component when an analytics email needed one, and that pattern became available to everyone else next time.

The handoff loop collapsed from a two-day designer ask to something an engineer or PM could do in a few minutes: paste the style guide into Claude, describe the email, get back an on-brand composition. The system stayed alive without me at the center of it. Designers extended the foundations only when net-new patterns were needed; the LLM handled the long tail.

Impact

What this delivered

• →Engineering and PMs could ship a new transactional email without a design ticket.
• →Brand consistency shifted from "depends who designed it" to "the system enforces it."
• →The tone-and-voice guidelines became a reference for transactional copy beyond just email.
• →Designers were taken out of the critical path for transactional email, freeing the team to focus on net-new product surfaces.
• →The architecture decision (code-first over Figma-first) became the team's reference for future systems work.

05 · Reflection

What this is, in the end

By the time the system was running, my involvement in any given email had dropped to nothing. An engineer or PM wrote the prompt. The LLM composed the result from the system. The brand held. That was the design.

The work doesn't show up as a beautiful single artifact. It shows up as the absence of friction across every team that ships email at the company.

What I'd push further

The system isn't finished. Engineering can still write off-system emails if they want to, and a few did. I'd occasionally find a one-off wonky subject line and have to point the engineer back to the styleguide. The pattern scales well within the existing transactional categories, but it's not yet a multiplier for net-new ones.

With another quarter, I'd build an actual generator UI on top of the system, with guardrails that flag when a requested email is too far off the existing patterns and route it to a designer, plus a way for non-designers to add new templates through the tool itself. The system is currently a multiplier for existing patterns. The next horizon is making it a multiplier for new ones.