Poe

The gap between design and engineering is usually framed as a communication problem. Hand-offs, specs, feedback loops. Fix those and the gap closes.

At Poe, the problem ran deeper. The root cause was a skill gap. Better hand-offs don't fix that.

Quora's designers were product-focused. They could design and some could build. Designing a feature and building a design system are different skills. A feature can be good on its own. A design system has to keep working six months later, when someone else is extending it in ways you didn't anticipate. That expertise didn't exist on the team. Every feature built without it made the next one harder to get right.

Making the case for design system investment before the problem is fully visible is hard. You don't know what you don't know at zero-to-one. Hiring a full-time design engineer before the product had proven itself was a hard sell. The path of least resistance was a contractor. Someone with design systems expertise and a frontend development background who could get the foundation in place without a long-term headcount commitment.

We started where it made sense to start. Semantic tokens for spacing, color, and typography, flowing consistently from Figma into code. Straightforward work, the kind that feels small and pays off later. That part went well.

Building out components and driving adoption was a different story. Without a single dedicated owner, implementation drifted quickly. Design would ship a spec. Engineers would build something close, but not quite. Polish got cut because it was too hard to get right, or too time-consuming for engineers whose strengths were elsewhere. Frontend work that takes an experienced design engineer an hour could take a backend-leaning engineer half a day. And it's not interesting work for them. It shows.

Adoption was inconsistent, and the gap between what was designed and what shipped kept growing. Partially successful, which against what we needed was a failure.

The contractor engagement clarified what we actually needed. Not someone who could set up tokens and move on, but a dedicated owner who could tell what good looked like and then go build it.

That person is rare. We found one.

He started by refining the token system the contractor had established, going deeper rather than starting over. The original tokens were semantically sound but lacked purpose at a product level. He split surface colors from foreground colors, and named tokens after how the product actually used them instead of what they rendered.

At the same time, he was working out why component adoption kept drifting even when the specs were clear. The answer was in the code. Too much flexbox. Too much custom layout CSS written feature by feature, page by page, with each team solving the same layout problem slightly differently. In some cases the components did not support the use cases the product had grown into. The design system had a fragmented structure.

Part of the fix was Tailwind. Color and spacing already had a system. Layout didn't, so every team invented their own. Tailwind gave them one, wired into the tokens we already had. Without that, new components would get wrapped in custom CSS and drift the same way the old ones had.

He rebuilt the core component library, starting with ones that were most used and had the biggest gap in adoption. Buttons, dialogs, cards, inputs, each with the full range of variations, so teams wouldn't have to work around them. Over twenty core UI components. For one person, that was roughly twelve months of steady work.

Buttons and icons became the most-used components and reached meaningful adoption. A couple of components isn't a solved design system. While the foundation was solidifying in the background, the product in the foreground didn't reflect it.

The design system work was moving in the right direction. But the product itself was at a standstill.

As the codebase grew more complex, velocity had slowed to an excruciating pace. No major features shipped for six to nine months. Engineering was under pressure from a company-wide velocity initiative. The code was accumulating debt faster than anyone could pay it down. Bloated CSS, inconsistent components, maintenance overhead that compounded with every new feature.

Designers were feeling it differently. Our engagement survey made it explicit: they wanted more ownership over craft and quality. They could see what the product should look like. They didn't have the agency to close the gap themselves.

Engineering had a week-long hackathon coming up, a company-wide push on developer velocity that was already planned and scoped.

We pitched it to engineering as additional capacity for a shared goal. Designers helping to migrate components and clean up CSS meant engineers could focus on the work only they could do. The ask: let us be part of this.

Getting a yes meant working through engineering leadership and the security team. More people with codebase access meant higher risk. That had to be addressed directly, setting the right level of permission to access our systems. We also defined what was in scope for designers to touch, established guardrails, and got explicit sign-off before anyone opened an IDE.

By then, the design system was mature enough that we could start using AI to help designers write code against it. Our design engineer built a Claude skill around our components, icons, and tokens, plus a design.md that taught it how the system was supposed to work. The documentation powering all of it was generated automatically as components were updated. The design system and its AI context stayed in sync without manual effort.

The goal was that a designer could describe what they needed in plain language and get back code that already matched our design system.

Training turned out to be the hardest part. Over half of our designers weren't technical. Everything from basic terminal commands, to how git works, to navigating the engineering development process without breaking things was a hurdle. Technical designers and our design engineer ran the sessions. The bar wasn't "become an engineer." It was "know enough to contribute confidently and safely."

The hackathon delivered. Every designer on the team contributed, migrating components and clearing out CSS that engineering had been carrying for months.

Adam, our CEO, recognized the work at the company all-hands. Mobile engineering leaders saw what was happening and started asking questions.

Adam's response made clear this wasn't going to be a one-time event. Designers contributing code directly to the product raised velocity as well as quality.

We formalized it as a Design Quality Initiative. Rather than overcommitting on scope, we ran it as a quarter-long pilot. Enough time to fine-tune the operations before locking anything in permanently.

We had a list of questions and no answers yet. Where does the work come from, and how do we prioritize it? How much time are designers expected to contribute, and what's the difference between work that gets a light review versus a full one? How do we make sure designers feel supported rather than overwhelmed, and that this reads as real ownership, not extra responsibility stacked on top of an already full role?

We structured it around three rhythms. A monthly check-in to review progress, surface larger blockers, and scope new projects entering the initiative. A biweekly check-in to track individual tasks and identify where design engineering support was needed. A weekly education session run by our design engineer, covering new developments, tips and tricks, and design system work that improved quality of life for the team.

Designers knew when they'd get help, how their work would be reviewed, and where to go when something was harder than expected. Before the end of the quarter, the check-ins showed component adoption increased and CSS reduced.