The AI-Powered Delivery Model
Driving cultural transformation from multi-tool review queues to designers owning the repository, with delivery roughly ten times faster.
- Contribution
- UX design, front end code, migration lead
- Team
- 2 designers, 3 engineers on the migration
- Product area
- Workflow automation
- Scope
- The component set moved from React to Lit
- Delivery
- 4 months, design to committed code, web
- Outcome
- Shipped, roughly ten times faster delivery
Context
From mock to meeting to build to review
A change used to go from mock to meeting to build to review and back again. I led the React to Lit component migration and started shipping the front end myself: design, code, QA, commit, review, with AI writing the first pass. Delivery came out roughly ten times faster.
The problem
Every handoff demanded a meeting
Historically, shipping a feature was a meticulous but burdensome process defined by friction and serial handoffs. Engineers translated design specifications into code, followed by a quality check where designers captured UI discrepancies as screenshots and logged tickets in the tracking system. Engineers then reviewed the notes, implemented amendments, and routed the work back for re-evaluation.
Every transition demanded a handoff, and every handoff demanded a meeting.
This friction was drastically amplified when the organisation committed to migrating our product suite from React to Lit across hundreds of screens. Under our existing workflow, maintaining visual and functional consistency meant capturing hundreds of individual screenshots. Every screen would then be routed through the traditional review loop. The result was unsustainable.
We were spending more time handing work back and forth than we spent building.
The case I made to engineering
Recognising an opportunity to fundamentally change how we operated, I proposed a shift toward true cross-functional partnership with engineering. Instead of policing changes through a bottleneck of screenshots and tickets, we bridged the gap directly in the shared repository. That allowed me to push UI and styling updates straight to the source, bringing ideas to life collaboratively and in real time, without the administrative drag of traditional handoffs.
The round trip
Four tools to change twelve pixels
A single spacing fix travelled four tools before it changed anything. It was raised in the work item tracker, argued in the design file, chased in chat, and finally made in a repository I had no way to reach.
None of the steps were difficult. The cost was the switching: every move meant another interface, another thread, and another wait for someone else to pick the work up.
Showing the change before writing it
Throughout the migration I built HTML pages showing a visual representation of the code change I was about to make. They gave me clarity on what I was changing and what it would look like. They also became a standard for sharing work with engineering. Pushing changes straight to the code will not be available on every project. Future work may start from designs rather than corrections, or run without the bandwidth or the permission for a designer inside the repository. A visual page is the compromise, carrying an end to end design or a before and after.
Show the whole pageShow less
Show the whole pageShow less
Show the whole pageShow less
The brief
The brief was engineering. I read it as an invitation
The assigned brief was engineering. Move the component set to Lit without the product changing under the people using it, and give design enough of a seat to keep the screens honest. The one formal design assignment was small: I built the entry points into the new interface as clickable demos.
The brief gave design a seat at the migration. I read it as an invitation rather than a boundary. If design was going to be close enough to keep the screens honest, it was close enough to fix them. That meant changing how the work moved between us, not just checking it at the end.
User personas
The four people the old loop ran between
Four people this had to work for. Only the first is a customer. The other three are who the old loop ran between.
Someone building a workflow
Mid-project, real deadlines- Need
- The product to stay the same while we rebuild it underneath.
- Constraint
- If we miss a visual change, they are the ones who find it.
The engineers on the migration
Shipping every month- Need
- Time to migrate, not another round of pixel comments.
- Constraint
- Every design review took a day off the rebuild.
The design team
More screens than one person- Need
- To change their own screens without waiting in someone else’s queue.
- Constraint
- Almost nobody on the team had ever opened the repo.
The directors waiting on delivery
Product and engineering leadership- Need
- Feature dates that hold, and a process they can see.
- Constraint
- The loop’s cost never showed up as a line on a plan.
What I designed
Moving the fix to the person who spotted it
Solution 1 of 4
One shared set of parts
- Problem
- The old interface had been redrawn by hand so many times that the same mistake lived in a dozen places. Every review found it again.
- Design decision
- I led the migration around one shared component set. We assembled screens from parts instead of redrawing them. I fixed the part, and every screen that used it updated.
- Result
- One fix corrected every screen that used the part. The codebase was also clean enough that a designer could work in it, with the tools we needed.
Solution 2 of 4
The designer owns the branch
- Problem
- I could describe a correction in one sentence. It still went through a screenshot, a queue, someone else’s hands and my approval before anyone saw it live.
- Design decision
- I took my own branch in the engineering repo and did the whole pass: design the change, build it, check it, commit it, and put it up for review the way an engineer would. That took skills I did not have yet, so I learned the engineering environment from the inside: shared repositories, branches, merging, pulling and pushing. Structural work I still wrote up and handed over.
- Result
- Design, QA, fixes, commits and reviews used to take five people’s calendars. Most days they took one afternoon. Understanding how engineering actually works is what let me keep that pace without cutting across anyone else’s work.
Solution 3 of 4
AI to write the first pass
- Problem
- If I wrote every line myself, I would become the new queue. I needed help, and I still needed to stand behind every change I shipped.
- Design decision
- The shared component set made the codebase easy for AI tools to follow. I described the design I wanted and reviewed what they wrote. Before anything went in, I built a small page putting the current screen next to the proposed one.
- Result
- I turned a design decision into reviewed code in hours. The check also caught me: I picked a softer red that matched my file and failed accessibility.
Solution 4 of 4
A practice other designers can pick up
- Problem
- If this only works when I am comfortable in the code, it dies when I move on.
- Design decision
- I built guardrails for every stage: logging an issue, implementing the UI, and pushing the update to the repository. In practice that is a review checklist, a write-up template, and one place that shows what is fixed, handed over or waiting on a decision.
- Result
- I was the first on my team to work this way, one of about three in the company. Other people picked it up and the model still held.
How the work was set up
The rules for a designer in the repository, written once as a skill
Working inside the engineering repository only helps if the way I work in it is predictable. So the process went into a skill: a short file the AI assistant reads before it touches anything, holding the rules engineering and I had agreed. Which branch to start from, how small a change has to be, and when to stop and ask rather than resolve something on its own. Less about automation than about a shared standard. Engineering knew the shape of what would arrive, and the designers who came after me started from the same file instead of from a conversation.
- name
- repo-workflow
- description
- Set up a branch in the product repository and walk through the pull request workflow. Use when starting a new piece of design work, or when moving a prototype into the product code.
Core rule
One component, or one feature, is one pull request. Never batch a whole audit or a multi-feature change into a single branch.
Show the stepsHide the steps
1Pull the latest base branch
Before touching anything, pull the current base branch.
Start fresh every time. Never build on top of stale code.
3Create a personal branch
[your-name]-[story-number]/short-description
Keep the description tight. One component, or one concern, per branch.
Confirm the branch name before running this.
4Open the pull request promptly
Same day, or the next one. The longer a branch sits, the further the base moves and the messier the conflicts become.
5Rebase before submitting
Do not break functionality in either branch. If the rebase surfaces a conflict or a change in behaviour, stop and ask before resolving it.
6Tag for review
Small pull request, fast review, less chance of colliding with another designer's work.
User flows
The loop before, and what replaced it
Delivery, as it was Designer, engineering, stakeholders
- Mock handed to engineering
- Built as understood
- Review meeting
- Drift filed as screenshots
- Reinterpreted and fixed
- Reviewed again, approved
- Rollout
Delivery now Designer, in the repo
- Design decision
- Built on my branch, with AI
- Checked before and after
- Engineering code review
- Shipped
Where it landed
Ten times faster, and what stayed slow
Feature and design delivery came out roughly ten times faster. Most of the old steps existed to move work between people. With one person doing the pass, those steps and the meetings around them went away.
The loop stayed for the work that needed it. Structural changes still went to engineering as a write-up. Everything I shipped still passed their code review. What I dropped was the round trip on a one-sentence visual fix.
What this project changed
For years, finishing a design meant writing a document about somebody else’s implementation. This project moved the ownership. The designer now owns the UI and the front end code, so the fix and the reason for it sit with the same person. Engineering got back the time the old loop spent on visual corrections.
Directors saw the delivery numbers. The recognition was for a process other teams could use. Every feature that ships anywhere in the company used to pay for that loop once, and the company ships a lot of features. I wanted other designers to be able to work this way without me.