B2B SaaS · Design Enablement
One designer was supporting seven engineers, a PM, and three data scientists. Every feature either queued for design review or got built without it, and the ones built without it needed rework. There was no budget to hire more designers, so I replaced the queue with a DRI-owned checkpoint process, plus a set of design principles and Claude skills that let engineers run well-understood, "solved problem" features end-to-end themselves.
Three large-scale features have since been built end-to-end by engineers with no design bottleneck, freeing my time for the harder, less-defined problems that still need direct design attention.
Ocula's squad ran with one designer supporting seven engineers, a product manager, and three data scientists. There was no budget to change that ratio. Every feature that touched the UI either waited on the designer's attention or, increasingly, got built without it.
With one designer against seven engineers, design couldn't sit as a checkpoint on every feature. There wasn't the capacity. Two things happened as a result. Features that waited for design review queued behind everything else already on the designer's plate. Features that couldn't wait got built by engineers directly, with no design input, and came out inconsistent with the rest of the platform, closer to a fix applied after the fact than a feature done right the first time.
Neither path worked. The queue was slow. Going around it produced work that had to be redone.
The instinct when design is a bottleneck is to add more design review, tighter gates, more checkpoints. Given the ratio, that would have made the queue worse, not better.
The actual fix was recognising that most of what engineers were building were solved problems, patterns the platform had already answered in some form, and that engineers needed a designer's judgment made available to them directly, on demand, rather than queued behind a review.
Design's job wasn't to review every screen. It was to give engineers the judgment to build it right themselves, and sign off only at the decisions that mattered.
The head of engineering suggested we try product engineering, the approach popularised by companies like Linear and PostHog, where engineers take on more of the product and design work themselves. That gave the fix a name and some precedent, but not a method. Defining that method became the strategy.
I started from the delivery process itself: extending design thinking past where it usually stops, so it covered build and monitoring as real stages rather than treating the work as done once a solution shipped. From that extended process, I identified the points that needed a stage gate, a fixed moment for product, design, and engineering to review together and make a real go or no-go call, rather than design reviewing everything on its own separate timeline.
That became four checkpoints, each convened by a DRI (directly responsible individual) who pulls in whichever of product, design, and engineering the decision actually needs. The first three are ad hoc. The fourth is a standing Wednesday slot for the go or no-go call.
To get engineers to Checkpoint 2 without me, I wrote a set of design principles, things like "understand the root cause, not the reported symptom" and "hide the complexity, only show what's needed to make a decision". I also mapped a Double Diamond process onto our design thinking stages (Discover, Define, Ideate, Prototype, Test, Build, Monitor), with Claude skills hanging off the key points in that pipeline.
Discovery skill. Pulls together everything relevant from Notion, Slack, Linear, and the codebase itself, including which personas and user journeys a problem touches.
Explore skill. Works through the problem with the engineer using how-might-we prompts, then maps candidate solutions into a pre-built, agent-focused user journey service map for review.
Sketch skill. Pulls interaction and component patterns from references like Mobbin, Shapeof.ai, Aiverse.design, and Dribbble, and sketches multiple options in Figma or paper.design for the engineer to react to.
Together, the checkpoints gave engineers a light, predictable structure to move through, and the skills gave them the judgment to fill it in themselves for the problems that didn't need a designer's direct hand.
Three large-scale features have been built end-to-end by engineers under this process. In design terms, these were solved problems the platform had already answered in some form. None needed to be reworked for consistency, which had been the recurring cost of engineer-built UI before the process existed.
Features built through this process land consistent with the rest of the platform, because the principles and skills carry Ocula's design patterns into engineer-led work instead of leaving it to guesswork.
Three large-scale features shipped without a designer as the bottleneck, with none needing rework after the fact. That also freed time for the "wicked problem" features that still need direct product and design attention.
Design doesn't scale by adding more designers to a queue. It scales by turning solved problem judgment into a process engineers can run themselves, freeing the designer's own time for the wicked problems that still need it.