./writing/gearious/tools
Learning to Talk to the Robots
The wireframe from post 01 was a verdict, not a product. It told me the tools had potential. It did not tell me how to use them well. This post is about the next stretch — the months of figuring out which tools to reach for, which ones to put down, and how to write instructions that produced something other than confusion or beige.
A theme emerged. The tools are extraordinary at filling in detail. They are not extraordinary at reading minds. The work I had to do was the work of saying clearly, in advance, what I wanted — which sounds like a small thing and turned out to be most of the job.
figma make, and the blank canvas it was built to defeat
The first tool I tried after the ChatGPT wireframe was Figma Make. Figma had introduced it at Config in 2025, and the mental shift for me was as interesting as the tool itself. Up to that point, AI tooling had felt like outsider tools coming for the design space — encroaching, suspicious, make-sure-you-know-what-you-want-before-you-let-them-in tools. Figma Make was the inverse. The tool I'd lived in for the better part of a decade was inviting AI in, on its own terms, in a way that felt less like an invasion and more like a friend bringing a stranger to dinner.
The framing in the keynote was the part that stuck with me: this tool is for getting you past the initial blank canvas. That landed. The blank canvas is a real problem. I've sat in front of a fresh Figma file hundreds of times in my career, and I sat in front of a fresh Photoshop file before that, decades ago, when Photoshop was the tool that came before Sketch which came before Figma. (You start to notice patterns.) The first move is always the hardest. Anything that helps a designer get to the second move faster is helping at the right layer.
I gave it a try. The tool was still rough — it needed a lot more guidance than the keynote demos suggested, even when you gave it a fully designed screen to work from. And what I had at that point wasn't a fully designed screen. I had hand-drawn sketches from a whiteboard a decade old, lovingly photographed, which is approximately the worst possible input for an AI tool optimized for designers who have already done the design work.
Figma Make wasn't the right tool for me at that stage. The blank canvas wasn't really my problem; I had a wall of sketches. What I needed was something that could take a longer brief and turn it into something I could push on. I closed the tab and went looking for the next one.
cursor, and the prompt that took a week to write
That's when I moved to Cursor. By that point I'd seen enough designers gravitating to it for their side projects that it was worth a serious look. I spent more hours than I want to admit on YouTube tutorials and blog posts and Twitter threads about how to get the most out of it, which is what I imagine a much younger version of me did with HTML in 1996, except the older version of me has gray in his beard and is muttering at the screen more often.
What I learned, after a stretch of false starts, was that I had been making the same mistake everyone makes when they first pick up these tools.
I had been starting with the finished product in my head and asking the tool to build it. Make me a planning app for adventure riders that works like this. The tool was filling in everything I hadn't specified — which is most of the things — with whatever it thought was reasonable. That's how you get an app that looks fine in the first prompt and falls apart on the second. It's also how you get an app whose color palette is, every single time, some variant of a purple-and-blue gradient on white. (I do not know who taught the models that this is what designers want. I have suspicions.)
What worked instead was telling the tool how I wanted the app built. React. Tailwind. Component structure. The specific shape of the data model. The conventions I wanted the code to follow. The constraints, not just the goals. The prompt I eventually wrote for Cursor was the longest single piece of writing I had done in months — and at one point, when I got stuck on how to phrase a particular section, I asked ChatGPT to help me write the prompt I was about to feed into Cursor.
I was sure that having one AI write a prompt for another AI was going to open up some kind of dimensional rift.
The rift did not open. The prompt did get better.
When I finally pasted it into Cursor and watched the tool stand up a framework, install packages, and generate an actual working prototype, I had my second moment of oh — this can really happen. The first was the ChatGPT wireframe. This one was bigger. The wireframe was a clickable picture. The prototype was running on my laptop. The bar between idea and thing that runs had moved an enormous distance, and I had moved it in an afternoon.
The prototype wasn't a real product. No backend. No database. The data model lived in memory and reset every time I refreshed the page, which is the kind of constraint you tolerate when the alternative is not having a prototype at all. But I could add gear to my inventory, define how many bags were on my bike, drag the gear into the bags, and watch the app calculate the total weight and the left-right imbalance in real time. The thing the entire app had been about, for fourteen years, was running on my laptop.
I had built it — or close enough to built it that the distinction stopped feeling important.
learning to instruct at the right altitude
Then I spent the next stretch of time learning how to talk to the system.
My first instinct as a designer was to instruct it like I was art-directing a junior designer in Figma. Move that label two pixels left. Change that border to two pixels solid. Tighten the padding under the heading. Make that color match this one I'll paste in a hex code for. The instructions worked. They were also the smallest possible use of the tool, and using them at that altitude was roughly the equivalent of hiring a chef to make me a sandwich.
What I had to learn was to instruct one level up — at the workflow level, not the pixel level. When the user drags a gear item out of a bag, the balance indicator should update before the drop animation completes, so the user feels the math working in real time. If a user adds a bag to the right side of the bike, the left and right totals should re-balance silently, without the indicator animating, because the user didn't initiate that change and shouldn't see it called out. The empty state for the gear library should not be a "+ Add Your First Item" button alone; it should suggest a few starter categories, because a brand-new user has no context for what they're supposed to add.
Those instructions are not pixel-level instructions. They are design instructions. They describe what the experience should feel like and trust the tool to translate that into the implementation. That's where the leverage is. That's the move.
I am still — I want to be honest — better at the pixel-level instructions than the workflow-level ones. The workflow-level ones come with practice, and I have been practicing. Some afternoons I catch myself reaching to push a button left by four pixels and have to talk myself out of it. Erich. The button is fine. Describe the interaction. This is, apparently, what it sounds like to be the older designer in the room learning a new way to work. It is fine. It is even kind of funny.
what's coming up
The prototype was the inflection point of this stretch of the work. It was also, looking back, the moment the project quietly stopped being just a design exercise and started being something with the shape of a real product. The next post is about that — about the two mentors who picked up the phone when I called, the foundations week that turned a side project into a real one, the slow process of letting go of the pixels at a level I hadn't yet, and the landing page that made Gearious officially A Thing On The Internet.
That's the post where it stops being a working prototype on my laptop and starts being something I can point people to. We're getting there.