Using AI to build UX Tools
My work at Shopify is not yet released and currently confidential. Until I can speak freely about it, this post outlines its underlying UX thinking.
See also
The most surprising thing I did at work this year? I built nearly a dozen Figma plugins, Chrome extensions, and other tools. I built all of these with AI IDEs like Cursor. They’ve completely changed my approach to work. Things like:
A design system linter that finds icons with missing descriptions or keywords, has AI look at them(!), has AI generate keywords and descriptions that match, and checks the changes into the codebase. Each of those steps would have taken a designer hours to do; this script within a Figma plugin can be run in five minutes.
A search query intent classifier. Given a set of queries from our production logs, it annotates each to a particular classification and gives a human-readable rationale for its decision. All of these get visualized in a simple web page – click on a classification and you can read the rationale!
A Chrome extension to collect user feedback on bad search results. Internal folks were eager to help us improve search quality by pointing out bad results in our slack channel, but this didn’t scale. So now everyone gets a browser extension and they can do it right then and there. Best part is we trade searching slack history for a simple database that can get plugged into other infra.
A Figma plugin that creates search result page mocks using our product search API. Easily my favorite. When designers build out a mock for search results, they drag a set of component instances from the sticker sheet. Making it look realistic requires going to the production app and copy and pasting the product title, merchant name, price, rating, image… over 40 clicks and minutes spent on a single result. I build a Chrome extension that copies all of those attributes to your clipboard at once, as well as a Figma plugin that accepts the pasteboard contents and applies those data to the correct component instance’s layers. Now it’s three clicks and ten seconds.
My workflow
When opening an AI IDE it can be tempting to just start describing what you want, accepting changes, and iterating. But with LLMs you want to provide specificity or else they go in too many directions at once. You’re left with code you don’t understand and throwing different prompts around just to get back to something that works.
Instead, start with a conversation about requirements. In your prompt, give all the information you currently have. Stress that you are thinking about the user goal and want to stay at a high level:
The goal of this project is to create a Figma plugin that checks icons for missing descriptions. The description is a value attached to instances of the Icon component.
Do not write code at this time. Create a product requirements document (PRD) that describes my goals for this project in great detail. Include a breakdown of the project into smaller, manageable pieces that can be done independently. Include sample code and consider edge cases. Keep a list of tasks remaining and a list of questions you have for me. I can answer these questions and you can update the PRD with new information.
The magic here is you now have a common source of truth with the AI agent. Save this as a text file in your project and include it as context in future chats.
That’s… a really good one-shot PRD
With this in hand, you can begin the actual coding part. Ask “what’s next on our PRD?” or “how should we approach [PRD section]?” As your project progresses, keep the PRD updated with the latest decisions.
Above all: work in small chunks, building up to a single feature. Think and work in milestones. If you need more specificity, ask the agent to update the PRD:
Break out the `data store` section into smaller steps.
Looking forward
I said earlier that this has changed my approach to work entirely. I remember the days when I would beg for a budget to get a contractor UX engineer on my project to make a high-fidelity prototype. Now, I can tackle it myself… in half a day.
The code isn’t production-ready, but it doesn’t have to be. It has to work well enough to do its job at the moment. And maybe that’s where this road leads: code that’s so cheap to write you don’t even bother checking it into source. Bespoke apps that are spun up for a single user’s needs and then, having served their purpose, tossed aside.