Old Man and the AI

A first encounter with the artificial will not defeat me.

I am a massive AI cynic. I’m the person who relishes in telling people the doom stat that 15 tokens guzzles a bucket of water. I am a designer for a startup attempting to solve the climate crisis. I have to be cognizant of the damage tech is unleashing into the world. But AI’s not going anywhere, and it’s a bit of know thine enemy sort of situation so I need to spend some time understanding what I’m undeniably going to be working with in the future.

You will not defeat me, weird fish.

My first impression of AI as a design tool is: broadly mediocre, pretty solid in a few key areas. Producing usable, clickable CSS is my favorite AI skill. I have working knowledge of CSS but it takes me sooooo long to code anything, so I like this ability to play more freely with the puzzle pieces. I also got quick answers to ‘how can I modify this component’ without having to talk to any of our engineers. Which at first blush felt like such a time saver, but it also felt like diminished interaction with my team.

This feels like where design teams will start to drift. We’ve fought to get a seat at the table, and the fewer conversations we’re having as designers means less visibility, waning influence to champion our ideas. If we aren’t careful, punching the AI button can feel like a step backwards into commoditization of what we do. Keep an eye on this on your own team as you experiment, and maintain the collaboration.

Other ways AI works well is in tedious tasks like cleaning up copy, correcting grammar, connecting dots on a particular problem, and of course the blank page problem. All great things that are generally net positive for my productivity, but still require double checking. These LLMs have a tendency to throw in a lot of random shit into your copy and your code, so you need to be diligent. I had previously dipped my toe in the AI water by putting together a handful of basic front end experiments, so I felt it was a good time to try AI out in our professional workflow.

---

Here’s a quick rundown of this feature we’re developing at Terraformation: Inventory Management for nurseries, and setting up Planting Seasons, as well as integrating our Withdrawals feature. Connecting a lot of dots and adding new functionality.

False Starts and Wireframes

At the discovery phase of the design process I attempted to pump out a few Figma Make prototypes to see if it pointed us in any meaningful direction. It was way too early in the process to jump into mocks, and I fed it the wrong prompts as I conflated two feature inputs. So, we went back to wireframes I made in Figma first and THEN built off those in my next attempt in Claude Code. Like I mentioned previously, I used AI to test out a modification to our table component and it came up with some workable results.

While I am relatively pleased with the direction that we came up with, unfortunately I’ll be converting the screens back to Figma mocks. The visual outputs were nowhere close to handoff level. Testing interactions real-time with stakeholders was beneficial, so that alone seems worth the manual labor of converting a few screenshots. I have been running into a lot of frustrating design system tradeoffs in the design translation phase — our own components not quite matching to the prototype, mostly. It seems as if you can never really escape this type of tedious maintenance with product design, no matter how advanced the tools are.

Key Learnings:

1. Get your discovery straight, know what you’re solving before burning tokens.

2. Clickable prototypes evince substantial clarity BUT…

3. Claude Code may be a bit overkill, Claude Design shows promise for fewer code-heavy solutions and design system integration.

Plug in the React table library and presto! New component UI, no questions asked.

Requirements, Did I Stutter?

After we were satisfied with the prototypes, my PM partner attempted using Claude Code for a diagram of notifications and a Must Have/Nice-to-Have checklist for me. The prioritization doc just ended up being overkill, Claude overloaded it with superfluous info. The notification diagram it cranked out ended up being helpful, though. On our next feature development cycle, it feels like we’ll be better prepared for the pitfalls of LLMs. We learned which tasks we could offload, and which we had to do ourselves.

Key Learnings:

1. Summarizing priorities and requirements still need to be mostly compiled by a human.

2. AI can create excellent diagrams and flow charts from your prototypes and context.

3. AI has a tendency to overcomplicate everything, especially technical text.

This little dojobber was handy output that would have been a pain to create in the olden days.

Overall I would say we benefitted from over half of the ideas generated by Claude Code. We got clarity in areas that we typically would have to make assumptions for, so that feels like a win as well. In the next cycle, I’ll try to use AI only after the constraints are set and only for iteration, not direction. And I’ll be mindful about my usage and try not to prompt frivolously.

I continue wringing my hands concerning the energy suck these artificial helpers consume. But I’m also a dad, so I also get depressed thinking of how many diapers I’ve pitched into the landfill. Everything has a cost. I can say I am more amenable to AI after applying it in earnest to our most recent feature development. I see its fail points – so while I’m cautiously optimistic – I guess you could say my career just has a bit more artificial flavor to it now.

Onwards for this old man into the AI frontier.