Drafting used to be a profession. CAD ended it inside one career. The lesson for product designers right now is precise, and the people who miss it will miss it the same way.
Read article
AI-generated research participants are fast and cheap. What they can't do is tell you how real people actually behave, and that gap is exactly where the risk lives.
If you took away the incumbent team, the half-built tooling, and the political memory of an earlier attempt, what shape would the program actually want to be?
If you took away the incumbent team, the half-built library, and the political memory of an earlier attempt, what shape would the program actually want to be?
If you took away the incumbent team, the half-built tooling, and the political memory of an earlier attempt, what shape would the program actually want to be?
AI-generated research participants are fast and cheap. What they can't do is tell you how real people actually behave, and that gap is exactly where the risk lives.
If you took away the incumbent team, the half-built tooling, and the political memory of an earlier attempt, what shape would the program actually want to be?
If you took away the incumbent team, the half-built library, and the political memory of an earlier attempt, what shape would the program actually want to be?
If you took away the incumbent team, the half-built tooling, and the political memory of an earlier attempt, what shape would the program actually want to be?
The tokens, components, and code are the part you can point at. Whether any of it gets used comes down to work that isn't design or engineering at all.
Drafting used to be a profession. CAD ended it inside one career. The lesson for product designers right now is precise, and the people who miss it will miss it the same way.
AI changes what designers produce and how fast. It hasn't touched the parts that determine whether the work is good.
AI-generated UI looks done before it's right. The things worth checking first aren't the things that catch your eye.
Not a roundup. A short, opinionated list of what I actually use, what I've stopped using, and what's mostly noise.
Claude Code changes what a designer can hand off and to whom. The boundary between intent and implementation is getting genuinely blurry.
AI writes usable component docs in minutes. It also writes confident, plausible-sounding garbage if you give it the wrong input.
AI has changed the synthesis side of research. It hasn't changed the part where you sit with a real person and watch them try to use your product.
Every product claims to be AI-native now. Most of them aren't. The distinction matters because it changes how you build, what you measure, and what you're actually competing on.
Not component generation. The value is in compressing the tedious, repeatable work so judgment can go where it actually matters.
Most advice about AI for design is generic LLM guidance dressed up in design vocabulary. Here's where the value actually lands.
What I've learned shipping AI-native tools over the past year. What works, what doesn't, and where the real leverage is.
Tables are some of the most information-dense UI components in any product. Most of them are designed with too little thought for how data actually behaves in them.
Most design briefs are written to exist, not to be read. The ones that change behavior share three properties that most briefs skip.
Engineers don't ignore specs out of disrespect for design. They ignore them because the specs are wrong in specific, predictable ways.
Modals interrupt users by design. That makes them the right tool in some situations and the wrong one in more than most teams realize.
Design and data science have overlapping concerns and almost no shared vocabulary. The friction between them is predictable and worth solving deliberately.
Design teams blame stakeholders for scope creep. Stakeholders blame unclear briefs. Both are usually partially right.
Accessibility debt works like technical debt but compounds differently: the violations accumulate quietly, the cost to fix grows with every new surface, and there's no static analysis to surface the interest.
Tokens don't solve the platform problem. When you take a web design system to iOS and Android, the hard parts have nothing to do with color values.
Navigation that works with five items usually breaks at fifteen. The reasons are structural, and they're predictable early.
The question of when design drives product decisions versus when it executes them is situational. Getting the read wrong in either direction creates different problems.
Escalating too quickly teaches people you can't handle conflict. Not escalating enough teaches them you won't fight for anything.
Touch target size minimums have existed for over a decade. They're still routinely ignored. The problem isn't that designers don't know the numbers. It's that the design environment hides the violations.
Office hours that wait for people to show up usually don't. Here's a different approach to design system support that generates real usage.
Spinners, skeletons, and progress bars are not interchangeable. Each one makes a specific promise to the user about what's happening.
Design-led gets invoked to describe everything from Apple's aesthetic to a rebranded product process. Only one of those uses is worth arguing for.
The gap between junior and senior isn't about craft. It's about judgment, and judgment can't be taught in a workshop.
The goal of alt text is not to describe what the image looks like. It's to serve the purpose the image serves. Those are different things more often than you'd expect.
Silence on a deprioritized request costs more than a clear answer. Here's how to handle the queue without destroying trust.
Hover states are a design crutch. They work on desktop, they reveal nothing on mobile, and they're often doing jobs that better design would eliminate.
Contractors accelerate output and introduce risk that most design teams underestimate until they're cleaning it up. The risk is manageable with the right structure.
Senior portfolios show you the work. What you actually need to evaluate is the thinking underneath it.
Automated audits and manual inspection find markup problems. Testing with real assistive technology finds usage problems. They are not the same thing.
The bar for 'done' in a design system is different from the bar for done in a product. Most teams discover this at the worst possible time.
Most UI color problems aren't about choosing colors. They're about using too many of them, for the wrong reasons.
Specialization solves real problems in large design organizations. It also creates a set of new ones that only become visible once you're inside them.
When what gets built doesn't match what was designed, the gap is rarely about communication.
Developers don't dismiss accessibility because they're indifferent. They dismiss it because the feedback they've received about it has been vague, late, and disconnected from how they work.
Component count and install numbers are the metrics design system teams report most and learn from least. Here's what actually tells you something.
Most design QA problems are avoidable if the designer reviews their own work the way an engineer will build it.
The Sprint process solves a specific kind of problem well. Applied to the wrong situation, it produces expensive consensus theater with a prototype attached.
Resistance to process is usually a signal about the process, not about the people resisting it.
Inclusive design gets used as a synonym for accessibility, then as a synonym for diversity. In product practice it's something more specific and more actionable than either.
Engineers who skip the design system almost always have a reason they can articulate. Listening to it is faster than any adoption campaign.
The interesting responsive decisions aren't about breakpoints. They're about what changes structurally when context changes.
The instinct to start with process and tooling is understandable and usually wrong. Culture changes when behavior changes, not when policies are announced.
Measuring design output is easier than measuring design impact, and most teams are measuring the wrong one.
Screen reader support and keyboard navigation have clear technical requirements. Cognitive accessibility doesn't, which is why it's easy to feel like you're doing it when you're not.
Figma and code diverge constantly, and some of that divergence is fine. The problem is not knowing which divergence to fix and which to leave alone.
Error messages are a design surface most products treat as an afterthought. The ones that work share a few specific properties.
Companies where design isn't in strategy conversations don't just make worse products. They make a predictable set of specific mistakes, over and over.
By the time you're presenting, the people in the room have already formed a view. That's the thing to fix.
Starting an accessibility program at a company that has none is less about training and tools than about knowing exactly where to apply pressure first.
Teams reach for theming when they need variants, and variants when they need theming. The confusion is expensive and usually shows up in production.
Forms are where most products lose users. The same mistakes recur so reliably they might as well be defaults.
Most handoff problems aren't communication problems. They're process problems that produce communication failures as a symptom.
When a designer says 'things are good' every week, that's usually not information. It's a habit.
ARIA attributes can make inaccessible interfaces accessible. They can also make accessible interfaces inaccessible. The first rule of ARIA is not to use it.
Most teams make the buy-vs-build call too early, with the wrong criteria, and find out it was wrong two years later when the cost of switching is enormous.
Most onboarding flows fail before the user finishes them. The reasons are more predictable than most teams expect.
Designers tend to frame this as a cultural problem or a seat-at-the-table problem. It's often neither. Here's what's actually happening.
Career ladders describe the behaviors that got someone promoted, not the work that moved the product.
Keyboard accessibility isn't something engineers bolt on after design. The decisions that break it are made in the design file, long before a line of code gets written.
Most doc sites get traffic on component pages and almost nothing else. The problem isn't the writing. It's what the other pages are trying to do.
Designing for real content means designing for every version of it: too short, too long, missing, wrong language, or all caps.
Culture is what people do when nobody's watching. For design teams, that means what gets celebrated, what gets corrected, and what gets quietly tolerated.
Writing a job description before you understand the problem is how you end up hiring the wrong person confidently.
The basic patterns aren't basic. They're full of decisions designers make on autopilot, which is where most of the broken ones come from.
Multi-brand design systems sound like a tokens problem. They're actually a question about how much of your design is brand and how much is something else.
Asking 'what's the ROI of design' is the wrong question. The right one is what wouldn't exist or wouldn't work without design's contribution.
Most design OKRs measure things designers can't move, or things that don't matter. The version that works is narrower than people expect.
Most attempts to make interfaces screen-reader-friendly make them harder to use. The fix is to design for both audiences at once.
Semantic versioning is the easy part. The hard part is what to do when your tokens change and a thousand consumers don't notice.
Inverting the palette is the fast way to ship dark mode. It's also why most dark modes look broken.
Most design feedback is comments. Useful feedback changes what the designer does next.
Maturity models are a diagnostic, not a destination. The companies highest on the chart aren't always doing the best design work.
Animation earns its place exactly once: when it helps the user understand what happened or what's about to happen.
The protection instinct is real and sometimes right. But it can also be avoidance dressed up as leadership.
'Polish' isn't vague. It's a specific set of decisions about consistency, attention to edge cases, and micro-interactions. Here's how to think about it systematically.
Design ops gets staffed for logistics and ends up responsible for everything nobody else owns. The version that works is narrower.
Type decisions determine whether most interfaces feel polished or rough. Most designers treat them as secondary. Here's what to actually pay attention to.
Component proliferation is a governance failure, not a success. Here's how to recognize it, what it costs, and what to do about it.
The naming and structure of your token system determines whether it survives past the first redesign. Here's what actually matters.
Fidelity should match the question you're trying to answer. High fidelity at the wrong stage is expensive and constrains exploration.
Executives aren't evaluating the design. They're evaluating whether the decision behind it was sound.
Companies promote great designers into management without asking which role they actually want. These are different jobs with different skills, and conflating them makes both worse.
Building a component is celebrated. Deprecating one is avoided. That asymmetry is how design systems bloat.
You can pass every automated check and still break keyboard navigation completely. Here's what falls through the cracks.
The instinct is to jump in and fix things. That's almost always the wrong move.
Figma file organization is craft. A badly organized file destroys velocity after the honeymoon phase ends. Here's the system that's worked for me.
Whitespace is a tool, not a virtue. The right density depends on what the user needs to hold in view at once.
Naming is how the system communicates intent. Bad names mean engineers have to remember what something is rather than understand it.
Open contribution sounds democratic and scales poorly. Here's what actually works.
Most design critiques fail for the same reasons. Here's a structure that actually produces better work instead of just more feedback.
Most documentation is written to be comprehensive. Good documentation is written to be used at the moment of need. The difference is everything.
Contrast gets fixed more often than it gets solved. Here's the difference.
When design quality feels low, the instinct is to level up the team. Mostly that's the wrong diagnosis.
Neither model is universally right. Here's what each one actually costs you, and how to decide which tradeoff is worth making at your company right now.
Empty states are where most interfaces reveal their laziness. They're also one of the highest-leverage design moments in any product.
When teams treat accessibility as a legal requirement, they do the minimum at the end of the process. They also do it worse than if they'd treated it as design from the start.
The expectation was obscure edge cases. What we actually found was the same five problems repeated everywhere.