373 posts tagged with “product design”

Lightspark’s chief design officer Geoff Teehan, writing in Design Field Notes, traces the work that comes with adding a UI control:

By details, I don’t just mean the small visual decisions. Every feature, control, mode, state, exception, and bit of behavior becomes something a team has to design and someone has to understand. There’s only so much attention to go around. Same for time, taste, and patience.

A button seems harmless enough, but someone has to decide where it goes, what it says, what it looks like, what happens when you press it, what happens when you can’t, and what happens after you do. Add another and now you don’t just have two buttons. You have the relationship between them.

Teehan’s examples distinguish reducing that work from simply hiding controls. Teenage Engineering’s gorgeous OP-1 combines a synthesizer, sampler, sequencer, recorder, and mixer. It still takes practice to use. But its four colored knobs correspond to colors on the screen, giving the musician a consistent way to make adjustments across different functions. The colors do a job here. Removing them to make the instrument look simpler would undermine the relationship Teehan describes.

He closes with what a team can do when it has fewer details to maintain:

Removing something gives you time back. Time to reconsider the typography, rewrite three words, make an interaction feel right, move something two pixels, tune the sound, or notice what becomes annoying after the twentieth use.

Most people won’t notice any of it. Fine. They shouldn’t have to.

Minimalism isn’t the point. You can make something sparse and still make it bad. The goal isn’t to have the fewest things. It’s to have few enough things that you can care deeply about every one of them.

Peter Merholz, who has urged design leaders to connect their work to what the business values, is reconsidering that advice. A company can track the screens a team produces while overlooking the exploration that helped it choose what to build. That’s what he means by design’s “legibility gap.” He explains why predictable work gets recognized:

This is not some fault of design, but instead reflects the values of business operations. Organizations value predictability, so that they can plan, budget, and communicate likely outcomes to their stakeholders. Predictability requires determinacy, where the nature of the work (its processes and outputs) are understood ahead of time—engineering will take 6 weeks to work through these Jira tickets; marketing will spend $50,000 to draw this amount of traffic. Determinacy in turn defines legibility, the qualities of work that can be seen, appreciated, valued, and accounted for.

Much of UX/Design work is indeterminate, and thus illegible. Examples include:

• You explore four concepts and choose one. The three abandoned efforts are invisible, and you’re asked why you didn’t just start with the workable one.
• Research reveals the requirements were misguided, so you reframe them around actual customer need. The roadmap retains the same name, so it appears nothing has changed.
• You draft the experience principles that will inform hundreds of downstream decisions, but none of which will be traced back to them.

I’ve supported connecting design work to an existing metric, with the qualification that a number can’t capture everything design work contributes. Here, he’s reconsidering whether the business’s existing criteria are sufficient.

His warning comes from a forestry example: in Merholz’s account, clearing a forest for timber production destroyed the undergrowth and other life that sustained it. The first generation flourished, but the next collapsed. He applies that warning to design leadership:

This legibility frame illuminates a potent detail that had escaped me. Where in the past I argued that design leadership is about translation and connection (I have used the phrase “connect design to what the business values” countless times), the real work is subtler and actually much more difficult.

If we want UX/Design to avoid the fate of the forest’s second generation, the real work of leadership is to evolve what businesses see as ‘legible.’ We need them to widen their aperture to appreciate the value of indeterminate work, which is open-ended, exploratory, emotional, meaningful, even beautiful.

Merholz leaves the practical question open: how does a leader persuade the business to support exploration whose result can’t be specified in advance? An existing metric gives that conversation a starting point, but it can’t settle which unmeasured work deserves support.

And it’s a question that I personally continue to grapple with.

The apps are still there. Just a step away, hidden. You ask an AI personal agent to move an appointment or cancel a subscription, and it handles the software for you. Writing in Design + AI, Felix Haas describes what happens to the products that are hidden away:

Watching this happen has clarified something I’ve been thinking about for a while. We are witnessing a new step being inserted in front of every interface we’ve ever designed. In the last years, using software meant going to the software, opening the app, learning its layout, and navigating its particular logic. Now you increasingly interact with one interface that is connected to all the other interfaces, and the moment that layer works well enough, the interfaces behind it begin to fade from view. They don’t fade because they got worse, but because nobody is looking at them anymore.

That is what an invisible interface actually means to me, and it has nothing to do with minimalism or fewer buttons. It means that the interface of the product you built, the thing your team obsessed over and tested and polished for years, basically becomes a back-end, and its primary user is no longer a person but an agent acting on a person’s behalf.

Haas gives the underlying service a design requirement of its own: make its capabilities and current state understandable to the agent. Then he turns to the person delegating the task. They may skip the app’s navigation, but the agent now has access to their money and messages. That makes the handoff back to the person consequential:

So how do you design for trust when there is no interface to carry it? I believe it lives in three places. It lives in how the agent communicates, in its tone, its honesty, and its restraint, in whether it admits what it doesn’t know and asks before it assumes, because every sentence is now a design decision and the conversation itself becomes the brand. It lives in how you show what is happening on the other side, not through a wall of logs but through a considered kind of transparency, the reassuring feeling that the machine’s work is visible whenever you care to look. And it lives in the approval moment, that brief flash where an interface does appear right before an action is taken, carrying exactly enough context for a confident yes or no. As the interface shrinks, that moment becomes one of the highest-craft surfaces in all of software, because the fewer pixels that remain, the more each one weighs.

A cyberpunk toy-robot landing page gives Nick Babich a test case for the Design plugin in Claude Code. Writing for UX Planet, he starts with /design:design-critique this design, then uses the findings to request changes:

And the nice thing about doing a critique in Claude Code is that you can use a report that AI generated for you as an input. You can provide a follow-up prompt asking AI to fix the issues it found for you.

He narrows the next pass to the primary button with /design:ux-copy primary call to action button:

The great thing about Claude is that it has a project context. It means that it can use the knowledge it has about this particular product and business to find the right words.

Similar to the previous task, Claude generated a nice report with suggested text labels. I can also prompt Claude to change the call-to-action button text to the first option it suggests (Reserve a unit).

I’d check what the button actually commits the customer to before accepting that suggestion. A reservation is a specific promise, and the copy needs to match what happens after clicking.

Babich finishes with /design:design-handoff this design and a warning about what goes to engineering:

Similar to an AI-generated design critique, it’s not a good idea to use a design handoff file as-is without any changes. You need to review the file, validate the information in it, and only after that send it to the dev team.

Take ownership of what the AI generates.

Design educator Michael Buckley, writing for UX Collective, asks design schools to reconsider how they recruit students. He starts with what happens when those students get to class:

I see the mismatch most clearly when students reach the parts of a project that precede the visual work. They may be eager to design screens but impatient with research, resistant to technical constraints, or inclined to treat strategy as documentation to complete before the real design begins. Technology is sometimes learned well enough to operate but not well enough to question.

These reactions are not simply failures of effort. Many students entered the field expecting a professional outlet for artistic creativity. A discipline increasingly concerned with behavior, systems, evidence, and consequences can feel like a change in the terms of that promise.

An interest in making beautiful work is a good reason to study design. But students also need to learn strategic and systems thinking. The school owes them a description of the profession that makes those expectations clear. They shouldn’t have to discover the difference after they’ve enrolled.

Buckley brings the question back to recruitment and admissions:

Changing the curriculum without changing the recruitment pitch leaves that mismatch intact. Programs that present design primarily as a practical outlet for creativity will attract students who expect creative expression to organize the profession. Their frustration is understandable when the education they encounter reflects the realities of contemporary design rather than the false expectations that brought them to the field.

Design programs should therefore reconsider what they advertise and what they evaluate during admissions. A visual portfolio can remain part of the process without serving as the only meaningful evidence of potential. Applicants could also explain how they understood a problem, considered conflicting needs, or changed a decision after encountering new evidence. An imperfect artifact supported by thoughtful reasoning may reveal more than a polished portfolio organized around personal style.

Candace Wilson and her design team wanted engineers to reuse the code from their AI-assisted prototypes. The goal was to preserve details that can get lost when someone rebuilds a design. Writing for Bootcamp, she describes what happened at handoff:

By the time development picked up the prototype, something that looked almost finished on the surface could still be difficult to use as a starting point. We had pages that had grown into thousands of lines of code, unclear component boundaries, and sometimes implementations that didn’t match the design intent. A responsive experience, for example, could end up built more like separate adaptive layouts. In trying to reduce the visual handoff gap, we had sometimes created a different problem: an architectural handoff gap. Development then had to interpret, separate, refactor, or rebuild that work before it fit the production environment. Design had moved faster, but some of that effort had simply moved downstream.

This is the double-edged sword with designers using AI to write code. It looks done or good enough to us, but in reality, the generated code might be hiding a bunch of tech debt.

She allows for looser code when the prototype is disposable. For code another team is expected to build on, she proposes a different standard:

Prototype code does not need to be production-ready, but it should be production-useful.

For the kind of handoff I am talking about, that means the code should be structured well enough that development can extract from it without first untangling the entire thing. Component boundaries should be clear. Reusable pieces should actually be reusable. Responsive behavior should match the design intent. The prototype does not need to mirror the production codebase exactly, but it should be close enough that the handoff preserves some of the speed we gained by building in code in the first place.

I joined Jason Giles on UserTesting’s Insights Unlocked podcast to talk about AI and product design. The trust discussion drew on a story from BuildOps, where our customer base is commercial contractors. From UserTesting’s episode write-up:

When Roger’s team spoke with technicians about ambitious AI capabilities, the initial response was decidedly practical.

“Just give us the basics first,” Roger recalled hearing. “Just make sure the app is reliable and it’s speedy and we can do what we do.”

Only after those needs were addressed did the conversation shift. When the team described an AI experience that could reduce tedious end-of-day typing, technicians saw the value.

That request for reliability was entirely compatible with wanting to get work done faster. Technicians were spending 10–20 minutes on job notes in their trucks after a day of hard, often sweaty physical work. When my team spoke with technicians, a feature idea came out of it:

From that customer research came an AI feature called Visit Summaries. Instead of typing everything, technicians can press a prominent microphone button and talk. AI cleans up the account and incorporates relevant context about the property, equipment, parts used, and so forth.

The sequence matters. The team did not begin with AI and search for somewhere to wedge it in. It began with observing a person experiencing friction and then finding a way AI could help.

When customers ask us to fix the basics, we should treat that as guidance for what to build next, including with AI.

It took Marek Minor about a year to redraw Cursor’s icon system: more than 600 icons in two sizes and two styles, with every exploration and final variant drawn by hand.

The scale only hints at the effort. Minor tested differences as small as 0.25 pixels, made 156 explorations of the hamburger icon, and tracked more than 155 recurring elements and visual properties. He also built the Figma files, migration dashboard, companion site, and release pipeline needed to migrate an old font with 645 codepoints without breaking references. Writing on his blog, he explains the construction method that holds the set together:

The icons in this set are closer to technical drawings than to organic shapes – diagrams with a friendly finish. The construction method is consistent across the set: start with lines that run horizontally, vertically, or at 45°, allow other angles where the concept demands them, then round the corners until the shape follows the idea. A cloud, for example, isn’t built from circles. It starts as straight segments that get rounded joins. A fire icon is built the same way, from angled segments with rounded corners. Freeform curves, or curves taken from circles, are extremely rare in the set.

This construction logic is what makes 600+ icons feel like the work of one hand. It also suits a coding tool: precise and engineered, with the rounded corners and round stroke caps keeping it from turning cold.

Patrick Morgan, writing in his newsletter Unknown Arts, starts with the boundary his system is designed around:

The problem is that prototype code and production code serve fundamentally different purposes. Production code needs to optimize for shipping and maintaining a performant product at scale while prototype code needs to optimize for speed, flexibility, and divergence. I wrote more about this distinction in my article Prototype Code Is Not Production Code (And That’s Okay).

You need both sides of that spectrum to design and ship a good product. A prototype should be able to change direction quickly, without worrying about scale or production constraints, while still benefiting from shared foundations, reusable primitives, and a connection to the product it may influence. So I started looking for an environment with the freedom of a prototype, but enough shared structure for the work to compound over time.

Morgan argues for giving exploratory code enough shared structure that designers can move quickly without severing each experiment from what the team already knows.

As more people used the environment, I started curating more of the context around the work directly into it, including our design principles, personas, and project briefs. As I wrote in AI Needs a Plan, the best agent work usually starts with a written brief, not a one-shot prompt.

By then, the environment had grown from a place to make prototypes into a shared foundation of tools and context that helps people and agents understand how our team designs.

In Morgan’s account, the prototype is not the only thing that compounds. The team’s principles, personas, briefs, foundations, and prior decisions do too, because people and agents can reach them from the same working environment. That shared home is the Design OS: a codebase separate from production where people and agents can reuse the team’s context instead of starting each prototype from scratch.

A codebase gives the Design OS somewhere to live. It lets design intent be shared, connected to other assets, and put into practice.

That has always been possible in theory, but until recently code wasn’t very accessible to designers. Agents change that dynamic by acting as translators into and out of code. They can turn a designer’s plain-English intent into working software, then translate that software back into something the designer can use and evaluate.

This builds on the argument I made in AI Runs on Text. So Should You.: when your thinking lives in plain text, it becomes an asset that both you and AI can read, reuse, and extend. Code just happens to be a more structured form of plain text, which makes it easier for agents to interpret and act on reliably.

The goal here is not to make designers write code. It’s to make design intent executable. When a codebase holds the team’s foundations, conventions, and decisions, an agent can translate a designer’s instructions into working artifacts and carry that context forward. Each new piece of work can then build on what came before it.

Adam Waxman built five personal tools using his household’s rules and data from several apps. Most work the same way:

Aggregate data, add an LLM. The cost drop doesn’t just mean more apps, it means apps can be far more personal. Most of mine follow the same shape: pull data from multiple sources, combine it in one place, and use an LLM to generate insights from the full picture. My fitness app combines nutrition, sleep, weight, and training data that lives in four separate apps, then uses that context to make recommendations none of them could alone. I think this pattern will spread to professional tools too.

Two more lessons:

Ephemeral is fine. We used the sleep app for about four months. Our son sleeps through the night now, so we retired it. If the app had taken me months to build, that might sting. Because it took a week, I’m just glad it worked when we needed it.

AI floods big markets and unlocks small ones. Yes, AI produces endless derivative apps. But the same tools also let me build apps for my household that no company would bother making. Beyond my household, I built nycjazz.guide for NYC jazz fans and claudecodedaily.com for Claude Code developers, audiences too small for a business but worth serving.

These fleeting micro-apps change what is worth designing. An app no longer needs a large market or a long life to be useful. They also avoid the customer adoption problem Andy Budd describes: Waxman starts with one household and one problem, not a market he has to win over.

These personal apps depend on other products letting people use their data:

Good APIs matter more than ever. I switched from Cronometer to FatSecret because FatSecret had a better API. My fitness app pulls from Strava, Oura, Withings, and FatSecret, and the quality of each integration depends on how well the API is designed. As more people build personal software, users will expect their apps to have APIs and MCPs worth connecting to.

Designers now need to ask whether people can get their data out. If a service keeps that data locked inside, people can’t use it to build tools that fit their own lives.

I’ve always been more interested in making something than selling it. That instinct serves the craft, but it can be dangerous for the business. Building offers control and a concrete result; earning customer trust and adoption requires getting out of that comfort zone.

Andy Budd, who has spent the past five years working with early-stage founders, describes the handoff:

Founders often assume that once they’ve built something significantly better, the hardest part is behind them. In reality, once the fun product-shaping bit is done, a different kind of work starts.

You have to get strangers to care. You have to explain the problem repeatedly without becoming boring, show the product, make videos, write posts, go to events, ask customers for introductions and follow up with people who didn’t reply. You have to sit through sales calls where somebody spends 25 minutes explaining their procurement process, and hear “this looks great, come back next year” over and over again.

Making the product better can become a way to avoid selling it.

So they retreat to where they feel useful.

They decide the onboarding needs improving. They rebuild the dashboard. They add the feature three prospects mentioned. They convince themselves that sales are slow because the product isn’t quite good enough yet and that one more release will finally make the market pay attention.

Sometimes they’re right. But often they’re polishing the product because polishing the product feels like progress, while trying to persuade people to change deeply embedded behaviour mostly gives you rejection, indifference and unanswered emails.

Arin Bhowmick, SAP’s chief design officer, shifts the software-death debate from apps to operating context. Rather than treating the model’s capabilities as the whole story, he asks where enterprise software’s enduring value actually sits:

Despite the cliché premise, I found it insightful, an honest take from one of the “Big Four” on AI and SaaS. In it, PwC’s TMT leader Dallas Dolen says enterprise software isn’t dead. His clients are redirecting their software budgets toward AI, and the systems going in on top of the stack they already run, keeping what runs the business and building the intelligence on top. They are betting that the value sits in what they have spent years assembling.

There’s a good reason for that. An AI model can answer almost anything, but on its own, it knows nothing about your company: how it runs, which data to trust, what it is allowed to touch…

The model is the “cheap” part, while the expensive one is the business knowledge around it, the processes, exceptions and rules a company encodes over decades. That context provided by software is what makes an AI agent useful.

The existing stack becomes the policy layer for whatever intelligence sits above it. That context determines more than what the agent knows. It sets the boundaries of action: when the system can proceed, when a person must approve, what happens when the evidence conflicts, and who is accountable afterward. Bhowmick turns those boundaries into the design brief:

Once design “owns” the judgment a system applies on its own, a new set of questions lands on every designer’s desk:

• When should an agent act?
• When should it stop and ask first?
• What does it show before it does something it can’t undo?
• When it isn’t sure, does it say so, or hand you a confident guess?
• When it gets something wrong, who answers for it?
• How does a person take back control when they need to?

Often, the most useful move an agent can make is to admit when it’s unsure and hand the decision back. We have to design that handoff so it feels natural. If it reads as the software confessing a mistake, people lose trust.

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.