A better way to build, by design

When I mapped how a design actually reached production, the discovery and design phase had five separate standing touchpoints in it: an early engineering alignment call, a product stakeholder review, a design review with our VP of Product, his design sign-off, and a design handoff call to engineering.

Every one of them was reasonable on its own. Together they meant the same work got presented five times to overlapping audiences, feedback arrived in sequence rather than in one room, and no single meeting had everyone in it who could settle a question. Engineering heard about a design before Product had agreed to it. Handoff came after sign-off, so the first time engineers saw implementation detail was also the last time anyone could change it cheaply.

Process arguments go in circles when nobody can point at the cost, so before I proposed anything I went and found it. I put the approved Figma file next to the shipped screen and marked every difference.

On the manual card entry screen: drop shadows that were never in the file, helper text under the security code that nobody had written, padding between fields that didn't match the spec, and a primary button at the wrong size. On the review screen, a single Pay button had become a card, a paragraph of explanatory copy, and a Confirm and Continue button.

None of these are disasters, and that is exactly the problem. Each one is small enough to lose an argument about. Together they are the difference between a product that feels designed and one that feels assembled. Five reviews had produced agreement without producing a decision anyone could build from.

I replaced all five touchpoints with one weekly call and named it Weekly Triad Alignment. The triad is the three functions, not three people: the leads from the product team of teams, the engineering leads, both of us on design, and my manager when she could join. We had never had a standing meeting with all three functions in it.

I run it. I set the agenda every week and I take proposals through it, which is how most of what follows on this page got decided. Its job is to align the three functions on priorities, work in flight and work coming next, and to resolve open questions early enough that they don't turn into reschedules.

I wrote the rules down, because the rules are what keep a standing meeting from decaying into a status report. It is a working session, not a passive readout. Attendance flexes by relevance, and leads forward the invite by agenda topic rather than everyone sitting through everything. You come with a clear ask, question or decision needed. The agenda is the same every week: work in flight and coming next, priority changes, our evolving ways of working, then open questions, risks and blockers.

Collapsing five meetings into one is the whole argument. Sequential approval rounds let each discipline respond to a decision someone else already made. One room makes them respond to each other. It also removed the handoff call, because engineering had been watching the design take shape for weeks by the time it was ready to build. The call has run every week since July 15, 2026.

The weekly call keeps a single piece of work honest. It can't tell you whether Design is working on the right things at all, so I set up a second call on a monthly cadence. Each designer reports what they shipped, what's in flight for them now, and what's up next on their plate. Product and Engineering then confirm that it matches their backlogs.

That one is a smaller room and I run it too: my fellow designer and me, our VP of Product, the Senior Director of Engineering, and my manager when she can join. The weekly call catches a design drifting from its spec. The monthly call catches Design drifting from the roadmap.

A new meeting doesn't fix accountability. So I built a RACI across four roles (Design, Product Management, Product Leadership, Engineering) covering every task in development and QA: who runs the early alignment, who answers an engineer's question about a design decision, who accepts a change made during build, who logs a QA defect, and who signs off before release.

I built it in a working session rather than circulating a document, because a RACI people haven't argued with is a RACI nobody follows. Every task has exactly one accountable owner, and I kept the consulted column deliberately short. Too many consulted parties is how a governance model turns into a bottleneck, which is the failure I was trying to avoid in the first place.

Who carries which row matters more than having the chart. Design is responsible for the design QA audit and engineering is accountable for it, which means Design cannot hold a release. I didn't want a gate that let Design stop a train. A team that can be blocked by Design will route around Design. I wanted the deviation caught and named by the people who could fix it.

The design QA gate is a review before release that checks the build against the Figma file and the behaviour the design specified. It is also a new step in someone else's sprint. I wrote that into the process diagram rather than leaving it to be discovered: engineers add the design QA step to their Jira estimates, so the time is visible in planning instead of arriving as an unbudgeted ask at the end of a release.

I made that trade on purpose. A gate nobody estimated for gets skipped the first time a date gets tight, and naming the cost up front is why the step is still running now that dates have got tight.

The product QA gate already existed and I left it alone. Design QA sits next to it rather than inside it, because folding design checks into an existing product QA pass would have made design quality the responsibility of someone with no design context.

The organization was moving planning into Git at the same time, with specs as the source of truth. I read 29 of them to find where design lived.

Design appeared in most of the specs and was structured in none of them. It turned up in ## Notes / references, the most common home and sometimes a callout at the top of the body instead. It turned up in ## Dependencies, listed with an owner name and a due date. It turned up in ## Risks and open questions, flagged as a risk with a confidence rating. And it turned up in ## Non-functional requirements, as the line “UI/UX design: Required, Figma designs available, see Notes.”

The template was the cause. spec.template.md addressed design only parenthetically, in the final Notes section. Nobody was leaving design out on purpose. There was nowhere structured to put it, so every author invented a place.

Asking 29 authors to remember a convention does not work. Changing the file they all start from does. I proposed two edits to the spec template and put them on the Weekly Triad Alignment agenda for July 15, 2026, the first session of the call.

First, a design status line in the front matter: not started, in progress, or approved and ready for dev. That makes design state queryable from the repo instead of something you have to ask a designer about.

Second, a ## Design section placed between ## User stories / Requirements and ## Acceptance criteria, so design sits where the work gets defined rather than in an appendix.

The deletable clause is what got the section approved, and it was a concession rather than a clever idea. I wanted design declared on every spec. A mandatory section on a backend capability with no UI is a tax, and a template that taxes people stops being used, so I gave up the mandatory version to get the structured one. I also took the old design language out of the Notes section, because leaving two valid homes for the same information guarantees people keep using the old one.

The proposal went to Product as the accountable owner, with me consulted. I wrote the change and PMs owned adopting it, which is the right way round: a template that Design imposes on Product is a template Product works around. roughly three quarters of the specs opened since carry a completed Design section.

The weekly call could settle almost anything except where a piece of work had stopped moving. Engineering and Product tracked work in Jira and Jira Align. Design tracked work in Coda. Nothing joined them, so there was no single view of where any project actually sat.

Two functions gave sincere and incompatible accounts of the same delay. Design would wait weeks on a product review with no way to show the wait, while Design was being described to Engineering as the hold-up. Nobody was being dishonest. Each function could see its own queue and none of us could see anyone else's, so everyone located the bottleneck somewhere other than where they were standing.

So I built the board that would settle it. I pulled from Coda and Jira Align through their MCP servers and REST APIs and joined the records into one view: every active project, week by week, with the stage it is in, how long it has been there, and who it is sitting with.

A blocked-work panel runs down the right side of the board. Each item names who it is waiting on, how many days it has waited, the question that needs answering, how many times someone has chased it, and which system it came from. Each one has a nudge button that sends the owner the open question directly.

The judgment call on this board is the discipline filter. It splits blocked items by function, which puts Design's own count in the open next to Engineering's and Product's. I built it that way on purpose. A bottleneck report that only ever indicts other people is an accusation with a chart attached, and it gets dismissed as one.

Raising a delay costs the person who raises it more than it costs the function that caused it, so delays go unnamed until they are expensive. With the days-waiting count on a shared board, nobody had to accuse anyone. The conversation moved from whose fault it was to which step needed help.

The board has a second job coming. The monthly call reconciles capacity, work in flight and work coming next out loud, and all three are already rows on the board. Running that reconciliation off the board instead of out of a document is the next piece.

I want to name the authority problem plainly, because it is the part of this work that is hardest to see from the outside. I'm a Staff Experience Designer and an individual contributor. The people who had to agree to all of this were our VP of Product, our VP of Engineering and a Senior Director of Engineering. Nobody reported to me and I couldn't require any of it.

The same proposal lands differently depending on which function sends it. Moving review and sign-off authority around is a sensitive thing to put in writing. From Product it would have read as Product taking hold of the schedule. From Engineering it would have read as Engineering pushing back on process. From Design, it was the function with the least positional power in the room proposing a system that constrained Design more than it constrained anyone else.

My VP of Product told me afterward that he was glad the proposal had come from Design, because the same changes wouldn't have been received the same way coming from Product or Engineering. I'd been working from that assumption for months without knowing whether it was true.

A proposal to change who decides is only credible when the function making it takes on a cost of its own. Design picked up the QA audit without the power to hold a release, and Design's blocked count sits on the board next to everyone else's. That is why it was adopted, and it is the part I would build the same way again.