Enabling AI prototyping
Built an AI-ready design system and no-code prototyping workflow for Brightseed Bio.
- Client
- Brightseed Bio
- Role
- Design Lead
- Status
- Shipped
- Year
- 2026
01
The challenge
Brightseed, a Series A startup, had a strong proof of concept in Hummingbird, an AI discovery platform for scientists. It let them research and source molecular compounds for new product development in food manufacturing. Powered by years of proprietary data, they successfully defined the product's core value and had customers eager for more features. Still, the product was amorphous, with the data model and features evolving rapidly. The team needed a way to iterate quickly, using AI for speed, without creating an untenable system to maintain. They knew the usability could and should be improved, but they needed outside help to adopt best practices.
02
Brand refresh
A design system is only as solid as the foundation under it, so I started with the brand. Brightseed already had a strong logo and a clear point of view; they wanted to read more like a modern tech company, lighter and brighter. Getting color and logo right first matters, because everything else is built on them, and a wrong color system is expensive to unwind later. I internalized their brand values (organic, pioneering, vibrant, intentional, scientific), explored five concepts, and scored each against those values. One cleared every bar: a mid-green direction, light and airy. I narrowed it to two structured options, cream accents leaning scientific and green accents leaning vibrant, and the team chose green.
03
Foundations
I started the design system from shadcn and built a three-tier structure of semantic tokens, primitives, and components. Components were documented and named for AI tools to consume, making generation predictable and on-brand.
04
AI-assisted icons
I went to art school, so drawing the icons wasn't the hard part. Catching where one would break later was. Refining Brightseed's hummingbird and the rest of the set, I used AI to study options against the reference and to dial in stroke weight (the 1.2 and 1.5 studies here). It also caught what I'd have missed: the eye has to be a stroke with rounded caps and zero length, not a filled shape, or it won't recolor with the icon, and it would have broken the first time someone changed the theme. A small rule, and exactly the kind AI holds well, the kind that quietly wrecks a system months later when a human misses it.
05
Component inventory
With the foundations set, I inventoried the components the product actually needed: navigation, the chat tray, a few card types, detail pages, filter interactions. Badges were the first win. The shadcn defaults weren't enough for an information-dense product, so I used Figma Console MCP to generate a flexible set, dozens of variants with the production work done for me. I carried that into the buttons, adding states the defaults missed (like a heavier button for marketing contexts), and held the set consistent across light and dark mode so nothing broke as the system grew.
06
Designing for iteration
Working with startups I've learned to design patterns that help teams iterate faster. Two examples here were the action overflow menu on cards, and the instance switcher. Neither were must-haves, but they enable speed.
07
Storybook as the source of truth
Used Storybook to host the design system (component library, token system, and layout patterns) as the shared source of truth, so when AI generates a screen it assembles from pieces that already exist, are already on-brand, and are already built for responsiveness and accessibility.
08
Mocking layer
Hummingbird's data model was still moving, and designing against a live backend would have slowed everything down. So I had the prototypes run on a mocking layer built with Mock Service Worker (MSW). A service worker in the browser intercepts each API request, matches it against a set of mocks, and hands back a realistic response, so screens render with believable data and no real server behind them. The design system and new flows can be built, demoed, and pressure-tested against true-to-life content while the real backend is still in flux.
09
New workflow
The old process was a workaround. Brightseed's product team are scientists and domain experts, not engineers, so they specified interfaces in twenty-plus-page markdown documents and hoped the result matched. The new workflow closes that gap. The same domain experts describe what they want to their preferred LLM, and because it draws from real design-system artifacts, the output stays consistent: components match, styling matches, and the code comes back front-end-ready by default. New habits emerged on their own, too. Early on, Claude needed the object model explained before it could do useful work, and answering that produced clean diagrams of the model, documentation I never planned to make and could never have made by hand that quickly.
10
Improved user flows
While not planned as part of the scope of this work, as part of the component clean up I did improve several user flows, like the initial launch point of the product.
11
Results
The scientists building the UI could deliver at a higher quality bar, faster, without the cognitive load of styling. Early-stage products used to earn forgiveness for rough edges. They don't anymore, whatever their size or funding, so we laid the foundations for Brightseed to ship polished UI from day one and maintain it as they grow.