AI and the Designer’s Job: From Pixel-Pusher to Curator

In August, about a dozen of us spent a day working the same fictional client. One person played the client and gave an unscripted brief. The rest of us asked questions, recorded the conversation, and had Claude turn our own recordings into project briefs. Then we turned the briefs into wireframes, and the wireframes into interactive prototypes.

Same conversation in, different briefs out. The differences weren’t wording. People had picked different things to care about. The prototypes that came next were all solid, and each headed in a different direction.

Nobody had trouble producing something. The hard part was saying which one was right, and why.

That’s the shift. Pushing pixels is honest work, and it’s how most of us learned the trade. But when a tool can hand you ten layouts before your coffee cools, making stops being the scarce skill. Deciding takes its place.

What got cheap, and what didn’t

Jason Cyr, who leads design for Cisco’s security and AI products, puts it simply: the build side of product development got about ten times faster, and the thinking side didn’t. Layouts, components, first-draft screens, working prototypes and a dozen variations of each are cheap now. Knowing who the user is, what’s worth building, and which option is right is not.

Cheap to generate isn’t cheap to judge. Ten options in an hour still means somebody has to look at ten options.

What the job is now

‘Curator’ is shorthand. Picking a favorite from a menu someone else made is the small part. The bigger part is four jobs.

1. Frame the problem. Before you ask for anything, know who it’s for, what it’s for, what limits apply, and how you’ll tell if it worked. Cyr describes building a pipeline of AI agents that failed badly without clear direction at the start. Bad direction at machine speed gets you more of the wrong thing, faster. Framing is the part you can’t hand off.

2. Choose and kill, with reasons. “None of these, and here’s why” is the most useful sentence a designer can say right now. The pick matters less than the reason, because the reason is what you take into the room with a product owner. Kateryna Orlova, a UX/UI designer and researcher at OnePageCRM, warned that a junior can choose the right option without understanding why it’s right, or when it stops being right. The bar is no longer whether the output is good. It’s whether you can say why.

I hit this challenge building a task app for my own daily use. I gave Claude the Figma design and it built something that worked: drag-and-drop kanban, live data, and the color and type tokens all pulled in correctly. The layout and components weren’t close to what I’d designed in Figma. They’d drifted to generic patterns. Working code and correct colors are an easy reason to accept the output, and I had a specific reason not to. I sent it back as not done. Then, instead of re-prompting screen by screen, I gave the tool a DESIGN.md to read moving forward. The designs improved because the reasoning was now explicit.

3. Encode what you decided. Once you’ve made a call, write it down where the next person, or the next tool, can find it. That means a design system, a set of principles, and increasingly a file like DESIGN.md that a coding agent reads at the start of every session. Tools can pull colors, type, and spacing out of a Figma file accurately. What they can’t pull out is the reasoning, or what your system would never do. Left to guess, they invent a plausible reason. With no file at all, they fall back on defaults, which is how you end up with products that all start to look alike.

The order matters, and we at EKKO are still working it out. On a product that already exists, you can settle the design and pull the system out of what shipped. A new product or one facing a redesign has nothing to pull from, and most AI tooling assumes the system is already there. Our working idea is a small seed: a short brief, some initial Figma concepts, a handful of tokens for type, color, spacing, and size, and most importantly, a list of don’ts. Generate against that, decide, and move each decision into the system as you make it. It’s still early, and we haven’t proven a new product needs more than that. From our work so far, we think we’re on the right path.

4. Stay close to users. This is the one the tools can’t touch. AI can summarize a call. It can’t sit across from someone and watch where they hesitate. Cyr expects the designers who do well to spend more time with users, not less. Orlova puts the target in the same place: the gap between what people say and what they do is usually where the real problem lives. Double down here and you’ll have valuable concepts to judge with.

The catch

You can’t curate what you can’t judge. Judgment comes from reps, and for most of us, the reps were production. Building forty button states taught you spacing, hierarchy, and what breaks. Nobody planned it as training. It just happened. Now the tool builds the forty, and the accidental education goes with it.

We don’t have a clean answer for how a young designer builds that judgment now. If someone tells you they do, ask what they’ve shipped. Shopify’s answer is a six-month apprenticeship that pairs junior designers with mentors on real shipped work, according to Designer Fund. Maya Brennan, who went from Figma to shipping production code at Amplitude, is honest about the cost of moving this fast: a real detachment from craft.

Here’s where we think the blue-collar approach earns its keep. The trades figured this out a long time ago. You learn on real jobs, next to someone who’s done it, with the tools in your hands, and the feedback is immediate because the joint holds or it doesn’t. EKKO’s blue-collar UX has always meant small, real jobs, important work, and short loops. That’s what a junior needs: many decisions, close to real users, an experienced person nearby, and quick evidence on whether the call was right.

Speed multiplies the decisions and does nothing for the feedback. So the work is to shorten the loop and make the learning deliberate. Here’s what we’re trying:

• Call it before you generate. Create your own concept and one sentence of reasoning, then compare it with what the tool made. The gap between the two is the lesson, and it takes a minute.
• Keep a decision log. What you chose, what you killed, why, and what would change your mind. It trains the reasoning, and it becomes the rationale layer for your design system and your design approach. Use tools like Obsidian to capture these decisions so you can reflect on them later.
• Compare with a peer. Same brief, two designers, two results. Ask each other why. This is what made our August day worth the time.
• Ride along. Sit in on the client conversation and the design review. Read the technical constraints before you design, not after the review finds them.

None of this is free. Apprenticeship takes senior time, and senior time is the thing AI-speed work squeezes hardest. We haven’t solved that part either. We’re adapting the same exercise for classroom use at Ferris State University where I teach, because that’s where we’re looking hardest for an answer.

Less time per decision

Cheap options have another cost. Cyr’s point is that design spent years moving upstream to buy time to think, and AI ate that buffer. More options, arriving faster, means less time per call. Younger designers feel it most because they don’t have the patterns in their heads yet.

A few things help:

• Set criteria before you generate. Who it’s for, what it’s for, the limits, and how you’ll know it worked. Judging against criteria is faster than judging by feel.
• Sort decisions by how hard they are to undo. Move quickly on the ones you can reverse. Slow down for structure: navigation, flows, naming, accessibility.
• Borrow a senior’s checklist. Ours is short. Color contrast tested to AA before a client sees it. Mobile first. A system with defined type, color, spacing, and sizing. A checklist gives a junior something to check against while the patterns build up. You can leverage Figma for some of these tools. Take a look at the “ready for dev” features and the token checks before that ‘ready’ flag is applied.
• Spend the slow time at the start. Direction is where time pays off. Most of what comes after can run fast.

Where this leaves you

If you’re a designer: keep making things. The people who’ll do best can still make and can explain why. Write the why down every time, and practice saying it out loud, because that’s how the next interview and the next stakeholder meeting will go. The proof of your value is bending away from the “portfolio pretties” and toward how you made decisions in plain language.

If you’re a product owner: ask your designers for the reasons behind the pick, not just more options. Give them the constraints and access to real users. And leave room for junior designers to learn, because today’s juniors are where senior judgment will come from.

Making got cheap. Judgment didn’t, and it still has to be learned somewhere.

By Erik Loehfelm, UX/CX Strategist and founding partner at EKKO Studio