LinkSquares · Design Systems
LinkSquares' transactional emails were built one at a time, drifting further apart with every release and accumulating accessibility gaps in a channel every customer sees. There was no system, so I built one. The goal was not fewer design requests. It was that product and engineering, including with LLM tools, could ship a correct, accessible email without a designer in the loop and without the product coming apart one email at a time.
01 · Problem
Every transactional email at LinkSquares was built one at a time. Password resets, invitations, receipts, status updates. A developer could stand one up on their own, but with no shared system it came out slightly off-brand and quietly skipped accessibility, and the next one looked a little different again. The result wasn't bad design. It was inconsistent design, which is its own kind of brand damage.
This mattered more at LinkSquares than it would at most companies. The platform had no in-app notifications, so email was the only thing pulling legal users back into the product. A status change, an assignment, an approaching deadline: the email was the trigger to return and act. Miss the email and the work didn't happen.
Legal users live in a crowded inbox, skimming for the one thing that needs them. When email is the notification layer, the subject line is the entire interface, and ours actively worked against the skim:
The bigger problem was trust. When the emails didn't clearly look like they came from LinkSquares, security-conscious legal users read them as phishing, because that is exactly what a generic, off-brand email asking you to click a link looks like. The messages meant to pull people into the product were instead making them hesitate, or report the email to IT. For a company selling to legal and security teams, and doing it in the middle of a next-gen relaunch, that is a credibility problem at the surface customers see most.
02 · System audit
Before designing anything, I audited the transactional email we were already sending, so the system was derived from real usage rather than invented. I pulled every live transactional email, grouped them by the job each one did, and looked for the structures that repeated.
The clustering set the component boundaries. A structure became a component when it recurred across categories (a header, a headline, a single primary button, a status box, a footer). A specific arrangement became a template when a whole category kept reusing the same composition (a password reset, an invitation). What repeated across many emails got standardized; what was genuinely one-off per email, like body copy, stayed flexible. That line, standardize the recurring, leave the variable free, is the decision the rest of the system is built on.
03 · Architecture
Because these components ship as HTML email rather than product UI, the rendering and client constraints live in implementation. So I treated the coded library as the authoritative source of truth, the layer the emails are actually built from. Figma stayed useful for exploration and review, but it could not be the only authoritative layer, or implementation would drift into a second, unofficial system. That is the drift that caused the original problem.
The system was built in three layers: foundations, components, and templates. Structuring it this way had a second benefit. Because the rules and components were documented in code, teams could use general-purpose coding assistants such as Claude or Cursor to compose standard emails from approved patterns instead of starting from scratch. That was the AI-assisted workflow that actually shipped; a dedicated generator was not part of it. AI sat on top of the system, constrained by it, rather than being the reason for it.
Designers extend the system when something new is needed. Everyone else composes from it.
04 · Alignment
My manager initially preferred a Figma-first system because it would be more familiar and accessible to designers. I agreed with the accessibility concern, but recommended that the coded library remain authoritative because email rendering behavior and client constraints live in implementation. A Figma system would sit one step away from where the emails actually get built, so developers would still be translating a design into code from memory, which is what caused the drift. This wasn't a claim that design systems belong in code instead of Figma; for product UI I'd want them synchronized. For email, code had to be authoritative so implementation couldn't quietly become a second, drifting system.
I also addressed the real concern that code would lock non-engineers out. AI coding assistants like Cursor had made code approachable to anyone who could write a prompt, so "only engineers can touch code" was already less true than it used to be. A couple of us on the design team were working in Cursor, with an account available to any designer who wanted one, and a Figma MCP layer could later let designers contribute to the same source of truth without pulling it back out of code.
The coded library was the source of truth. An internal documentation site, hosted at a link anyone at the company could open, made the system accessible to product, engineering, and design without moving the authoritative layer out of code.
05 · Adoption & governance
In practice, the handoff that used to require a designer stopped requiring one.
In the examples I observed, a standard email that previously required a design request and handoff could be composed in minutes from existing patterns. Just as important, the system kept running without me at its center: my role moved from producing every email to defining the standards and handling the exceptions.
A system only stays consistent if there's a shared understanding of how it changes. In practice, requests followed a lightweight, mostly-informal model with four paths depending on how far a request sat from what already existed:
06 · Accessibility
Most developers aren't thinking about accessibility when they build an email. That's not a knock, it just isn't top of mind under a deadline. Our next-gen product solved the same problem by building on Material Design, so accessibility came baked into the components. I took the same approach for email: rather than relying on every contributor to remember the same requirements, I incorporated accessible defaults into the approved tokens, components, and content guidance. This reduced the chance of common omissions, although the full system was not formally audited for compliance.
The requirements I documented in the system included:
The choices that make email work for users with disabilities make it work better for almost everyone:
Impact
The system was a bet on a specific change, not just a tidier set of files. Before building it, I defined what "better" had to mean, so the architecture call could be defended on outcomes rather than preference.
Standard emails became easier for product and engineering to compose from approved patterns, reducing recurring design work and opportunities for brand drift. This also extended the next-generation product identity into the notification layer that brought legal users back into the application.
I did not measure a direct effect on retention or renewals. The observed business outcome was greater team self-service and a more consistent customer experience across a high-frequency product touchpoint. Accessibility fit the same scope: because requirements were built into the approved components, the accessible version was the default one, which matters for a product sold to legal and security teams that may review it.
07 · Reflection
By the time the system was running, I no longer needed to touch a standard email. An engineer or PM wrote the prompt, the LLM composed the result from the system, and the brand held. My involvement moved to defining the standards and handling the genuinely new patterns. 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.
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. (I've since built an interactive concept for that generator on this site.)
I'd also hook the system up to a Figma MCP server so designers who aren't comfortable in Cursor could contribute from Figma instead. The code stays the source of truth; contributing just gets easier. The system is currently a multiplier for existing patterns. The next horizon is making it a multiplier for new ones.