Denis Kharchenko — Lead Product Designer
Small UI changes were getting stuck in the same workflow as much larger engineering work. Copy changes, spacing fixes, component replacements and inconsistencies in AI-generated interfaces would become tickets, wait for developer capacity and sometimes remain unresolved.
The implementation itself was often simple. The expensive part was everything around it. I started exploring whether we could shorten that path without removing engineering from the process.
Feedback was coming from Product, Customer Success and Sales and making its way into the product backlog. Some requests were substantial product work. Others were much smaller:
The existing workflow treated all of them in roughly the same way:
Designer identifies issue → creates ticket → developer picks it up → implements → designer reviews
That made sense for changes that required engineering work. For a small UI correction, the coordination could be more expensive than the change itself.
I looked through roughly three months of recent feedback with Claude to understand how often this type of issue was appearing and what kinds of changes were being reported. The pattern was consistent enough to question the workflow itself.
The question shifted from how to process these tickets faster to whether every small UI change needed to enter the engineering queue in the first place.
I didn't want to create a parallel system where designers could change production without engineering involvement. The useful middle ground was to give designers more implementation capability while keeping the existing engineering controls around the codebase. The model became:
Designer → AI-assisted implementation → separate branch → PR → Design Review + Code Review → Merge
The designer could take a UI problem further than a Figma file, but the resulting code still had to pass through the same review process as other frontend changes.
This became the foundation for Designer Mode.
Designer Mode sits between the design decision and the existing frontend workflow. It brings together parts of the system that already existed:
Frontend codebase + Storybook + Design Patterns + AI
The AI agent could work against the actual frontend rather than producing an isolated prototype. A designer could ask it to make a small change, such as:
The important part was that the agent wasn't operating without context. It had access to the same components and implementation patterns that the product was already using.
That distinction mattered. I didn't want designers to create another version of the product somewhere else and then hand it to engineering. I wanted designers to work closer to the real implementation.
Access to the code wasn't enough. If the agent could see the components but didn't understand how they were supposed to be used, it could still produce technically valid interfaces that were inconsistent with the product.
So I added a pattern-based layer containing reusable rules and decisions. For example, a pattern could describe a constraint such as:
The patterns gave the agent another layer of context:
What exists in the codebase\n→ How those things are normally used\n→ What the designer is trying to change
That turned the system from a frontend code generator into a way of making changes within an existing product language.
This also changed how I thought about a design system. It wasn't only a collection of components for designers to pick from. Some of its value could live as constraints and implementation guidance for the systems building the interface.
The biggest constraint was simple:
"Designer Mode could not become a shortcut around engineering."
Designers worked in a separate frontend environment and branch. When a change was ready, it became a normal pull request.
Engineering could inspect the implementation, change it, reject it or merge it. Design could review whether the resulting interface solved the original problem. The workflow was therefore:
This was the part I cared about most. Engineering responsibility stayed with engineering. The goal was to move some implementation work closer to the person making the design decision, while keeping the technical and product safeguards around it.
Designer Mode changed the role of the designer for a specific category of work. Before, the designer could identify a problem and specify the solution, but implementation depended on another person picking up the ticket. With Designer Mode, the designer could take some smaller UI changes through to a working implementation and then submit them through the normal engineering workflow.
That created a different relationship between design and engineering:
The difference was the space between those two responsibilities.
Designers using AI to write code is becoming ordinary. The more interesting question was where to put that capability inside an existing product organisation.
A small UI change doesn't necessarily need the same workflow as a new product capability. Once the implementation barrier becomes lower, the organisational boundary around the work becomes more important:
For me, that is where Design Engineering becomes more interesting than simply writing frontend code. It can change the distance between a design decision and the thing that ships.
More case studies and notes: denisxko.com · full text of everything: /llms-full.txt
© Denis Kharchenko. All rights reserved.