How one of our designers used AI to build a throwaway tool that shows every contrast failure across a set of themes at once, and why I asked them to ship the fix end to end.
Two years ago, one of our designers said in our team meeting this week, they would have recreated every theme in Figma by hand. The ticket was about color contrast in the website builder clinicians use to make a site for their practice. It offers a set of themes, each with its own photos, backgrounds, patterns, buttons and text colors, and the job was to find which combinations didn’t meet contrast guidelines and fix them without making every theme look the same. The old way meant rebuilding all of it in design files, running a contrast plugin pair by pair and adjusting values one at a time.
They tried a chat model first, pasting in the ticket to see how the palettes worked and where they failed. It helped, and it was still hard to parse. So they gave an AI coding tool 3 inputs: the accessibility ticket, the product’s code and a live demo site as a visual reference. The first build had the right parts and looked wrong, and adding the demo site fixed the look.
What came back is a stand-in for the website builder that shows every photo, background, pattern, color and button hover state, with a theme switcher at the top. Every pair it checks carries a pass or fail label, and a side panel shows the details. It checks 2 standards at once: WCAG, the guideline the law points to, and APCA, a newer method based on how people actually perceive contrast, which isn’t a legal standard yet. Checking both means a fix that passes one doesn’t make things worse on the other. It suggests fixes too, like darkening a gray or lightening a background, and the designer still tunes those by hand, because plenty of the suggestions pass and don’t look as pretty. When they’re done, one button copies every changed value across every theme as JSON, ready to drop into a ticket or a pull request.
It took a couple of days, on the side. My first reaction was that they’d casually recreated Figma, which is hilarious and pretty accurate.
One of our design managers put a finer point on what made it different: the AI is working as an intermediary tool for exploring, building a view of the problem that neither our design files nor our code could give the designer on their own, in place of generating more screens.
The AI is working as an intermediary tool for exploring, building a view of the problem that neither our design files nor our code could give the designer.
In the same meeting, another designer showed a small library that puts live sliders on any style or motion value in the running product, so you can move a slider and see what a value does. They compared it to Dreamweaver, if you’re old enough to remember it. Both are instruments for seeing, built for one problem, and I’d love more designers to reach for one when a problem is too spread out to see in a single file. Another of our design leaders took a similar path on a link-styling fix, which I wrote about in Debating The Code. In both cases the tool that made the work possible was small and disposable, and what shipped was a set of changes an engineer could review.
The part I pushed on was what comes next. The website builder isn’t at the top of anyone’s roadmap, and that’s why I’d like this fix to go all the way through to production, with some help from marketing to let clinicians know when it does. It’s a fun experiment in shipping something end to end, and a good example of how we can focus on things we care about that maybe aren’t prioritized and still make an impact for our clinicians. The designer will open the pull request themselves, with their engineering partner reviewing it. My one ask was to make sure their partners know it’s coming before it lands, so nobody is surprised by a change on a product they own.