The Tools Changed. The Job Didn't.

Jul 20

5 min read

Two years of shUX, and a year of rebuilding how we design.

We just hit our two-year mark. Two years of shUX, and I can say with confidence that the way we work today looks almost nothing like the way we worked at the start.

The short version: AI didn't replace our design process. It just made a lot of it faster, and quietly exposed which parts of our process were habits rather than decisions.

By habits, I mean the steps we take because that's where we've always started. Opening Figma first, no matter the question. Assuming every change has to travel the same route from design to approval to story to backlog. None of those were bad calls when we made them. They just stopped being calls at all.

The longer version comes in two stories.

Story one: the client we've had since day one

This is a mature product with a pretty mature UI kit. For two years, the rhythm was familiar and, honestly, comfortable. Build screens in Figma. Refine stories with product. Hand them to developers. Repeat.

Now most of our screens start in Claude Design or Claude Code, and which one depends entirely on what we're being asked for.

For brand-new ideas, Claude Design has become our ideation space. We fed in our existing Figma kit. And yes, we reviewed it thoroughly and tweaked it first, because garbage in, garbage out is still the law. The results came out noticeably closer to our actual product than what we'd been getting elsewhere. Close enough that we got a little bold with it.

We ran an internal challenge where the whole team used Claude Design to ideate. Traditionally, that's Crazy 8s territory: eight boxes, eight minutes, everyone sketching badly and loving it. To be clear, Crazy 8s is not dead. I will absolutely still make you sketch. This was about getting people who don't live in design tools comfortable inside one, and watching what they'd come up with when the tool stopped being the barrier.

Now the honest part. Claude Design still isn't perfect with components. It gets us dramatically closer than it has any right to, but "closer" isn't "done." So for a few key screens, we exported to Figma to clean up, mostly because our component library was already sitting there, ready and waiting.

Next time? We're going to try sending it straight to Claude Code and skipping Figma entirely.

Which is sort of the whole point. Right now, our process is an experiment. New tools ship, new features ship, and we adjust. Our process is forever changing, and I'd argue that's exactly what makes us a good design team. Not that we found the perfect workflow, but that we keep changing with it.

We've also started working directly in Claude Code against the product's GitHub repo. This one surprised me most. We can create or update front-end features using the foundation the app already has, and iterate fast.

Last week I pushed a PR to my dev team in under two days. It was a visual change, a full re-skin of our navigation. But here's what that used to look like: design it in Figma, get product approval, write a story, wait for prioritization. And let's be real, a nav re-skin was never going to beat out actual roadmap work. It would have quietly lived in the backlog forever.

Instead it was designed, built, reviewed, and merged into our dev environment in less than a week.

Story two: the blank page

Different client. Brand-new tool. Nothing to inherit except a UI kit shared across their other products.

Since we're apparently in our "challenge everything" era, I set myself a rule: design this thing without Figma.

Here's how it actually went.

Experience Blueprint, in FigJam. Yes. I broke my own rule on step one. I needed to capture the flow, the details, and the data required at each step, and FigJam was my comfort blanket. Next time, I may start somewhere else. But I'm not going to pretend I didn't do it.
Claude Design's wireframe tool. First time using it, and I was genuinely impressed. We presented six concepts and landed on one, all inside a single two-week design sprint. That's one of the fastest concept-to-decision cycles I've had.
High fidelity, still in Claude Design. I imported the existing .fig UI kit to build the design system, added a slimmed-down data set, and have spent the last four weeks iterating in a fully functioning high-fidelity prototype. The speed here isn't just about making screens faster. It's that we can share the happy path and break it. We can walk stakeholders through the error state, the empty state, the "what if they do this instead" state. All the stuff that usually gets discovered three sprints into development. Decisions and approvals came faster because there was simply less left to imagine.
Handoff. Their dev team is building with Claude, so once we're approved, we're exporting straight to Claude. Stay tuned for how that goes. I'll report back, good or bad.

What I've actually learned

The wireframe tool earns its keep. Every designer knows the pain of showing a polished screen and getting feedback on the button color instead of the flow. Wireframes force the conversation to be about functionality first. It's nice to have a fast way to stay disciplined.

Real data means a real story. Be honest: how often do we make up the story as we go? The product selected on screen one isn't the product that shows up in the summary. Everything is Product 1, Product 2, Product 3, because real names are tedious and we've got four more screens to build. A real data set, even a slimmed-down one, forces a coherent storyline through the whole flow. And stakeholders understand what they're looking at when it behaves like their actual product instead of a placeholder.

Batch commenting is quietly brilliant. I can point at fifteen things I want changed, comment on all of them, then run one prompt. That's how critique actually works in a designer's brain.

Downloadable HTML prototypes are a game changer. I send a client a file. They click through a working prototype. They give me feedback based on what it does, not what it looks like in a static frame. That alone has changed the quality of feedback we get.

The part I want to be very clear about

Claude Design isn't perfect. And that's exactly why a UXer needs to be the one driving it.

The tool will happily give you something that looks right. What it won't do is notice that step three asks for information the user couldn't possibly have yet. It won't catch that you've created a dead end with no way back. It won't ask who this is actually for, whether this flow respects the user's time, or whether the "efficient" path you just built quietly strips out the moment where someone needs to pause and think.

The designer's lens is what turns a fast output into a good one. Speed without critique just means you ship the wrong thing sooner. AI gave us a much faster first draft. It did not give us judgment, taste, or the responsibility to advocate for the person on the other side of the screen. That's still the job. Honestly, it's more the job now that the production work has gotten so much cheaper.

Two years in

We don't have this figured out. We have a process that changes every few months, a growing pile of experiments, and a stubborn belief that adapting fast is worth more than being right the first time.

If that sounds like the kind of design partner you want in the room — one that will use the newest tool available and tell you honestly where it falls short — we're taking on new work. Come build something with us.