How 100% of our designers shipped production code within one month

When I joined Hinge Health, I wasn't sure how quickly a healthcare technology company would embrace the massive AI shift dominating my social media feeds. What I found was that Hinge Health was already moving beyond the hype, using these tools in practice to not only build but improve the member experience. It wasn't theoretical, it was ingrained in the culture. That was true in engineering, and it was becoming increasingly true in design and product as well.

For our design team, that created a pretty clear challenge: learn fast.

So we did. We set a goal for every designer to ship a pull request (a small production code change through our established review processes) within a month. That goal generated attention at the company and, truthfully, anxiety among a few, but shipping code wasn't actually the point.

As one of our designers noted: "I'll say, when we first set this goal, I wasn't fully confident I could do it. But I'm so glad we did. In a time when the industry is shifting fast, finding ways to upskill while still shipping high-level craft is essential."

The real goal was a tighter feedback loop between design intent, proposed solutions, and what members actually experience. It was also about empowerment, giving designers freedom to improve the product experience directly, with the right guardrails in place, while helping the team build a stronger sense of ownership over quality.

The principles we anchored on

A few key principles allowed us to approach this in a way that felt practical and sustainable.

Start small

Something I learned in my experience was that the best change often happens incrementally. Instead of pushing designers toward full feature development, we focused on UI tweaks, copy changes, small bug fixes, and targeted component updates. The goal was to build confidence and momentum while avoiding overwhelm.

Establish safeguards

Every change went through the established Hinge Health engineering review process, including pull request review, QA, and engineering oversight. This was essential, because if designers were going to participate in implementation, it had to happen at the same quality bar and with the same accountability as the rest of the team.

Prioritize judgment over technical perfection

Applying good design judgment didn't mean code quality didn't matter. But at this stage, our priority was empowering designers to apply their product instincts to improve the experience in tangible ways. We were optimizing for better product outcomes while building new technical muscles over time.

Learn by doing

We didn't want to spend weeks in abstract training before anyone touched the product. We wanted the team to get hands-on quickly, make mistakes in a safe way, and learn through real work. Starting from anywhere was better than waiting for the perfect starting point.

How it worked

First, we set up the guardrails by partnering with engineering to get local development environments working for each designer and simplifying the path to a first PR. It took a few sessions, but once done, it was a game changer. Documented guides, office hours, and 1:1 support made the work feel much more approachable.

From there, we defined "low-risk" work, prioritizing UI bugs, copy tweaks, small interaction fixes, and component improvements. Clearly outlining what designers should not touch kept the scope manageable and let the team build confidence without creating unnecessary risk.

We also leaned heavily on pairing and review. Every PR was reviewed like any other code on the platform. This maintained a consistent quality bar while creating a shared learning environment: designers grew comfortable with implementation, and engineers gained visibility into the details designers protect.

AI became an important bridge, using tools like Claude Code and Figma MCP to translate design intent into implementation more quickly. Whether starting in Figma or directly in Claude Code with a prompt, AI lowered the barrier between idea and execution.

What mattered most was iteration over perfection. We focused on smaller changes, shorter loops, and faster learning. As a result, every designer at Hinge Health successfully shipped a PR by the end of the month.

What changed for the team

What changed after that initial goal was less about "designers learning to code" and more about becoming builders in a practical, low-risk way.

They independently identified and fixed UX/UI issues directly instead of letting them sit in the backlog as lower-priority items. Typos, visual inconsistencies, incorrect design system usage, and small bugs no longer waited for attention. For example, one designer's first merged PR fixed a color-related bug, a major unlock that made future design-bug fixes feel directly within reach. Another updated the video visit flow, replacing a repetitive 'View Profile' text action with a cleaner chevron interaction.

These may sound like small fixes, but that is exactly the point. Designers could now spot problems, make the change, and move the product forward while the context was fresh.

Another designer pointed out: "AI tools have completely changed my day-to-day. The biggest unlock isn't just speed, but parallelization, running multiple AI agents simultaneously across various project stages. This lets me bridge strategy and execution quickly, cuts down on context switching, and frees up my time for high-leverage product decisions."

Just as importantly, designers developed stronger empathy for engineering constraints. By being closer to implementation, they see tradeoffs more clearly and understand where the system is flexible vs. fragile. That understanding improves collaboration in both directions.

The deeper change was in how designers viewed their role. Conversations began framing the future designer as a builder, not just for shipping UI. Designers began driving experimentation, increasing our learning velocity. We've created scoped career paths for designers fully embracing this mindset to work directly as a builder within their pods. At the end of the day, design has stopped being limited to intent and handoff. It's become a more direct lever on quality, speed, and execution.

There was also a positive side effect for the engineering team. Enabling designers to safely ship high-quality production code forced us to solve a wide range of DevEx friction points. These were the kinds of annoying issues that engineers know how to work around, but designers don't. This process also helped build the case for much greater investment in our design system team.

What's next

We've made good progress and the next phase is about empowering designers to get out in front even earlier, pairing their natural design judgment with stronger guardrails to maximize impact. As we scale, we need more consistent code quality, clearer design system alignment, and workflows that keep small contributions maintainable.

To do this, we must treat our design system as foundational infrastructure for both people and AI. While we initially focused on getting designers into code to build engineering empathy, we now want to do the inverse: arming engineers and PMs with a "design harness," and designers and engineers with a "PM harness." Ultimately, every member of our R&D team should be empowered to operate as a full stack builder, while leveraging deep expertise in their primary function.

This shifts the very core of design. We are already seeing designers create high-fidelity working prototypes during and sometimes before the PRD phase. This changes the job, placing a higher value on people who can visualize ideas quickly, test them, and move fluidly between product thinking, design judgment, and implementation reality.

Shipping code was never the destination. The bigger opportunity is a design team that brings ideas to life earlier, closes the gap between intention and reality faster, and raises product quality through direct ownership.