From handoff to a system a team could run

The full story: a handoff, and the decision it turned on

How it reached me

The project started as a template redesign to match the brand refresh, with a wish list of new layout options and functionality on top. A contract designer the Foundation had brought on laid the groundwork, both the new design and an early build in Adestra. When his contract wrapped, it was handed to me.

At that point, it needed someone who could carry all three at once: the design, the front-end build, and Adestra itself, which I'd been working in for years. That combination is the whole reason it landed with me.

Picking up the build

With the build in my hands, I reworked the Adestra setup, closed the gaps between the build and the design, added the remaining options, and pulled everything into one integrated template on a clear model: pick a background, then a block, then an element.

The platform fought back

The hard part was never the blocks. It was the platform. Adestra does let you mix and match blocks, but within fairly limited options. We wanted more range than that: enough flexibility for a non-specialist team to compose real, varied emails on their own. Adestra fought me the whole way as we pushed it past its comfortable set of options. Every option we added made the email composition menu longer and more tedious to navigate, and getting it all to work correctly bloated the template a little. So the job wasn't just building blocks. It was making them compose reliably, and stay usable, in a tool that wasn't built to stretch this far.

The architecture was the real fork

How granular to make the blocks was the decision the whole system turned on. I could have decided it alone. I deliberately didn't, and worked it through with the Foundation's creative director, so the people who would live with it owned the tradeoff with me. We landed firmly on the restrictive side: locked, purpose-built blocks that keep a non-specialist team on-brand by default, with a small set of generic full-width primitives (image, text, button, headings) for the layouts that needed to stay open.

Built for the system's life

I set up version control for safe rollback, published the Figma component library in the Foundation's own account so future designers build from shared components, tied a block-library guide to those live components, and replaced scattered feedback with a structured intake form that quickly earned its place by catching issues that would have slipped through chat.

Training the teams

Rolling this out meant getting several different teams inside the Foundation comfortable building with the system, not just handing over a file. I organized and planned the sessions, and I ran them: walking each team through the block library and training them on the template itself, so the people who would use it day to day could build confidently on their own. A PM coordinated logistics; I led the sessions. Enablement was the deliverable here, not an afterthought, because a template only holds if the people using it know how it is meant to work.

Outcome

The system shipped: governable, documented, built on a clear model, with a team trained to run it. The win was getting there, taking an in-progress rebuild and turning it into one coherent template.

It ran about six months before the Foundation moved to Salesforce Marketing Cloud. Email code doesn't carry between platforms, so the system didn't move with them. The value was shipping it clean and leaving the team a documented system they could run without me.