I've spent the past ten years as a design engineer at IBM, Shopify, Intuit, Netflix, and now Ramp. At every company, we've faced the same question: how do we achieve design quality at scale?
AI is widening the gap between how quickly engineering can ship and how much design can support.
When our ability to build outpaces our ability to assess the result, we risk scaling quality problems just as quickly.
Raising the design floor
Design systems have helped us address quality at scale for years through shared components, workflows, and judgment. But I vividly remember the hesitation when they were first introduced: would designers still get to design? Would engineers lose the frontend work they enjoyed? We're hearing similar concerns about AI today.
What we found was that a good design system freed builders to focus on complex problems. It also gave them foundations to extend when an existing solution didn't fit, helping the product and the system evolve together.
I believe that we’ll reach a similar point with AI tooling where leveraging AI in the design process can help any builder independently ship an experience that looks, feels, and sounds like Ramp. At Ramp, we call that the “design floor”, the foundation for Ramp experiences, typically primarily been supported and enforced by the design system.
For that floor to hold as more people build with AI, agents become a third user of the system, alongside designers and engineers. The goal is to give them enough guidance on components, patterns, language, and constraints to get most of the way to our quality bar. Humans can then focus on refining the experience and deciding where to go deeper.
Supporting both means expanding beyond Figma, code, and documentation. We need tools that help people and agents make good decisions throughout the work: context before building, guidance and critique during it, checks before shipping, and learning after release.
A peek at our internal design tools
I've been working on several connected parts of a connected design system that go beyond components. Each addresses a different gap between having design guidance and being able to put it into practice.
Shared design skills
A design system contains a lot of judgment, but an agent needs help applying it to a particular job. Framing a problem, exploring a direction, writing copy, and reviewing an implementation all need different context.
We've been packaging that guidance as skills in our Design Dojo, our shared library of reusable agent skills. The goal is to make our design knowledge available where builders work, whether that's Claude Code, Cursor, or Inspect. A skill can bring in the relevant references, guide the work, and make the expected output clearer.
Builders can visit the Design Dojo site to understand those capabilities. A name and a short description don't always tell someone when to use a skill or what to expect. The pages explain how each skill works, show scenarios, and expose the prompt and reference files behind it. A design agent can then draw on those individual capabilities across a broader workflow.
This is not only another way of distributing shared decisions, but for the design system to distribute shared workflows and resources.
We're making the guidance easier for both people and agents to find and apply.
Field Guide
Having those resources available doesn't mean everyone is ready to use them. Some designers are new to working in code. They need to understand how we build before they can confidently work with an agent.
That was the original purpose of the Field Guide, a resource I created to help people use AI as a development partner. It covers the tools available at Ramp, how to craft useful prompts, and how to get a local development environment running.
This was released in late February. By summer, it was mostly being used for developer onboarding, which I still see as a big win. Designers could follow a self-serve guide and run a custom setup script. If something went wrong, they could work with Claude to understand the error and get through it.
This is part of making the design system accessible. We need to give people enough context to work with agency, including people who haven't used these environments before.
Sakura
Once someone can work in code, they need a useful starting point. Sakura provides a React workbench with Ryu, our design system, and Ramp design context available from the start.
Designers can explore with real components and try the interactions an end user would experience. They can change content, see edge cases, and give other people something concrete to react to.
In the talk, I showed how builders could start through the Sakura skill in Inspect or Glass, or use the CLI from their terminal. These are different paths into the same foundation, depending on where someone is comfortable working.
From a Design Systems perspective, Sakura puts the system into an environment where people can experiment with it. It gives them a place to work through a product question while using the components and guidance we already maintain.
Copy Check
Copy Check started as a Figma plugin to help designers review interface copy. But Figma was too limiting. Designers, PMs, and engineers all contribute to copy, and that work happens across many tools and conversations.
We’ve since focused on a shared set of copy criteria. Those criteria live in our design system as guidance and in skills that agents can use to draft, edit, and critique copy. A Slack agent makes that support easier to access wherever someone’s work starts.
The skills give us more flexibility, and Slack gives more people a familiar place to ask for help. We’re using the dashboard to understand where that help falls short, so we can keep improving the criteria, skills, and agent.
Design Crit
Design Crit has been our most challenging endeavor.
We’ve compiled hundreds of criteria across five lenses: product reasoning, user experience, design-system use, accessibility, and copy. Copy alone has 118 criteria, with violations of 94 classified as critical. We’re tackling each lens one by one.
The challenge is giving an agent the right context for the stage of work. Questions about the problem and proposed workflow belong early in the process. Raising them for the first time in a PR creates noise when someone is trying to ship.
The same applies to fidelity. Designers iterating quickly aren’t always aiming for pixel-perfect work or a one-to-one match with the system. A thorough check of design-system adherence, down to individual code choices, belongs at handoff. Earlier feedback should help them explore and refine the experience.
We’re working through what useful critique looks like at each checkpoint: concept review, implementation polish, and handoff or pre-ship review. We’re also using internal tools to explore how that guidance can reach builders beyond skills:
- Review Buddy reviews the lines of code that changed. It can flag missing states, inconsistent patterns, accessibility issues, and potential design regressions before they ship.
- Testo tests the product hands-on. It opens the product, clicks through a specific scenario like a user would, and reports whether the experience works and looks right.
The work now is figuring out which criteria belong in each workflow, what evidence an agent needs, and when a finding should block progress or simply inform a decision.
Ryu-ify plugin
Ryu-ify is an experimental Figma plugin that helps designers bring captured product UI back into the system. It takes an editable capture and creates a new frame using Ryu components, text styles, and color tokens, flagging anything that still needs review. The goal is to spend less time rebuilding what already exists and more time improving the experience.
What this enables at Ramp
The part I'm most excited about is seeing designers build in ways we hadn't imagined.
In the talk, I shared an example from Jason Li: he'd built his own commenting interaction and a custom sprite sheet for his agent pixel. He was shaping tooling around the way he wanted to work.
Alongside self-serve developer onboarding, that's a concrete sign of what these foundations make possible. Designers can try interactions, build tools of their own, and bring something real into a conversation with engineering or product.
The broader goal is for more builders to feel confident making design decisions: make a sound first pass, understand where it falls short, and know when to bring someone else in. That gives designers more room for focused craft and helps product teams decide where to go deeper.
A system that keeps learning
As more people build, we have more opportunities to learn. Evals help us test how our guidance performs across scenarios. Real sessions show us where people get stuck, correct an agent, or need something the system doesn't yet provide. We're exploring ways to bring that learning back into the system with quantitative and qualitative evals.
For example, our design systems engineer Frank Albenesius created tests that ask agents to build interfaces with different component APIs and guidance, then check the rendered results. Reviewing where agents struggled helped improve both the component and its documentation, including guidance on wrapping, truncation, and when to use its layout components.
As the models and our product evolve, we need to keep asking: how often are ideas reaching shippable quality? Where is significant rework still needed? What should our tools and guidance do differently?
I want designers to help lead that evolution, both through the experiences we create and the systems we give other people to build with.