361 posts tagged with “product design”

I’ve started asking Claude Design for multiple directions on a canvas, then sending the promising ones through another pass before I choose. In a conversation between Michael Riddering and designer/builder Kyle Zantos on Dive Club, Zantos builds the missing part of that workflow: an interface for reviewing what the agents made.

Zantos uses a standalone HTML artifact to render the proposals and collect decisions in the same place:

You act as the orchestrator and the quality-control reviewer and send out Opus 4.8 sub agents to execute these audits as each skill does it. Compile the results, but at the end of it, compile it all, remove the duplicates, and then present me an HTML doc that has all the proposed changes and then options for me to approve, deny, or discuss them, and then have a way at the bottom to copy all of what I put in here and just paste it right back into my session with Claude.

Zantos on combining decisions across different parts of a product:

Then be like, “Oh, no, not that. That’s terrible. I hate that.” Or just like, “Yes, but add this other thing.” Or, “I really like what you did in number two on number six that’s in a totally different area of the app or the site or whatever that I’m working on, but grab the technique that we used in the second point of this doc.” So just visualizing everything from your agents has been huge.

Product designer and educator Aliena Cai argues that AI is changing the work, but isn’t replacing one kind of product designer with another. I think her survey shows that replacement can happen without cutting jobs:

The survey found that 60% of design leaders actually expect to keep or grow design headcount. Only 10% of design leaders expect to reduce design headcount, and 8% of design leaders say they are shifting investment towards hybrid roles like design engineers. However, expectations for design talent have shifted. 50% of design leaders are looking for a greater emphasis on AI tool fluency when it comes to hiring. And 48% of design leaders are placing greater emphasis on systems thinking and strategic skills. I would just call it business sense or product sense.

If you’re a manager, you may have heard the terms “rotate people out” and “upskill the role.” That might be happening here. The number of design jobs may stay the same, but the requirements are changing. Experienced designers will be asked to use AI, think about the wider system, and understand the business. If they don’t, they’ll be managed out. People entering the field will face that higher bar from the start. Some who would have qualified for the old job won’t qualify for the new one.

AI fluency here means using the tools to make and revise working prototypes. Designers still need to understand the user and business problem, check what the tools produce, and decide what should ship. Cai gives similar advice:

Based on everything I shared today, I think that if you are an experienced product designer, then there are two things you can do right now to secure your career for the future. Number one is to improve AI fluency. And number two is improve your business sense. But AI fluency really doesn’t mean just using AI for everything, because AI, at the end of the day, is an amplification tool, and it amplifies your design skill and product sense. Just like I said, it brings great ideas to life faster, but it can also bring bad ideas to life faster.

I couldn’t agree more with the AI fluency point. That’s why I’ve been reading and writing about it for over a year.

Podcaster Lenny Rachitsky interviewed Ian Silber, OpenAI’s head of product design.

Ian Silber discusses task-specific UIs. He shows how ChatGPT’s transcript can make room for them:

Another good example is, then once you actually ask it to do something, the chat transcript doesn’t need to be purely text, right? We’ve seen these now evolve so far from what it was with when ChatGPT just launched. It’s no longer just a pure chat bot.

It actually has many features within that, right? So a good example is what we call writing blocks. You ask it to write you a letter or an email.

And it now contains that email in a block that you can directly manipulate, and you can type with it, and you can brainstorm, and you can edit little bits and parts of it. You can copy just that. And that has made that interaction much better.

And we’re seeing the same thing with image generation and creating special tools for that kind of mode. And I think that’s where the UI is going to start to really continue to evolve. How do we make if you come at this and you’re a designer? Maybe ChatGPT should actually really look different or have different affordances. Or you’re a data scientist or you’re using this to run your home, your your personal life.

Maybe it should really kind of work or look differently.

Chat is useful at the beginning of an interaction because users can express ambiguous intent in plain language. The UI can then provide task-specific controls. These might be a writing surface for an email or image controls for a picture. A designer might need another set of affordances. Silber’s example turns the post-chat argument into a product architecture already appearing inside chat. In other words, generative UI.

Chat usually collapses two jobs: understanding what someone wants and giving them the right environment to finish it. Silber on how one entry point could handle both:

And hopefully all of this gets simpler as we do it too, right? When we think of the super app, I think eventually we really think of the idea of especially for our broad consumer base. We do think that there should be this one universal input that you can ask that knows when it needs to answer really quickly, or it should be chatty, or whether it should go off and do work for you.

And so, that’s a big excitement that we can get to. How can we continue to simplify the experience such that you shouldn’t have to think about how this works. You shouldn’t have to think about what model you’re on or what sort of speed you’re using. That goes back to the balancing the different kind of personas and user needs. Of course we want to expose that for the right people, but then we want to make sure that we can get a default experience that works great for for most people.

Quotes slightly edited for clarity.

In an interview with Ryan Mather, Federico Villa, and Robin Chen, OpenAI product designer Benjamin Zweig explains why designing memory for ChatGPT required studying how people remember. The work moved beyond the UI. Zweig had to turn invisible human judgment into training examples and evaluation rules that would shape the model’s behavior:

And the core of it all really is, how do you turn qualitative decisions into a quantifiable rubric? That’s exactly how you train a model to get better at any task.

Here, this meant formalizing the very human skill of determining what’s worth remembering, both in terms of what you save and when you recall it. If you ask a person to explain how they make that decision, they’re not going to have a clear answer for you. It’s an inherently human thing. So what you do is you look at a bunch of examples, apply your human intuition to make a decision, and then look for patterns and ways to turn that intuition into a heuristic that you can train against. That’s a new skill for many designers, and a new way of thinking and working.

Jem Gold’s encounter-language—describing how a design should feel rather than what it is made of—puts the intended experience into words. Design systems leader Yesenia Perez-Cruz, who led Shopify’s Polaris system, takes the next step: giving a team enough shared structure to express product meaning coherently, screen after screen.

Many design languages are really style guides. They define typography, color, spacing, shadows, illustrations, and icons, but say little about how to represent the concepts at the center of the product.

If you remove the opinions from container components while the design language still teaches people to place text and controls inside boxes, you will simply end up with more text and controls inside boxes.

Composability creates room to shape. A design language teaches teams what to shape toward.

Instead of treating a design language as a collection of visual rules, we should think of it as a tool for solving communication problems.

It can help to compare it to written language.

Written language has subject matter, vocabulary, grammar, emphasis, and voice. A product design language needs the same: a model of what it must communicate, recognizable visual signs, rules for composing them, ways to direct attention, and a distinct visual character.

Perez-Cruz starts with the product model: the objects, states, actions, and relationships the interface must make understandable. From there, her language needs a vocabulary that makes those concepts recognizable wherever they appear.

A language needs recognizable signs with stable meanings.

You might think of them as:

• Nouns: visual signifiers for orders, customers, articles, or projects
• Verbs: symbols and labels for adding, removing, deleting, publishing, or fulfilling
• Attributes and states: draft, published, paid, delayed, fulfilled, or critical
• Semantic roles: informational, cautionary, destructive, selected, or inactive

At Shopify, an order was most recognizably identified by its order number. A customer could be identified through a consistent customer symbol and name. These signifiers followed the resource wherever it appeared, helping merchants recognize it across different workflows.

The vocabulary also included consistent symbols and labels for common actions, distinct treatments for static attributes and changing lifecycle states, and semantic color roles for informational, cautionary, destructive, successful, and active states.

A product’s visual vocabulary creates recognizable forms.

But vocabulary alone can’t communicate a complete thought.

In Perez-Cruz’s model, stable signs solve recognition; grammar explains how those signs relate. That dependency is what turns a collection of reusable elements into a language capable of expressing a product’s structure.

After defining the vocabulary, you need to define how to combine it into meaningful compositions.

To me, this boils down to a basic question: what do you primarily use to create structure? Shapes, lines, or space?

The combination that you use depends on what relationships and information need to be understandable at a glance.

Those might include:

• Sequential relationships: steps in a workflow, stages of delivery, or progress over time
• Linked relationships: dependencies, inputs and outputs, or causes and effects
• Nested relationships: items within orders, files within folders, or variants within products
• Comparisons: choices, performance between periods, or a value relative to a benchmark
• Movement and change: work velocity, article engagement, momentum, or growth

Grammar describes the recurring visual structures used to communicate those ideas.

Perez-Cruz’s model lets a product’s personality grow from its own logic rather than decoration laid on top.

Have you ever walked into a fast food restaurant lit with overhead fluorescent lights and knew immediately that it might be a bad idea? Or if you walk into a slightly more upscale eatery with warm, incandescent light and it immediately feels inviting?

Creative technologist Jem Gold illustrates a similar phenomenon in UI design. There are mechanical specs about pixel values and hex colors. And there are guidelines for the experiential quality of the product.

Good design absolutely talks about feeling, atmosphere, taste, mood, audience, pacing, the embodied experience of arrival. But that work gets compressed too early into machine-readable implementation language. The moment a design intent becomes a token, the temperature drops out of it.

I keep coming back to this distinction:

Object-language describes the artifact. Warm neutral palette. Elegant serif typography. Subtle texture. Soft cards. Generous spacing.

Encounter-language describes the experience of meeting the artifact. Stepping out of your car into a eucalyptus grove. The taste of the pacific air in Mendocino. Golden hour sunshine kissing your forehead. Copal smoke wafting through a mountain cabin. The page has already exhaled before you arrive. A room prepared for attention. Clarity without sterility. Intellect without deadness.

The second kind of language contains more design direction. It carries sensation, mood, pacing, social meaning, and implied structure all at once. A single sensory scene can encode color, spacing, contrast, materiality, ornament, and density without naming any of those directly.

It is precise along a different axis.

That difference becomes real once models can turn atmosphere into visual form. Encounter-language gives the model a clearer target, but you still need taste to decide whether the result feels right. Gold extends the argument from direction to judgment:

The model generates possibilities, but taste remains in the loop as judgment. Does this still feel like the intent, or did it collapse into aesthetic costume? Only after a design tastes right do you derive tokens, typography scales, spacing rules, and component behavior. If our design specs only teach the model what the interface is made of, they have already forgotten what the interface is for.

Andy Budd, Clearleft co-founder and longtime design leader, argues that AI may make design organizations smaller while making some design roles larger. His bull case is that designers who can move across product, craft, commerce, and implementation gain agency instead of getting stuck in production hell.

The best designers start to look less like traditional product designers and more like hybrid product leaders. They still care about interaction, hierarchy, language, flow, brand and craft, but they also understand the commercial shape of the problem. They can make trade-offs. They can prototype in code, or close enough to code. They can use AI to explore options quickly, then use judgment to throw most of them away. They can sit with a founder or PM and move from a vague product concern to something tangible by the end of the day.

Budd on the bear case and the danger of plausible design:

The problem is not that these people will suddenly become great designers. The problem is that many companies do not know the difference between great design and plausible design. Plausible design is dangerous. It looks coherent in a product review. It uses the right components. The spacing is fine. The copy is not embarrassing. The flow mostly works. Nobody in the meeting feels strongly enough to object. So it ships.

Budd’s point is that these outcomes can arrive together: cheaper execution can expand the role of designers while giving companies that never valued design a faster route to mediocrity.

Intent is one of my go-to coding workspaces. By default, it’s spec-driven and uses swarms of agents to execute the work, with a brainy orchestrator agent coordinating it all.

Ryan Mather, interviewing the product lead for Intent, designer-developer Amelia Wattenberger for AI Design Field Guide, asks how she designs when software behavior itself can change:

It’s a new dimension in which apps can be dynamic. We had image maps exported from Photoshop with a certain resolution, and then we were like, “wait, screens are going to be different sizes — this isn’t going to work anymore.” So we needed layout algorithms. Then users could interact and change what’s on the page — so we made them dynamic through time. Users had preferences — so we made them dynamic based on the user. And now there’s an additional dimension where even the app behavior itself can be completely changed - custom to you.

So designing now is a dance of, what are the primitives to add to the structure? Are we using bricks or another building block? And then the user can fully configure the app’s behavior, which I think is the only way to build a product now. Otherwise it’ll be stale in five months. Someone else will build a new app that does something around the workflows that people want.

Stable application chrome can provide continuity. In configurable software, Wattenberger locates that continuity in the objects people use to compose a workflow: the workspace that contains a task, the spec that humans and agents edit, and the subtasks that make delegation visible.

She describes what happens when those objects disappear:

I think about a straw that’s really bendy, and someone trying to do a thing with it — it’s just not a very powerful thing. Or clay — you can’t build super big things with clay, and you can’t go really quickly, because it’s infinitely moldable. Anything that’s generic is the jack of all trades, master of none. If you want something really powerful, you need some structure there. You need bones, you need muscles, some affordances. You can’t just be like, “oh, it’s a pile of goop, and stuff arises from the goop, that’s not what we all want.”

Mather then asks how far configurability can go. Wattenberger:

I have a feeling that applications as a paradigm will not last much longer, at least as the main way we interact with computers. Things will be way more modular and definitely decoupled from the data. There will also be a strong remix culture, because people don’t want to create everything they want from scratch, but they also want the ability to customize the things they use. So things are going to get super wacky.

OpenDoc, for example, imagined documents as containers for live, editable components supplied by different tools, rather than files owned by a single monolithic application. Computer scientists have been chasing variations of this modular model for years. AI, and the capabilities it gives users, adds a new dimension: the behavior of the application itself can now be remixed.

The startup grind is often the same: ship fast, but maintain a high bar of quality. At least that’s the sentiment. Those things are in opposition and the system incentivizes people to just move on.

Miguel Fernandez, writing for Slack Design, describes why shared standards matter:

Craft is subjective, until it isn’t. Disagreement surfaces the moment you have to define it. Is this interaction good enough? Is this component polished? Without shared standards, these discussions become battles of personal taste rather than principled decisions. You can’t argue craft in a document. You can only experience it.

That makes the quality bar a cross-functional working agreement rather than a designer’s private standard. Fernandez continues:

It seems like craft competes with velocity. Engineering and Product are often rewarded for shipping, not refining. Craft requires slowing down at key moments, which feels costly when measured against sprint commitments. The incentive systems work against craft, but this is a false trade-off: craft debt compounds just like technical debt, and eventually you pay for it in churn, reputation, and the slow erosion of what made your product special.

Fernandez then quotes Linear co-founder and CEO Karri Saarinen on the conditions beyond the individual:

“Craft is the mindset that creates quality. But it’s not enough. You need to have the right skills and ideas. You need individuals who take their profession and craft seriously, then build teams that work this way together, and have a company that creates the conditions for it. Not only incentivizing with deadlines and metrics, but also caring if the experience is good enough.”

At Apple, my boss Hiroki Asai, then the VP of Graphic Design, often gave me the same feedback: “This needs to be more considered.” Meaning, spend more time with it. Keep your quality bar high.

That memory came back while listening to Michael Riddering interview Charlie Deets, a former Safari designer now working on Dia, on Dive Club. Riddering:

It’s that extra loop and practice of consideration that I find often is the only way that I can get to simplicity.

I might have the right idea as my knee-jerk reaction. Like we put in a lot of reps, like that’s not uncommon for me. Sometimes I return back to the idea.

But then knowing that this is directionally correct, but then going through it one more time and say, “Okay, how what can I distill or cut or combine?”

Deets connects Riddering’s extra loop to Apple’s willingness to interrupt its own momentum:

Yeah, this is something I think Apple just does better than anyone else, and I think it’s partially because of sort of this one-year release cycle thing. At any point in that cycle you can say, “Is this really the right way?” And you can go back to the beginning.

And people almost are expect that disruption as part of the process. Like it’s very much part of the process to just say, “Actually we’re on the wrong path. Let’s start over from this position.”

Reopening the work also asks something of the team. Deets again:

And I think that requires a lot of confidence and it requires a lot of low ego or something.

That was Hiroki’s lesson, too. “More considered” meant that the work could be further iterated upon.

Quotes lightly edited for clarity.

Experience is usually treated as an advantage, as exemplified by Google product leader Jules Walter defining what product sense is in Lenny’s Newsletter:

Product sense is the skill of consistently being able to craft products (or make changes to existing products) that have the intended impact on their users. Product sense relies on (1) empathy to discover meaningful user needs and (2) creativity to come up with solutions that effectively address those needs.

Quoting Walter, Tanner Kohler, a researcher at Nielsen Norman Group, argues that it can become a trap when the current problem only looks familiar. He contrasts his definition of product sense with Walter’s:

Product sense is the ability to recognize when current problems match past successes or failures and reliably estimate how similar solutions will affect the desired outcomes.

[…]

This definition improves on Walter’s because it turns product sense from a loose combination of empathy and creativity into a measurable decision-making skill. It specifies the mechanism behind strong product judgment: recognizing when a current problem resembles past successes or failures, predicting likely outcomes, and knowing when those comparisons are reliable. That makes product sense easier to recognize, practice, and improve.

Pattern recognition gets most of the credit when we talk about senior judgment. For designers, calibration means knowing when a pattern that worked before no longer fits the problem in front of you.

Kohler then limits where experience can be trusted:

Our definition requires people with strong product sense to know both when an experience-based pattern is likely to work and when it is not. That judgment is the “sense.” It is not magical, does not come automatically with time, and remains limited to a person’s domain of expertise.

Consider a fire chief experienced with small building fires advising a crew during a skyscraper fire, a NICU nurse caring for an adult patient, or a chess grandmaster playing checkers. Do the cues they learned in one domain still apply?

Daniel Kahneman and Gary Klein point out that any new decision-making environment needs to provide sufficient familiar clues for an expert to accurately match the patterns they’ve learned to the current situation.

Kohler warns that AI can also interrupt the decision–implementation–measurement–reflection loop that creates those patterns:

Buzzwords come and go. There’s nothing wrong with the term “product sense.” The problem is believing that, with little data, an ever increasing velocity, and more work and decision making outsourced to AI, people can develop a “sense” for what to do without rigorous thinking.

Intuition comes with time and repeated exposure to real product decisions and results. AI may rob you of the chance to develop product sense if you aren’t careful. Stay in the ring, own your decisions, and face the results. This is what will make you valuable for years to come.

Om Prakash, writing for UX Collective, argues that chat should handle ambiguous intent rather than replace graphical interfaces:

This is a distinction Erika Hall draws precisely in Conversational Design (A Book Apart, 2018) — arguably the sharpest book written on this subject. Hall argues that conversation is the right design choice only when the system needs to negotiate meaning with the user. When the user already knows what they want — “add to cart,” “filter by price,” “submit the form” — conversation is overhead. Structure is faster, more accurate, and less exhausting. Conversation earns its place only when intent is genuinely ambiguous: when the user is exploring, when their goal is fuzzy, when they need the system to meet them partway.

This framework changes how you evaluate chat implementations in the wild. The products that figured it out early didn’t go all-in on chat. They built hybrid interfaces , structured UI for known, predictable tasks; conversational AI for open-ended, exploratory ones.

For designers, the practical choice comes before any screen or prompt: how clear is the user’s intent?

Choosing the interaction mode becomes more consequential when software can act. A form submission can usually be corrected; an agent may send an email or book a flight before the user realizes it misunderstood. Prakash shifts from intent to oversight:

The UX problem this creates is the most interesting one in our field right now: how do you design an interface for an agent that doesn’t need an interface to do its job, but whose users absolutely need one to trust it?

Ben Shneiderman, in Human-Centered AI (MIT Press, 2022), has been asking a version of this question for years. He argues that the dominant framing of AI as an autonomous agent replacing human judgment is both technically premature and ethically dangerous — and proposes instead a framework of high human control combined with high automation. Not one at the expense of the other. The goal is not to minimize human involvement; it’s to make human oversight legible, accessible, and non-burdensome. Shneiderman’s model is the right north star for agentic UX: not autonomy versus control, but autonomy with control — designed into the system from the start.

This is the transparency paradox of agentic design. An agent that operates silently is efficient and terrifying. An agent that narrates every action is trustworthy and exhausting. The design challenge is finding the right level of visibility — enough that users feel in control, not so much that they’re overwhelmed by a stream of system-generated activity logs.

Ben Callahan on what a design system can and can’t guarantee:

A design system can only raise the quality floor. It sets the baseline below which nothing should ship. An accessible-by-default button, a holistic and thoughtful approach to spacing, a template that starts a consuming team ten steps ahead.

But a design system alone can’t raise the quality ceiling. That’s not something you can do by delivering assets. The worst product teams can make awful experiences with the best design systems. That’s because the quality ceiling is set by the choices product teams make with what you give them. It’s their restraint, it’s where they push, and it’s knowing when to deviate from the standard because the standard isn’t serving the end user.

Callahan’s title invokes AI, though the essay only touches it indirectly. The connection follows from his distinction: faster generation and stronger defaults can produce more acceptable work, but neither can decide when the standard is failing the user. That decision still requires careful judgment.

Callahan on the loop:

And, of course, this loop just continues to run. Over time, the quality floor and the quality ceiling are raised.

The most important step here isn’t the shipping of a new component. It’s the time in conversation that results in alignment on a definition of quality.

Your system sets the floor. The way your system is used sets the ceiling. If you’ve poured everything into the first and bowed out of the second, it’s time to step back into ring.

Kai Wong asked 32 design leaders what they do when companies mistake faster production for faster design. He begins with a plumber:

Imagine a plumber walks into your house, looks at the pipes for a few minutes, tightens one valve, and hands you a bill for $300. Your first reaction might be, “Anybody could have turned that valve.”

Wong borrows a distinction from neuroscientist and Tiny Experiments author Anne-Laure Le Cunff: “the ancient Greeks had two words for time, not one.”

The first is chronos: time as quantity. The number of hours in a day, the number of weeks in a year. This is the time your projects are based on.

The second is kairos: time as quality. Not how much, but how good. Le Cunff frames it not just as better quality time: it’s having the time to recognize a pattern from everything you’ve seen before and know it’s the right time to act.

[…]

Design runs on Kairos. AI might have made things faster, but businesses don’t need 500 screens by lunchtime.

They need the right solution to their problem. And that comes from the quality of thinking that happens along the way.

Wong closes:

When AI is your competition, the temptation is to compete on its terms. Faster. Cheaper. More. You’ll lose that race. And you’ll produce worse work while you lose it.

Compete on the thing AI doesn’t have. Judgment.

Generation is chronos, and chronos is cheap now. Judgment is kairos, and kairos is the whole job. Protect it. Make it visible. When someone asks you to cut the timeline in half, be ready to explain clearly what they’d actually be cutting.

Wayland is a display protocol many Linux desktops use to coordinate how applications draw to the screen. Its “every frame is perfect” goal means users should see a complete, coherent image rather than partially updated output. Nikita Prokopov argues interface designers should hold transitions to the same standard:

A stated goal of Wayland is “every frame is perfect “.

And I think this is a goal we should all aspire to. Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

His screenshot test belongs in design review. Stop the transition at arbitrary points and ask why each component is where it is.

Prokopov shows how a small mismatch becomes a larger trust problem:

Not the end of the world by any means, but it does create a feeling that these two components are not in sync with each other. Next thought: maybe they weren’t designed together? If so, then they might not work well together. That’s how trust is lost.

Motion can also tell the user something happened when it didn’t:

This creates a false feeling that something subtly changes when you switch between modes. And you know what? I don’t want my UI to give me false feelings. I want it to be a precise instrument, not an animated toy.

The click-target problem is why I’m fine with macOS’s mandatory squircle. Older icons sometimes made negative space look clickable when it wasn’t. Apple’s uniform shape makes the target predictable—a small accessibility improvement worth the trade, IMHO.

Louie Mantia, writing on the Parakeet blog, explains the icon designer’s tradeoff:

Masking all of these app icons to a squircle, and even applying Liquid Glass effects to them, aims to solve this problem. And this follows the same principle of iOS 7, which is to make it easier for all apps to fit in on the platform, especially apps built by designers and developers who aren’t familiar with how to make an icon that looks great next to first-party icons.

Just so I’m clear about my preference, I would love if Apple provided a way for designers to poke outside that squircle boundary. Some of my favorite app icons did that. But also some of my least-favorite app icons ignored this shape entirely, when it was used for every system icon in the last five years. Whenever those apps showed up in my Dock, it was like a stain on my shirt I couldn’t get out.

Despite the genuine loss associated with the squircle restriction, there’s more than one way to design with it.

Mantia is right that Apple handled some older icons poorly. Designs made specifically for the pre-Tahoe squircle were shrunk and placed inside the new one, punishing designers who had followed the previous rules. But Mantia’s broader point holds. The Dock also has to accommodate neglected utilities, unmodified corporate logos, and apps whose makers never learned the platform’s conventions. The squircle makes more of them look correctly sized next to one another.

Mantia goes beyond visual consistency and describes the shape’s semantic job:

Seventeen years later, now that app icons on macOS do have a uniform rounded-square appearance, they do look better adjacent to each other in the Dock. What’s even better is that over the last 19 years, apps on Apple platforms have distinguished themselves with a very recognizable visual identity.

The shape of apps is a squircle. And it has been proven to work for everyone. Companies can use their logo as an app icon. Designers can create something specifically for the platform. And both of these get to look like an app. Whether people consider the squircle a container or a canvas, this uniform appearance communicates its function: a squircle represents an app, just like how a piece of paper represents a digital document, or a folder represents, well, a folder.

Phil Morton, who writes about product design, research, and AI, argues that design teams can’t adopt AI one designer at a time. The process only changes when design and engineering change it together:

New ways of working mean that designers and engineers have to work closely together. The ideal is that you’re in the same code repository as the engineers, not throwing a Figma file over the wall.

For most teams that’s a long way from today. Designers and developers might sit in the same squad, but they’re still siloed, with a big handover in the middle.

So when you’re trying to work out what your AI design process is going to look like, you’re not just choosing new tools for yourself. Your engineering partners have to adopt the same approach, because it makes no sense for you to work one way and them another.

The handoff is the stubborn part. A designer can learn Claude Code and still end up handing a different artifact across the same organizational boundary. Without a shared repository, components, and review process, the team has improved one person’s output while leaving the production system alone. Tool fluency helps, but it doesn’t create a shared way of working.

Morton also shows why there can’t be one standard AI workflow for every design project:

In the old way of working, the output was roughly the same whatever the project: a high-fidelity Figma file.

Now it varies wildly. If you’re assembling a feature on an established product with a mature design system, you barely need Figma at all. AI is good at using existing components and you’re not asking it to do any visual design, which it’s bad at. You can sketch the rough idea, have it assemble it and iterate. There’s little point building a pixel-perfect version by hand first.

But if you’re working on a new product which needs its own visual design or brand, it’s a different job. AI can get to a rough wireframe using generic components, then it stalls. Creative and original visual design still needs a human.

Jess Eddy starts with an advantage product designers often overlook: much of the job already involves finding unmet needs, reducing ambiguity, and giving an organization something concrete to respond to.

If you are a product or UX designer, you already hold a “wildcard” that makes you uniquely suited for this journey. Your craft and problem-solving skills align naturally with corporate innovation. Designers are natural change-makers. They’re trained to step into users’ shoes, spot unmet needs, make sense of complex problems, and imagine better ways of doing things.

In fact, design’s core human-centered methodologies: discovery, ideation, prototyping, and testing closely mirror modern lean startup practices. When you facilitate a design workshop, advocate for user research, or map user journeys, you are already embodying the role of an intrapreneur within your organization.

Your greatest advantage is your ability to make ideas tangible.

Making the idea tangible gets attention. Eddy’s test is whether the designer remains responsible long enough for that idea to create value.

In a corporate environment, the comfort of a steady paycheck can make it easy for designers to focus on work that feels innovative but doesn’t actually move the business forward. Sometimes, leaders and managers may even encourage this. “Innovation theater” is when teams prioritize appearances, like running workshops, polishing slide decks, or endlessly redesigning dashboards, without ever delivering meaningful value to users.

The real benchmark of intrapreneurship is whether your work results in products that reach customers and deliver measurable business value. The number of design sprints you run is far less important than the impact you create. To avoid the theater trap, regularly ask yourself: “What measurable outcome am I creating, changing, or improving?”

The trap is measuring the ceremony around innovation while avoiding responsibility for what ships. Eddy’s next step is business fluency:

Speaking the language of business means reframing design in terms of business outcomes. As a designer-intrapreneur, your goal is to connect design decisions to their financial or operational impact, whether that’s driving revenue, reducing costs, improving retention, accelerating time-to-market, or mitigating risk.

[…]

Strategic intrapreneurs don’t wait for a brief. They spot problems, form hypotheses, and proactively pitch solutions. To move from task execution to business experimentation, use this disciplined, business-driven formula:

“We believe [change] will result in [metric improvement] for [user group] by [amount] in [time]”.

The strategic seat comes with co-owning the result all the way through. Design artifacts are evidence along the way, never the finish line.

Dan Maccarone, founder of the product-design studio Charming Robot, recounts what changed after a year rebuilding its process around AI:

Before anyone accuses me of sneaking speed back in through the side door: the sprint is still five days, and nobody here got faster at design. What went away was the relay.

This time, we built all five states at once. Live. Interactive. Flip a toggle and watch the page rearrange itself for a logged-out stranger versus a power subscriber. Switch to mobile and it’s already there. Same five days, an order of magnitude more product. The work got deeper, and depth was the thing that, for years, blew out schedules and drove us crazy with minute details in UX and design.

This is what redesigning the factory floor looks like: not making each station faster, but removing the relay and reorganizing the work around what AI makes possible. The practical advantage is broader attention. More of the product becomes available for judgment before it hardens into implementation.

And because that documentation is generated from the prototype instead of maintained next to it, it cannot become out of date. Every change order rebuilds it. Move a state, kill a screen, rethink a flow, and the user stories, the acceptance criteria, and the error conditions regenerate to match what is actually there. You can lay the docs and the working prototype side by side and catch a contradiction in seconds, while it is still cheap to fix.

But a prototype can preserve the current answer without preserving the reason for it. Maccarone’s experience brief keeps that responsibility on the human side of the workflow.

The one that’s really going to hurt you is much more subtle and is rarely communicated. It’s the why. Why this flow and not that one. Why this default, this state, this tradeoff. The AI never writes that part down, because the AI never had a reason in the first place.

Because AI is so good at producing a confident, finished-looking deliverable, the temptation is to let the prototype become the spec, to let the thing that looks done stand in for the thinking that was supposed to happen first.

Patrick Neeman is making an argument I’ve returned to repeatedly: as AI makes production cheap, designers’ value shifts toward judgment—knowing what good looks like, choosing the right problems, and owning the outcomes. I’ve called this the orchestrator gap: agents execute; judgment stays human. Neeman extends that argument by locating craft itself in that judgment, without pretending execution no longer matters.

The production layer — the wireframe, the boilerplate, the competent first draft of a screen — is collapsing toward free, which changes our own perceived value proposition.

When making gets cheap, much of what you called craft turns out to be production wearing craft’s clothes. What survives is the part that was never about the file: choosing the right problem and owning the outcome it moves. Not a loss but a relocation you can get ahead of. Here is where craft goes.

Craft is not decoration on the product. It is part of what makes the product worth trusting.

When a tool can generate a thousand plausible screens before lunch, the scarce skill is no longer making one; it is knowing which one deserves to exist. That skill has a name, taste, and most people have been outsourcing it to whoever runs the critique.

None of this means polish stops mattering. It means polish is table stakes, not the differentiator. The differentiator is the judgment that points all that cheap production at a problem worth solving in the first place.

That judgment is also what earns trust. Users never see your process, but they feel its absence. A product built on the right calls feels coherent and reliable, and reliability is what brings people back; one built on plausible guesses feels off in ways people cannot name and do not forgive.

Neeman on teaching that judgment to a machine:

Most craft is tacit. You know a layout is wrong before you can explain why. You feel that a flow has one screen too many. Michael Polanyi named this decades ago: we know more than we can tell.

Your taste lives mostly below the waterline of language, in pattern recognition you built over years and never had to state, because your own hands did the work. That gap is harmless when you do the work yourself. It becomes the whole problem the moment you hand the work to a machine.

Point a model at a vague brief and it fills the silence with its own defaults, which is the average of everything it has seen. Average is exactly what craft is supposed to beat.

I agree with Neeman: writing the standard requires the same judgment the standard is meant to preserve.

Emily Campbell, designer and writer, on AI’s position in the design stack:

AI asks designers to go one layer deeper again: into the model, the harness, the context, the policies, and the emergent behaviors that produce the experience before it ever reaches the interface.

Jesse James Garrett’s The Elements of User Experience asked designers to look past the surface layer they owned. Jamie Mill’s The Elements of Product Design asked them to look past the product and into the conditions around it. Campbell maps the next step in that arc with a six-layer architecture: User Interface, Context, Harness, Model, Governance, Emergence.

We cannot control for every outcome directly through the interface, but we can design the conditions that shape a model’s generation. In that regard, the work of design looks less like specifying every expected state, as Garrett’s model encouraged, and instead closer resembles system design, identifying and manipulating the leverage points in a system that exist in the layers below the surface.

Of the six layers, governance puts designers in the least comfortable position. The rules that shape AI behavior often come from legal, compliance, security, and executive choices before the interface team ever sees them. When that reasoning is not documented for the people designing the experience, assumptions pile up and harden into product behavior. Campbell’s conclusion is about fluency, not ownership:

The expectation going forward should not be that every designer works across every layer. Full-stack AI designers need to have a general fluency across all inputs into the experience, so they can influence, mitigate, or receive the impacts that upstream work has on the end experience.

[…] Technical designers are more likely to focus on the Model, Harness, and Context levels, and the role is more than just “design engineer”. Other designers may focus further down the stack, as we might see design-specific titles pop up in policy making and emergent research (these roles exist today, under titles like “business designer”, but have not reached critical mass within the industry). And of course, classical design will remain, but its workflows, tools, and outputs will evolve.

Marina Krutchinsky, the writer behind UX Mentor Diaries, spots the part designers tend to miss: they have internalized the belief that design work is secondary unless someone else translates it into business language.

Here’s the thing: most executives don’t understand what design is.

To them, designers are the people who make things pretty after the real decisions get made.

And every time you present your work in design language, you confirm that belief.

Her client had just shipped a checkout redesign that cut abandonment by 35%. Real work, invisible to the CFO who walked past her in the hallway. Three slides changed the conversation:

“Our checkout flow was losing $1.2M annually in abandoned carts.”

“We identified 3 friction points and redesigned the payment experience.”

“We recovered $840K in the first two quarters. Projected $1.4M annually.”

That’s it. 3 slides. Maybe 45 seconds of talking.

The CFO asked her to stay after the meeting. First real conversation they’d ever had.

Krutchinsky’s three-part structure is familiar: name the leak, name the intervention, name the result. The sharper move is the business-language translation that follows:

CFOs don’t care about usability scores. They care about margin, revenue, and risk.

When you connect your work to those things, you stop being “the design person” and start being someone who solves expensive problems.

That imbalance will not fix itself. Designers already know the first language: usability, friction, flows, trust. The second one is finance’s language: margin, revenue, risk, and the expensive problems design actually solves.

Wouter de Bres built a free online book about psychology for designers. Forty chapters, organized around four areas: the people you design for, the interface you put in front of them, your own cognition while designing, and the organization that can override all of it before you ship. The introduction explains why he made the site:

Every decision you make as a designer is a claim about how a person will think, feel, or behave. Where you put a button is a claim about where people look. What you show on an empty state is a claim about what people need when they feel lost. Whether you use a progress bar is a claim about how people experience effort. You make these claims every day. The only question is whether you make them with understanding of how people actually think and work, or just with a gut feeling and a deadline.

That is the useful provocation: design is already full of behavioral claims, even when nobody names them that way. Chapter 14 goes after “intuitive”:

“Intuitive” is one of the slipperiest words in a design review. Designers say it all the time and nobody pushes back because it sounds like evidence. Usually it is not. Most of the time it is just a description of how familiar the designer feels with the thing they made, and that is a weak way to judge whether it will work for someone else.

Most of the time, intuitive just means familiar.

That chapter is the internal trap: designers can mistake their fluency for the user’s. Chapter 27 is the external version of the same problem, where teams underestimate how expensive it is for users to leave an existing routine:

This is what teams underestimate when they say users are irrational for sticking with a worse tool. They are not running a fresh comparison every morning. They are moving inside a routine that already became cheap to repeat. Less thought. Less searching. Less risk. Your product may be better once it is learned. The old one is better at 9:03 a.m. on a busy Tuesday.

A lot of product strategy gets built around the wrong moment. Teams compare tools in a calm demo state. Users switch in the middle of real work, with deadlines, interruptions, and habits already in motion.

The two chapters work well together because they correct the same designer bias from opposite sides. Inside the team, “intuitive” often means “familiar to us.” Outside the team, a worse incumbent can still win because it is familiar to the user. The design implication is brutal but useful: better is not enough. The experience has to be easier to understand, easier to try, and cheaper to switch into during real work.

We haven’t talked too much about AI and e-commerce here on this blog, but as much as any other area in our digital life, AI agents will change how we shop online.

Elizabeth Pizzuti, writing on the Automattic Design blog, explains the two definitions for how “agent” can be used in the e-commerce context.

The word “agent” is overloaded in 2026 commerce.

Two unrelated things share it:

1. Agentic commerce: AI shoppers buying from stores.
2. Agentic merchant operations: AI workers operating for the merchant.

The distinction matters because the two sides ask designers to make different things legible. On the machine-buyer side, Pizzuti’s first principle is basically agent readiness applied to commerce:

AI agents don’t browse websites like humans, they read structured data from the backend. Considerations here include providing an “AI readiness” score or dashboard for a clear, visual indicator of product catalog health, and a preview of how the AI agent sees that data. This demystifies the structure and allows the merchant to see exactly what an algorithm is evaluating. Additionally, make sure that context is part of the catalog—blog posts, buying guides, FAQs, and reviews all determine sentiment and trust and should be linked to the product schema.

For merchant-side coworkers, the problem flips. The interface is there to help a human judge whether the system did the right work. Pizzuti on the interface merchants use to judge and approve the agent’s work:

Designing for trust means exposing the agent’s backend homework. A merchant will never click “Approve” out of blind faith, especially in high-risk areas like pricing or inventory replenishment. Every automated recommendation must include the underlying context and trigger. Instead of “Drop price of item X by 10%”, the UI should show the reasoning chain:

• Observation: Competitor price drop detected.
  • Impact: Your listing’s conversion rate fell by 14% over the last 48 hours.
  • Reasoning: Lowering the price by 10% restores your competitiveness while preserving an 18% net margin.

That’s the right design shape for AI coworkers: controllable over perfect, with proof of work, a visible undo path, and enough context for the merchant to approve the change without pretending the system is magic.

Tiina Golub, writing in UX Collective, points at the right version of “personalization” for enterprise software:

I have spent most of my career working on the large-scale computer programs designed to operate and automate complex business processes for big organisations, known as enterprise software. Due to their size and complexity, these products are often slow to innovate, relying on outdated usability principles and legacy systems long after the rest of the industry has moved on. However, recent technological advances (yes, I’m mostly talking about AI) have both enabled and compelled them to evolve at an unprecedented pace. No one can tell for sure what the future will look like, but there are some clear trends reshaping the user experience of enterprise software right now.

The interesting part is not that enterprise tools should start feeling like consumer apps. That usually leads to dashboards with the user’s name on them and a recommendation panel nobody asked for. The better version is software that understands the work well enough to reduce how much process the user has to remember.

That makes AI less useful as a standalone feature and more useful as embedded guidance:

No longer a stand-alone feature, AI is increasingly woven into the fabric of the interface, deeply embedded into every workflow, and offering contextual guidance right when the user needs it.

That is the useful frame: enterprise personalization is not taste. It is role, permission, workflow state, and organizational context. The product gets “personal” when it knows what kind of decision the user is trying to make, what constraints surround that decision, and what help belongs at that exact moment.