How do we achieve quality at scale?
I have spent the past ten years working as a design engineer, mostly on design systems at companies like IBM, Shopify, Intuit, Netflix and now Ramp. Design systems made common decisions cheaper. They gave teams shared components, workflows, and patterns so people did not have to remake the same choices over and over.
When design systems first became common, people were hesitant. Designers wondered if they would still get to design. Engineers wondered if systems would take away the parts of front end work they liked. That sounds a lot like the way the industry talks about AI tooling today.
But design systems did not take all the work away. There is still a lot of judgment required, especially as products evolve. AI tooling works the same way. Implementation is getting cheaper. Judgment is not.
That means our job is still to encode design judgment clearly, but now we need to do it for a new kind of user: agents. It is no longer enough to keep Figma and code in parity. We need coherence across tools like Shadcn, Tailwind, Ryu (our design system) and whatever else agents may use. Agents need shared decisions too. They need to understand our components, patterns, language, and constraints.
Supporting every stage
We have been thinking about AI tooling across the full builder journey:
- Before implementation
- Give people enough context to solve the right problem.
- Help them work with agency.
- Make sure they understand the tools available to them.
- During implementation
- Provide paved foundations.
- Help people start from the right place.
- Make building faster without lowering the quality bar.
- After and around implementation
- Critique the work.
- Learn from tool usage.
- Feed those learnings back into our systems.
Having resources is not enough. People still need to understand how to use them.
Two places to work with agents
At Ramp, we have two big internal tools: Inspect, which is tailored for builders contributing to production code in Ramp repositories, and Glass, our internal knowledge worker.
But designers sometimes need to work locally. They want to work with real code, real components, and real data. That lets them simulate the end user experience and see edge cases in real time.
For many designers, this is also about empowerment. Some designers may not have had the technical proficiency to make these changes before. AI tooling gives them a way in. The Field Guide gives designers the guides and resources they need to use AI well. It covers things like:
- How to use Ramp, Inspect, Claude, and Cursor as a development partner
- How to craft better prompts
- How to set up a local development environment
Dev onboarding for designers is now self-serve. Designers can get set up with a custom script. What used to take days can now happen in a couple of hours. Once designers have that context and setup, the next step is giving them paved paths for building.
Dojo: Shared skills + reusable workflows
Dojo is Ramp’s internal library of reusable skills. People can browse and install Dojo skills in their personal dev environments.
I wanted a place where people could go deeper on design-specific skills, so I built Design Dojo. It includes:
- Individual skills that can be invoked for specific jobs.
- A channel people can subscribe to for skill updates.
- An agent that can work across an end-to-end design pipeline.
The skills cover different parts of the design process, including research, exploration, copywriting, and brand design critique. There are also tooling-specific skills like one called /paper that allows agents to more easily build with our design system in Paper.
The goal is simple: give people more context so they can use these tools with confidence.
Each skill page gives people more than a description. It can show what the skill does, how it works, what people can get from it, when to use it, related skills, example scenarios, and the system prompt and reference files behind it.
Sakura: Start from Ramp
Sakura helps designers spin up a React environment using React and Vite. It is not just a generic environment. It has Ramp design context baked in, including:
- Design skills
- The design agent
- Design MCP servers for agentation and Figma
- Ryu, our design system
Sakura is meant to be a harness or workbench for design work. Designers can use it from Inspect, Glass, or the terminal. They can say "Sakura" in Inspect or Glass, and the agent can use the Sakura skill to spin up a React app. They can also run sakura new in the terminal to start an interactive prototype flow.
The paved start matters. But a paved path does not automatically mean the output will meet the quality bar. That is where critique comes in.
Building criteria for design quality
We have been working on a robust set of criteria to assess design quality. So far, we have collected around 200 criteria. That needs pruning, but the breadth is intentional. The criteria span five lenses:
- Product reasoning
- User experience
- Design system
- Accessibility
- Copy
We also distinguish between two types of criteria:
- Blocking: The work should not ship until this is fixed. Example: using brand green where constructive color should be used.
- Advisory: The agent can flag it, but a human should make the final call. Examples include spacing, rhythm, grouping, or subjective copy guidance like “clever, not campy” and “confident, not arrogant.”
The goal is not to surface 200 criteria every time someone builds something. The goal is to surface the right context at the right moment. That might look like:
- Concept review: pressure test the problem and the workflow before anyone commits to a direction.
- Implementation polish: catch design system, typography, and interaction issues while the work is still in motion.
- Pre-ship gate: run a broad check before merge so the builder ships with confidence.
Design Crit variants
I have also been working on a design crit skill to make this more concrete. There are four ways into the skill: a general "Grill Me" mode and three phase-specific modes tied to the builder journey. Each mode includes example prompts and expected outputs.
Because Design Crit can apply to many contexts and stages, we have been testing it across lots of scenarios. Some examples include:
- Poke holes
- Repeated hierarchy
- Intensity critique
- Browser-based gate before merging
- Pre-ship gate before merging a drawer
Depending on fidelity, the output could include an HTML report that shows how the design performs across the five lenses and what to do next.
We are also grounding the criteria in our documentation. If someone gets a blocking issue, they should be able to see where it came from, such as a component page or design system documentation. That helps people understand the quality bar instead of treating it like an arbitrary agent opinion.
Can we build taste?
A lot of our design system foundation is strong. But there are still gaps. Some of those gaps are not about components. They are about taste: the non-codified patterns and design decisions that our organization values. So the question becomes: how do we use AI to build taste?
I was inspired by our engineer Mary's work showing different AI-generated landing page experiences. That led to an idea called This or That, an app that shows designers two different designs and lets them:
- View each design full page
- Vote on which one works better
- See another design that is similar to the one they chose
- Continue comparing until they find a winning direction
Once someone finds a winner, they can see:
- The AI's intent for the design
- What the team is seeing
- Whether the team is choosing similar directions
- The mocks they previously reviewed
The goal is not a popularity contest. The goal is to create a structured way for designers to talk about quality. Why did one direction feel better? What did we value? Are we aligned?
The next step is annotation. Designers would be able to click directly on the design and note what stands out. They could tag what works, what needs work, and what they noticed across multiple designs.
All of that feedback would be saved to a database. Over time, we could look at the aggregate signal and use it to have better conversations about taste.
Learning from repeated tool use
Proprietary tooling is helpful, especially when we can store structured data from tools like This or That. But a lot of our work happens in Inspect and Glass. Once a skill or tool is released, the context can disappear. It becomes hard to see how people are actually using it.
That is why we need evaluation layers. The goal is to learn from repeated use. We want to identify patterns from Inspect session evidence, then turn those patterns into proposals for improving our skills and resources.
A human would review the proposal. If they agree that it identifies a real gap, they could approve it and publish the improvement to Dojo.
UXR Monitor: visibility into tool usage
UXR Monitor is meant to be a dashboard for understanding how people use these resources. It helps us see:
- When people use the agent.
- When people use a skill.
- When people use both together.
- Who is using which resources.
- How Inspect sessions relate to UXR.
The goal is visibility. We want to understand usage patterns so we can keep improving the system.
Copy Council: turning feedback into guidance
Copy Council is a more robust version of this idea. Copy is subjective and hard. Even when we prompt carefully and evaluate scenarios, important feedback can still happen in sessions or Slack and then get lost.
Copy Council is meant to collect those signals and turn them into better guidance. It could collect different sessions and show:
- A session summary
- The initial prompt
- The final agent response
- What changed across iterations
- Confidence in the summary
- A link back to inspect the session
Those session summaries and iteration patterns would inform recommendations from the agent. For example, the agent might propose guidance like "repeat confirmation" or "state success." The proposal includes the guidance, an example, and linked session summaries.
Once guidance is approved, it can be marked as ready for Dojo and shipped in a pull request. If something needs more conversation, it can move into a discussion flow with reasoning and a Slack channel.
Approved and rejected decisions would go into a decision log, creating a change log for how the skill evolves over time.
Designers are becoming builders
The most exciting part of all this work is not just what it does for the systems team. It is what it enables designers to do. Designers are starting to build in ways we did not imagine before. They can play with code, create tools, and shape their own workflows.
Jason Li is a great example. He created his own style of agentation feature with commenting, along with a custom sprite sheet for his agent pixel. That kind of work shows what becomes possible when designers have the right tooling ecosystem around them.
The future of design at Ramp
The question is no longer: can we build it? The question is: does it meet the bar?
We are still solving the same problem design systems have always tried to solve: making quality scale. But AI changes the speed of the work. That means our systems, critique, and taste-building practices need to keep up.
My hope is that designers continue to lead this change, both in how the industry thinks about design and in how we work with internal tools at Ramp.