Hey Reader

Everyone on your team can build a prototype now, and that’s a good thing, until every one of them gets judged like it’s ready to ship. This week’s issue gives you shared language to fix that, plus resources on making your case with evidence and where designers still add the most value.

In today's email:

• Designers writing code: A new book making the case for designers to start shipping their own code, plus a tool built to make that shift less painful.
• What AI still can't do: Two sharp takes on where human judgment, taste, and problem-finding remain the job, even as the drawing part gets automated.
• Making your case: A library of real A/B test results and a tactical breakdown of what makes a product vision actually land - evidence and persuasion, still core skills.

🎟️ Get your ticket to our next live event with Jeremy Miller where you'll learn where your real leverage actually is and how to use it. Through discussion and hands-on learning, you'll leave with a way of thinking about your work that holds up when the plan falls apart.

Design gems of the week

• ​Griddy Icons: A free, open-source library with 1,350 icons now available. If you want solid, consistent icon set, this is a great one to bookmark.
  ​
• ​80% of a UX designer's value: A grounded answer to "if Claude can draw the UI in 3 minutes, what are designers for" - the problem-finding, stakeholder-wrangling, and taste work is still almost entirely on us.
  ​
• ​The Return to Craft in AI Design Leadership: Why design leaders who stay hands-on with the work, not just manage it, are the ones who can actually guide their teams through this.
  ​
• ​Product Design Engineering: A new book making the case for designers to start shipping their own code, with AI finally making it realistic.
  ​
• ​Graphical: A visual theme builder that turns your design language into tokens and agent-ready files, so Claude or Cursor can actually hold a consistent style instead of improvising one.
  ​
• ​fglibs.com: Describe the exact interaction you're prototyping and it points you to the code library someone already built, instead of you burning hours reinventing it.
  ​
• ​abtest.design: A library of real A/B test results - pricing, onboarding, paywalls - with the exact tactic and the lift it drove.
  ​
• ​What a Product Vision Actually Has to Do: A tactical breakdown of what makes a vision land - evidence-based but opinionated, concise enough to actually stick.

Open design roles:

• ​Senior/Staff Product Designer (Amplemarket) - Remote, EMEA
• ​Manager/Senior Manager, Product Designer (Mandai) – Hybrid, Singapore
• ​Product Designer (Footlocker) – Remote, USA
• ​Designers (Pocket) – Unsure.
  ​

AFFILIATE PARTNER Make stronger design decisions grounded in what real products actually ship. Mobbin’s library has 600K+ screens from 1,000+ live apps, and their MCP brings those references straight into your AI tools, so your prototypes start from proven patterns instead of guesswork. ​Get 20% off Mobbin Pro ↗​

From bottleneck to enabler: a framework for vibe-coded prototypes

PMs and devs are vibe coding prototypes and skipping the design process. Overnight, designers have become the bottleneck.

The prototype shows up fast and looks close to real. By the time it reaches you, it's been shared in Slack, maybe shown to a VP, and it ignores the design system and half the edge cases.

Your options:

1. Slow it down
2. Let it go

I don’t think either is the real job. The problem is that every prototype gets judged against a production bar, even the ones that were never meant to ship.

So what if your team gave every prototype a clear job? Sketches to explore. Probes to test a question. Blueprints that actually ship. And what if your design system was easy enough to vibe code with that the right path was also the fastest one?

The problem isn't vibe coding

PMs and devs prototyping more is a good thing. Ideas get tested faster, people feel ownership, and you get to react to something tangible instead of a doc.

The tension is this: one artifact is being treated as three different things. It starts as an exploration, gets shown to a stakeholder, and slowly turns into "the plan". By the time design sees it, you're judging a sketch against a production bar it was never built to meet. Suddenly, design is seen as a bottleneck for pushing back and advocating to slow down.

Every prototype has a job

The fix is shared language. Give your team three types of prototype, and be really clear about which is which.

A couple of notes on the middle row, because that's where things usually go sideways. A probe still needs a designer's eye, even if it's not on-system, because a leading prototype gets you a misleading answer.

The unlock is this: sketches are allowed to be messy forever. They're just not allowed to ship.

Three questions to ask before anything gets shared

To stop prototypes drifting, try a lightweight "prototype contract." Before a vibe-coded prototype goes beyond the person who made it, they need to answer:

1. What question is this answering? If there isn't one, it's a sketch.
2. Who's going to see it? Teammates, leadership, and customers carry very different risks. Showing an off-system prototype to an exec is often how it accidentally becomes the spec.
3. What happens to it next? Thrown away, tested, or handed to design to refine or engineering to build?

Make the right path the easy path

Here's where you get to move upstream.

Writing guidelines helps. But the biggest lever you have is making your design system easy to vibe code with. Think a starter repo with your components already wired in, a context or rules file for whatever AI tools your team uses, and a few example prompts that produce on-system results.

If prototypes use the system by default, your role can shift from the person who shuts prototypes down to the person who makes everyone's prototypes better. Win.

What to say in the moment

Even with a framework, you'll still get handed prototypes that make you wince. A few phrases that keep you on the same side as the person who built it:

• "What are we trying to learn?"
• "What would need to be true before it's a blueprint?"
• "Before this goes to leadership, can we spend 30 minutes on what we want them to react to?"

Notice none of these mention the design system or the missing edge cases. You'll get there. Start with the intent, and the quality conversation gets a lot easier.

Try this week

Pick the next vibe-coded prototype that comes your way. Before you give any feedback, ask the person who made it the three contract questions: what question is it answering, who will see it, and what happens next?

Then share the sketch, probe, and blueprint language with them and ask which one they think it is. You might be surprised how quickly that one conversation changes how your team prototypes.

P.S. This came straight out of my group coaching program, where we work through exactly these kinds of messy, real-team problems together. We have 5 open spots starting January 2027 – book a call to see if it's a good fit for you.

If your team has already figured out a good way to handle this, hit reply. I'd love to hear what's working.

Have a topic you'd like me to write about? Reply to this email and let me know! I read every reply.