241 posts tagged with “user experience”

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.

Jakob Nielsen’s AI-generated illustrations do his work no favors. His visual taste is, to put it kindly, not mine. But Jakob Nielsen has done something few technology forecasters ever do: he pulled out papers from 1993 and 1996, scored 23 predictions against computing in 2026, and published the misses alongside the hits.

The 71% headline is Nielsen’s own grade, and he acknowledges the obvious conflict:

Two clarifications. First, timing gets no separate penalty because the delay affects nearly every row. Neither paper promised a full system within a decade; Noncommand explicitly said such a system was unlikely “within the next ten years, which is about as far as one can predict in the computer field with a minimum of credibility.” The vision nonetheless took 30 years to become a widely shipped product pattern, a delay I return to in the lessons.

Second, I’m grading my own homework, which is an obvious conflict of interest. I’ve tried to score against what shipped and stuck, not against what demos well, and I show every score so you can regrade me.

So I wouldn’t get hung up on whether 71% is exactly right. Nielsen and his late co-author, computer scientist Don Gentner, still saw an intent-driven interface decades before machine learning made one practical. Some of the details are uncanny; others reveal how a sound principle can survive the failure of its original mechanism.

Nielsen on one of those switcheroos:

In 1993, I described moving an on-screen object “by selecting it by looking at it and then pressing a selection button (to prevent accidental selection).” In February 2024, Apple shipped Vision Pro with the same core selection pattern: look at a target, then pinch to commit. The prediction reappeared three decades later with its confirmation step intact. Of course, the Vision Pro remains a niche product, which is why the bandwidth and interaction-stream rows score in the middle of the scale: the high-bandwidth immersive future arrived, but as a sideshow. The main stage went to the lowest-bandwidth input device imaginable: an empty text field.

The physical channel narrowed while the semantic channel widened. Our mistake was measuring the interface by how much raw data crossed it rather than by how much work each user token could trigger. The better metric for AI is intent leverage: useful output divided by the effort required to specify the goal.

And this 1996 sentence comes remarkably close to describing the interface designers should be building beyond the prompt box:

We assumed users already knew what they wanted and just needed a better way to say it. Conversational AI revealed that human intent is rarely a pre-formed cognitive object just waiting to be translated; rather, intent is fluid and often discovers itself through the act of conversation. Current AI user interfaces do little to help users figure out their intent, but even primitive AI UX already supports some degree of iterative co-articulation.

One sentence from 1996 aged better than everything else Don and I wrote: “Real expressive power comes from the combination of language, examples, and pointing.” That’s a working definition of multimodal prompting: type your intent, paste an example of what you want, and point by uploading an image or selecting a region. If I could grade a single sentence at 100%, this is the one.

Language is best for leaping across a large solution space: “make this calmer,” “compare these contracts,” or “plan a week in Kyoto.” Pointing is best for local correction: this paragraph, that number, the face in the upper-right corner. Examples communicate qualities users can’t easily name. The winning AI interface will therefore let language propose, examples constrain, and pointing repair.

Nielsen and Gentner’s prediction worked because the underlying idea was stronger than the technologies they had available. They got the vehicle and timing wrong. They also expected expert users to benefit most. Yet language, examples, and pointing still sound like a better creative interface than an empty text field.

Pick one metric on your team’s dashboard. What decision would change if it moved?

Ant Murphy offers two questions for finding out:

Two of my favourite questions to ask about any product metric are:

1. What are you trying to learn?

2. What change will you make as a result?

There are thousands of things you can measure, but measuring for measurement’s sake isn’t helpful. It needs to drive decisions.

The second question puts a team on the hook before the data arrives. It forces the decision rule into the open, when there’s less temptation to rationalize whatever the chart happens to show.

Murphy also argues that difficulty assembling a metric can be evidence that the team has stopped settling for whatever its analytics tool already exposes:

And that’s the trap that Ridgway was describing all those years ago and it’s still relevant today.

So I see friction as a good sign - it means the metric is:

• Unique: specific to your product and your problem, not pulled off the analytics shelf
• Meaningful: tied to the behaviour change you actually care about
• And thought through: you’ve actually unpacked what you’re trying to learn

So it’s worth pushing through the friction. I’ll take a meaningful proxy, or a smaller sample of something high-quality, over a generic metric every time.

Lola Famulegun, writing for Nielsen Norman Group, separates the UX metrics that describe design performance from the business metrics executives use to judge an investment:

Upstream metrics tell you how the design performed. Examples include task success rates, error rates, SUS scores.

Downstream metrics capture what changed in the business as a result. Examples include support contact volume, conversion rates, and churn.

Downstream metrics tell you what the work was worth. You don’t need to abandon the metrics you already collect, but you do need to build a bridge from them to the ones leadership tracks. The table below maps common upstream metrics to the business priorities they most directly connect to, with a suggested framing for each.

Famulegun also points out that the translation depends on access to data outside the UX team. I recall that my team had to fight with my company’s revenue operations team to get access to Salesforce data so we could make prioritization decisions with ARR as an input.

Famulegun:

The data you need already exists inside your organization. Partner with finance, product analytics, customer support, or marketing to understand what they track and to get access to before-and-after data for flows you’ve redesigned. Even directional data is persuasive when it’s honest: “Contacts about [feature] dropped 30% in the quarter following the navigation change.”

A practical note: this translation only works if you have access to downstream data. If your team isn’t currently connected to product analytics, customer support, or finance reporting, that’s the first conversation to have.

The goal isn’t to overstate what UX delivers. It’s to surface the connection that already exists between the work your team does and the numbers the business is tracking.

After Addy Osmani’s introduction to loop engineering, Robert Ross, writing at The Thought Drop, opens up the machinery. What looks like one agent loop is really three nested loops:

Agent loops are often oversimplified. They’re presented as a single loop, when really it’s three loops in a trench coat that make up an “agentic” experience for a customer. I’m here to write (yes, I wrote this, insane right?) yet-another-blog about agent loops. The example code blocks are also pseudo-code and for illustrating these ideas. Also I’ve omitted streaming, which complicates the post but the shape of these stays the same.

Those are the inference loop, which manages model calls and conversation history; the tool loop, which turns model output into actions; and the human loop, which approves, rejects, or redirects consequential work.

Ross’s “brain in a jar” analogy explains why the tool loop changes a model into an agent:

LLMs are brains in a jar. They provide no functional value on their own. The tools you give an LLM are what make it an agent.

When you tell a model “here are the tools you have” in your outer inference loop, the model may try to “use” them in its inference (response). This is the same thing as a brain sending an electrical signal telling your index finger to hover over the enter key of the email you desperately want to send Laney. Tom, we need to set boundaries my man.

The separate tool definitions you include in your API request are usually serialized into the system prompt field of the token stream the model processes. And it may infer the usage of multiple tools in one turn. (Hence: Tool Loop).

The human loop is the final layer—and the hardest to build:

The Human Loop is arguably the hardest part to implement in agentic systems. You can’t have a piece of code block for hours. What if the server restarts? What if you have thousands of other requests coming in you need to respond to? The first two loops (inference and tool) are simple enough. The human loop ups the ante of difficulty. This is why durable execution frameworks exist, like Temporal.

But the human loop is necessary, because it’s the only thing stopping Tom from actually sending that message to Laney. IT WAS TWO YEARS AGO TOM, MOVE ON!

Marcin Wichary, author of Shift Happens and the Unsung essays on software craft, has been cataloging how software fails our hands for years. This new 7,700-word interactive essay has 38 live playgrounds that let you feel the argument in your fingers rather than just read about it.

Wichary’s central argument is that software keeps rediscovering a century of research into how hands actually work: overlapping keystrokes, motor memory, spring-loaded modes, dead zones. For designers, the lesson is that responsiveness at finger scale is not polish. When an interface blocks or delays the narrow timing window our hands rely on, it breaks motor memory and flow.

It turns out, fingers are time travellers. At any given moment, each one is living in a slightly different time – as one finger is moving down to press a key, another is already travelling to the next one, and your brain is thinking of a few keys in advance, visualizing your hands moving to the right place.

[…]

None of this requires touch typing. What we eventually called overlapping happens even if you reside at the awkward intersection of “hunt” and “peck.” Overlapping is a small miracle happening in front of your eyes, and it happens pretty much to everyone.

A capability of our hands and brains to treat our fingers relatively independently, and allow them to move at their own pace without waiting for other fingers (on the same hand) to finish.

The essay walks from 1960s terminal echo buffers through Chrome’s reload-button disabling trick to the moment iOS broke cardinal contracts of programming for the sake of scroll:

[…] competitors reportedly recorded the interactions with a high-speed camera to confirm they were, indeed, running at a constant 60fps.

[…]

iOS stopped running my code in the middle of a function just so it could go back to making sure scrolling was as smooth as possible. No modern programming language would ever dare interrupting your function halfway through; iOS was so dedicated to its user’s fingers that it broke cardinal contracts of programming.

That commitment, prioritizing fingers over execution contracts, is the standard Wichary is asking us to hold in design crits. He closes by turning delight away from decoration and toward restraint:

Sometimes they say that confidence is absence of confidence. […]

In a same way, I think often delight is absence of delight. In places and apps that welcome fast fingers, delight can be abstaining from a transition or something cute but deathly. Pushing for delight of the right kind can mean long fights with frameworks to reduce even one-frame delays…

The interactive format is fantastic. Experiencing painful buffers or re-experiencing how early Mac windows could be dragged around, makes the argument visceral in a way no static screenshot ever could. Start with the playgrounds; they make the timing failures impossible to unfeel.

Taras Bakusevych, a UX designer and writer, synthesized 39 principles for designing human-AI interaction across nine domains: probabilistic foundations, expectation setting, calibrated trust, transparency, control, graceful failure, co-creation, responsible autonomy, and sustained reliance. What makes the piece useful is not the count. It is the insistence that AI behavior is interface work.

The whole framework starts from non-determinism: as Bakusevych puts it, “the same input can produce different outputs.” Standard UI patterns were not built for that property. His framing:

AI introduces interaction problems that conventional UI patterns don’t resolve:

• When should the system suggest, ask, or act?
• How should uncertainty appear on screen?
• What evidence should accompany a generated answer?
• How much autonomy does a given action earn?
• Etc

These are not cosmetic questions. They determine whether users can judge output, recover from mistakes, and remain responsible for consequential decisions.

Principle #14, on sycophancy, is the one I would pay most attention to. It turns “the model is too agreeable” into an interface responsibility:

A model that agrees to keep the user happy inflates trust exactly where it should fall.

When the user’s request contains a false assumption, weak reasoning, missing evidence, unsafe instruction, or likely error, the system should have a way to push back.

Build affordances for disagreement — flag weak reasoning, surface the counter-case, say “this looks wrong.” Sycophancy is overreliance manufactured by tone.

Bakusevych backs that with Sharma et al.’s sycophancy research: five production assistants showed sycophancy across varied tasks, models wrongly admitted mistakes on up to 98% of questions, and the preference model favored sycophantic answers 95% of the time. Design the disagreement in: a flag, a counter-case, a refusal to smooth over weak reasoning just because the user sounds confident.

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.

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.

The first time I retrofitted a URL scheme onto an existing web app, it wasn’t easy and the engineers on my team were reluctant. The work itself looked like engineering cleanup, but the problem was design debt: the product had no shared model for what its pages, states, and resources were called.

Routes accumulate around backend data models and frontend file conventions rather than the resource hierarchy a user or linking system would recognize. Ownership fragments across teams; each team names things for its own context. By the time someone wants to clean it up, the redirects are locked in by downstream dependencies and analytics instrumentation is tangled around the old slugs. The retrofix was necessary groundwork for new features that needed stable, meaningful URLs to work at all. The real lesson was that we should have had this conversation at the start, not mid-build.

JSTools.Space explains why that cleanup is so expensive:

A URL is part navigation, part application state, and part public interface. Once users bookmark it, search engines index it, monitoring systems record it, and other applications link to it, changing that URL becomes an architectural decision rather than a cosmetic edit.

Good URL design is therefore less about making every address look pretty and more about making it predictable, stable, and unambiguous.

The decision framework should be a team contract from day one: path for identity, query for optional state, fragment for in-page location or client-only state. Inconsistent routes are what make a migration touch everything. Designers should care because this is information architecture in production, not just routing syntax.

Heenesh Patel links Apple’s WWDC 2026 moves (Siri now able to invoke app functions without the user ever opening an app) to a larger skill shift for designers. The polished-UI moment isn’t ending, he argues; its shelf life is just shorter than we think.

This moment might be shorter lived than expected, as we enable agents to execute more tasks on our behalf, screen-based flows fold in on themselves to intents, replaced by API calls and lightweight confirmations. Here the beautifully crafted experience still matters, but it’s not where the experience lives.

As designers continue to rapidly evolve their skills in an AI first world, taste judgement can elevate the experience but only so far and the real differentiator in app design becomes the overall experience architecture, and how flexible and robust apps are in embedding into the platform.

Patel locates the new value in how flexibly and robustly an app’s functions embed into the platform. That is a systems problem before it is a screen-design problem.

Taste is the skill of this moment. Systems thinking is the skill that will become indispensable in the next chapter of design. Designers who start building that capability now will be the ones setting the standard when the shift arrives in full.

The uncomfortable implication in Patel’s urgency: Job Stories (a way to frame user intent in context) and state charts (maps of the states an experience can reach) have been in the UX toolkit for years. What changes is the operating system. If Siri can trigger app functions directly, and if users can move through an experience by intent instead of by screen, designers need to understand the states, permissions, handoffs, and failure paths that sit behind the interface.

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.

Jenny Xie, writing for Figma, collects a set of community sketches about what AI-native software might feel like. The useful part is how concrete the sketches get: controls that appear only when they’re needed, systems that change pace when the user is overwhelmed, and interfaces that treat intent as the starting point instead of the final prompt.

Figma Weave marketing director Itay Schiff starts with creative tools:

When you’re working with a creative tool, select an element—a frame, a sentence, a scene—and state what you need to do. The right controls appear around it, surfacing only what’s relevant to that moment. No hunting through menus, no memorizing where things live. When you’re done, they disappear. Someone editing a video that feels too slow selects a clip and sees options for timing, pacing, alternate cuts, and sound bridges. You’re not losing touch with your craft, but accessing the right controls more directly, through context. This bridges the gap between how people think and how tools are structured. Creative work starts with intent—make this clearer, more nuanced, more intense—but traditional software is organized around persistent menus, panels, and modes. When users can focus on decisions rather than mechanics, the conversation shifts from what buttons we pressed to what we changed, and why.

This extends the generative UI debate from generated content into the surrounding interface: what controls appear, when they appear, and when they disappear.

Anna Oh, Head of Product and Design at Norbert Health, pushes the same idea into domains where software has to adapt to the person using it:

An intelligent system continuously adjusts how it communicates and acts based on how you respond. It offers structured guidance when you seem lost, steps back when you don’t need it, and shifts between voice, text, and visuals based on the context. It controls pacing, simplifies language, or breaks down information into smaller steps to reduce overwhelm. For decades, humans have had to adapt to machines. The mismatch between system capability and human readiness has only grown more visible as software becomes more powerful, and in domains like healthcare and education, especially with an aging global population, that gap has real consequences. As AI becomes the intelligence layer, this reverses: Systems meet people where they are, instead of the other way around.

For design teams, that means pacing, language, modality, and restraint become interface decisions, not polish applied after the workflow is done.

Tech anthropologist Jésabel DC shifts from adaptive behavior to the sensory cues that help people understand where they are in a product:

Sound, motion, and pacing are reintroduced as signals that orient you inside an experience. In the early 2000s, digital interfaces were full of these situational cues: the dial-up sound as you went online, the progress bar acting as a passage to the world you were entering, the voice announcing “You’ve got mail.” As technology became faster and more seamless, these cues disappeared, replaced by notifications engineered to grab attention rather than provide orientation. Because our users’ overall tech experience is already so dysregulating, it’s not enough to design something that isn’t overwhelming. We have to actively design experiences that counterbalance the rest of our users’ tech stack—otherwise, we risk losing users not because our product is bad, but because their nervous systems are already maxed out before they arrive. Think: always visible progress bars, sounds that mark transitions, and consistent visual language.

AI has made product work feel weirdly cheap in the middle and expensive at the edges. Another screen, prototype, or feature is easier to produce than it used to be. The harder work is deciding what belongs, what can be trusted, and what should never ship.

That is a different kind of leverage than pushing pixels faster.

Karolina Rojek, writing in UX Collective, names the design problem underneath the AI boom:

As technology accelerates, the limiting factor is no longer our ability to build. Increasingly, technology can help create itself. The harder question is deciding what should be built and how it should fit into people’s lives. That is a human problem, and design sits at the center of answering it-Jon Friedman said.

Design is now the discipline of deciding what should be made, who it is for, what behaviour it encourages, what it removes, what it simplifies, and what kind of relationship it creates between people and technology.

Rojek’s piece tracks Microsoft, Samsung, Shopify, Meta, OpenAI, and even the federal government elevating design leadership. That list is easy to read as corporate signaling, but the pattern is more interesting than that. If AI makes output cheaper, design has to move upstream: what should this product do, how should it explain itself, when should it stay quiet, and when should it hand control back to the person using it?

Rojek:

One of the traps product teams fall into is thinking the interface is the product.

The interface is where the user touches the product, but the experience is shaped by everything around it: onboarding, pricing, permissions, support, notifications, failure states, data policies, service handoffs, organisational incentives, and the user’s real-life context.

AI makes this even more obvious.

She puts that into everyday product terms:

Imagine a small business owner using an AI tool inside an e-commerce platform. The value is not simply whether the AI can generate a product description. The value depends on whether the merchant trusts the suggestion, understands how it affects SEO, can edit it easily, knows whether it matches their brand voice, and feels confident publishing it.

Or think about a designer using an AI prototyping tool. The value is not only speed. It is whether the tool helps them think more clearly, explore better alternatives, communicate intent, and avoid creating generic work at scale.

Or consider a citizen trying to renew a passport or access benefits through a government website. The problem is not just visual design. It is language, accessibility, anxiety, eligibility rules, documentation, error recovery, and the emotional weight of dealing with a system that may affect their life.

This is why “powered by AI” is such thin product strategy. The model is only one part of the experience. Trust, permissions, support, and failure recovery decide whether the product feels useful or feels like more work.

Rojek on craft:

AI can help generate options, but craft helps decide which option has integrity.

This is especially important because AI products can easily become noisy. More prompts. More suggestions. More assistants. More summaries. More generated content. More things asking for attention.

Without strong design judgement, AI can turn products into cluttered systems full of technically impressive but emotionally exhausting features.

Cheap output and coherence are different problems. A product can generate options all day. Someone still has to decide which options deserve to exist, which ones ask too much of the user, and which ones quietly turn into another obligation.

Pratik Joglekar, writing for Smashing Magazine, on the core UX trap in AI products:

This is the risk at the heart of designing with AI today: probabilistic systems wrapped in deterministic interfaces. The AI offers a guess, the interface presents it as truth, and the user, or the organization, acts on it.

Humans are wired for deterministic thinking. We prefer to believe that past actions determine future outcomes. Flip a coin 999 times and get heads every time, the deterministic mind assumes the coin is rigged. The probabilistic mind accepts that the 1000th flip could still go either way. That second mindset is harder to hold onto, but it is exactly what designers need right now.

Products operate in complex, nonlinear environments, and AI is accelerating that complexity. When designers and product teams treat AI outputs as the answer rather than one of many possible answers, they build fragile experiences, and in some cases, like medical diagnostics or financial forecasting, genuinely dangerous ones.

That gap matters because the interface can make a confident-sounding answer look settled. The moment a chatbot, recommendation, risk score, or AI-generated summary hides the uncertainty behind the answer, it becomes a designed claim about how much the user should trust the system.

Joglekar’s practical advice is to treat the model as a signal generator, not a decision-maker:

What you receive is not truth. It is the most statistically likely outcome given the data available. Always ask whether past data meaningfully predicts future behavior. If additional context can improve the prediction, include it. Without context, the output is just one of many possible answers dressed up as the only one.

The trust piece lines up with a recurring AI product lesson: controllable over perfect beats confident and wrong. Joglekar again:

One of the hardest things for designers is making uncertainty understandable and actionable. When uncertainty is hidden, users treat AI outputs as facts. When it’s communicated clearly, trust increases.

Ranges, estimates, and confidence indicators go a long way. A delivery window of “Friday to Monday” tells the truth about variability without misleading anyone, whereas a specific timestamp that slips erodes trust every time. A face recognition feature that says “this looks like Pratik, is that right?” sets more honest expectations than one that just labels the photo with a name.

Communicating uncertainty does not weaken trust — it strengthens it. The goal is not to eliminate uncertainty but to design for it intelligently.

Every product has rooms users are not supposed to spend much time in. A 404 page is one. So is an empty project, empty folder, empty collection, empty dashboard, or empty search result.

Most teams treat these as edge cases. But edge cases are where brand voice has less room to hide.

Orlaith Wood, writing for The Subtext, makes the case through 404 pages:

I love 404 pages. Or more specifically, well-written 404 pages. I screenshot them and save them in a little folder on my desktop. Sometimes I actively seek them out.

Yes, I need to get out more.

A 404 page is the best test of a brand voice. It has to:

1. Admit something’s gone wrong
2. Convey useful information
3. Ideally not bore people to death

If a brand’s taken time to craft its 404 page, it tells me they care about my experience on their website – even the bits I’m not supposed to see. It shows commitment to a consistent brand voice. And consistency builds trust.

Consistency is hard. Brand voice can break all over the place. The companies with the shiniest ad copy are often the ones with the coldest and most corporate customer service comms, or small print. But a good brand voice should be able to flex to the functional. Microcopy, with a little creativity, can be a great conduit of voice.

That line about voice flexing to the functional is the bridge into product design. An empty state has the same basic constraints as a 404: something expected is missing, the user needs a next action, and the brand suddenly has to speak without sounding like a campaign.

It is one of those tiny surfaces where product strategy, UX writing, and brand all show up at once.

The best versions do not merely decorate blank space. They make the product feel considered at the exact moment the user has the least to do.

Wood on the no-joke version:

A 404 page doesn’t have to have a joke on it, if it doesn’t fit with the brand. That doesn’t mean it has to be mind-numbingly dull, like this afterthought from Visa:

The tragic broken image. The ominous dot dot dot. The shifting of blame. From one of the biggest brands in the world. Even ChatGPT could do better than this.

It doesn’t have to be that way. Global Payments could have fallen into the same dreary, robotic trap. Instead they’ve channelled their caring expert tone of voice to lift the mood.

That little ‘we’ll get you to where you’re going’ is subtle, but it’s a nice touch to ease a frustrating CX moment. (Full disclosure: I’m pretty sure my boss wrote this, so I’m basically just sucking up here.)

That distinction matters for empty states too. A B2B dashboard probably does not need a mascot or a punchline when there are no invoices, jobs, assets, or reports yet. It may need one calm sentence that explains what happened, one useful action, and a tone that feels like the rest of the product.

Wood on the brief:

If you have a website, take a look at your 404 page now. Is it missing a trick to channel your brand voice? If you can’t tell, maybe it’s a sign that your voice needs an overhaul, or that you’re missing one completely.

Writing error page copy is rarely in the creative brief. I think it should be. It’s important to show how a brand voice reacts when something goes wrong. Just as important, if not more so, than showing it on a tote bag, or a bus stop ad, or those fake billboards in Camden.

I’d put product empty states in the same brief: not as cute copy, but as one of the few places where voice, usefulness, and trust have to coexist in ten words or less.

Designers are used to thinking with their hands.

That sounds sentimental until you’ve spent time moving hierarchy and spacing around in a canvas. Some thinking happens because the thing on screen moves when your hand moves. It’s visual.

Quinn Keast, a designer writing in UX Collective, is getting at the cost that appears when that gestural loop becomes an instruction loop. He starts with the body, leaning on MIT design theorist Donald Schön:

Every tool becomes an extension of the user’s body. The user develops a spatial relationship with each tool.¹ In design school, we learned how to use pencils, pens, brushes, knives, and a whole bunch of materials and mediums before we were allowed to touch a computer. Mastery of one tool carries forward into other tools, but every tool has its own shape and movements that must be learned.

There’s a feedback loop where information comes back through your hands as you work and direct and change the course of creation. Schön describes this as “a conversation with the materials of a situation.”²

When the things you’re designing are themselves spatial — relationships of hierarchy and attention and movement — manipulating those things spatially is engaging with the problem directly, such that the moving is the thinking.⁴

This is why the “AI is faster” argument can feel too flat. Speed is one dimension. The other is the kind of attention the tool asks from you.

Keast’s distinction is not “old tools good, AI tools bad.” It is that the channel changed:

Big tool shifts have happened before, from the graphic designer’s drawing board to Photoshop, from hand-drafting to AutoCAD, even from Sketch to Figma. Each meant reskilling and churn and fatigue. You might argue these already introduced abstraction; the mouse is an abstraction of the pencil. But each still stayed continuous with the hand: I move, the proxy follows, and feedback still came through.⁵ The making-feel carried through each of these shifts, because the channel was still gesture.

The agent is the first shift that moves the making out of gesture and into language. I no longer manipulate a proxy whose movements mirror my own; I describe an outcome, and hand off the specifics to a system that decides them. The change is from gesture to instruction. It’s not another kind of canvas or another kind of pencil, but rather handing the pencil to an assistant and describing what you want the pencil to do.

That matters for design-to-code work because the thing we’re judging is no longer just the screen. Agents are good at producing a testable surface, but they can hide decisions that a canvas would have forced into view.

I appreciate that Keast doesn’t turn this into nostalgia for Figma. Keast brings in chemist and philosopher Michael Polanyi to name the cost of turning tacit judgment into language:

The act of prompting forces you to articulate into language what the hand knew without speaking — and, as Polanyi observed, “we know more than we can tell,” so that articulation is always incomplete.⁶

Making-feel is generative, where the thinking happens in the producing. Result-feel is evaluative, where I react to the result and how it feels to use. It’s no less engaged, but it’s a different type of engagement.

There’s two questions in my tiredness, and they have different answers.

If it’s a mismatch, in reaching for the agent when the problem wanted the canvas, will that fade, as I learn which problems belong to which layer, and prompting becomes a more well-worn tool?

Or is it a permanent cost, the tax that comes of translating tacit knowing into explicit instruction, of forcing what the hand knew into spoken words, every time, even when the agent is the right tool? That cost wouldn’t fade with skill, because it’s inherent to the tool itself.

I think it’s both — and it’s the latter that I keep thinking about.

For designers working with agents, the question is where prompting helps and where the work still needs the hand in the loop. Which I’d argue is still at the beginning.

Tony Le separates a usability problem from a clarity problem before the team starts redesigning screens:

A usability problem is when the user understands the promise but struggles to complete a task.

A clarity problem is when the user never forms a confident mental model in the first place.

They hesitate. They guess. They bounce. Not because the UI is hard, but because the product is not making a clear argument.

Le’s example shows the distinction in practice:

A few years back, I worked with a company building an internal SaaS product, something they planned to launch within about a year.

They did a lot of things right early on. They invested in research. They poured real money into development, easily in the five-figure range. The team was shipping.

Then onboarding came up.

The owner tried to use the product and got stuck.

Instead of treating that moment like a signal to test the build, align on how the system worked, and validate the onboarding path, the conclusion was immediate.

This is a UX and UI problem.

So the team did what teams often do under pressure. They rebuilt.

They revamped the system once.

Then they revamped it again.

And after all that effort, the real issue came into focus. The UI was not broken. The product lacked a shared, plain language model of how it worked. Key concepts were obvious to the people building it, but not obvious to the person trying to onboard into it. So when onboarding started, confusion showed up as hesitation and wrong clicks, and the team assumed the interface was the culprit. They revamped the system twice, only to learn the real fix was clarity, clearer concepts, clearer naming, and a clearer first win.

That is the part teams miss. The stuck user is real, so the design critique feels real too. But if the product has not made a clear argument, every screen-level fix is downstream of the wrong problem.

I see this most often in products that have accumulated internal language. The team knows what a feature is for because they have lived with the roadmap, the sales narrative, the customer calls, and the implementation details. A new user gets none of that. They get a label, a blank state, a primary button, and maybe a tour.

So clarity is not just better copy. It is the product choosing what it is asking the user to understand first. The interface can make that choice visible, but it cannot make the choice for you.

Amber Bouabdallah, writing in UX Collective, gets at the learning problem lots of designers are facing in this AI transition: the tools don’t produce one shared path toward competence.

Bouabdallah draws the line between deterministic software training and relational AI practice here:

Traditional software training works because the tools are deterministic. You learn where the buttons are, what the shortcuts do, how the system behaves when you click the thing. Mastery, in that world, converges — everyone arrives at roughly the same competence, following roughly the same path, and you can write a training deck for it. Mastery means knowing the tool’s correct use.

AI tools break that definition. Maggie Appleton — designer and anthropologist, now at GitHub Next — gave a talk in 2023 called “Squish Meets Structure” about designing products with language models, and the line from it that I love is her description of the magic-input box: it has “no affordances,” “no knobs or door handles.” The interface, she writes, “offloads a ton of cognitive labour to the user.” There is no correct use to learn. The tool meets you where you are. Which means what you bring to it — your instincts, your mental models, your accumulated taste, your willingness to iterate, your custom claude.md files — is the tool, as much as the model is.

So mastery hasn’t disappeared. It has shifted. With deterministic software, mastering the tool meant converging on its logic. With AI tools, mastering one means the opposite: learning to bend it toward your logic. Tailoring it to how you already want to work. Mastering an AI tool is the craft of making it amplify the specific strengths and experience you bring — so the work that comes out is sharper, and unmistakably yours. That kind of mastery is real, and hard-won, and worth teaching toward. It is just personal rather than universal. Divergent rather than convergent. Everyone’s version of it should look different, because everyone’s version is built out of a different person.

Her Salesforce examples keep that from becoming an abstract tool-training claim:

Six months in, Ningdan and I had designed for tool adoption and accidentally created conditions for something more intimate. Seeing each other work. Seeing the specific choices someone makes when the tool doesn’t behave, the workarounds they’ve invented, the mental models they’ve constructed to make sense of something genuinely new. A window into someone’s thinking — and into how each person was mastering these tools in a shape no one else’s would match.

And once you can see the thinking, you can see the worry too. Amanda Harris, a User Experience Architect on our team, named a tension directly in the post-mortem: “I worry that we’ll lose the exploratory aspects of finding what’s wrong with an idea by jumping so quickly into hi-fi prototyping.” That’s not resistance to new tools. That’s a designer protecting something she knows matters. Hearing it voiced — in a room where everyone is nominally learning the same things — is only possible in a setting small enough and safe enough for honest uncertainty.

The anxiety designers are feeling is a signal, not a weakness.

And Bouabdallah closes by naming the training layer her team actually designed:

The tools will keep changing. They will keep arriving faster than any module can be written, any best practice can be documented, any official curriculum can ratify. It is tempting to treat the peer layer as a bridge — something to lean on until the real training arrives. But the real training is not coming, because there is no fixed competence to train people toward. As long as the tools keep moving, the peer layer isn’t the bridge. It’s the ground.

We did design how designers master AI. We just found that mastery wasn’t what we thought it would be. Not a competence everyone arrives at, but a practice each person builds — bending a generic tool toward their own strengths, their own experience, their own way of working, until the work it helps them make is sharper and theirs.

Nicole Alexandra Michaelis, catalogs the job titles opening up as AI takes over the production work. Titles like “AI Design Consultant” (aka forward deployed designer), “Agentic UX Architect,” and “Trust Designer.”

These new titles are flashy, as she says, and I’m wary of crazy titles as I believe “designer” is a good catch-all. Michaelis seems to agree:

The “Product Designer” used to be the top of the crop, working with content designers, motion designers, UI designers, service designers, and more. But all of these titles had one thing in common: deeply strategic design thinking. While product design was often treated as the most T-shaped profile amongst designers, I always believed any (good) designer could shift in and out of skills and ways of working quickly, independent of their specific title.

The constant she identifies—deeply strategic design thinking—is the job; the titles are what we print on the business card in any given season. I’ve watched these labels multiply over the years, and the strong designers always moved between them regardless of title.

Take the Trust Designer:

The Trust Designer focuses entirely on transparency. They translate complex cryptographic or algorithmic verification into instant, split-second visual signals. They design the metadata tags, watermark indicators, and explainability mechanisms that show consumers exactly why an AI recommended a specific product or how a piece of media was verified.

The work here is genuinely needed. Translating something invisible—verification, provenance—into a split-second signal a human can trust is design at its core, not pixel-pushing. This is the part worth taking seriously, regardless of what we call the person doing it, or that it’s its own full-time job.

Michaelis again:

Ultimately, this shift is incredibly empowering for the creative community. The lesson of the AI age isn’t “learn to code or get replaced.” It is that design is moving away from the mechanics of pixel production and shifting heavily toward cognitive psychology, systems thinking, and business orchestration. And I would argue, most of us loved that part of the work most anyway.

She’s right about where the work is heading, and the only thing I’d watch is the title proliferation. The strategic judgment underneath is the same craft it’s always been, whatever we end up calling it.

The AI job grief piece was about what happens when old roles stop feeling stable. Sarah Gibbons, writing for Nielsen Norman Group, gets at the next question: what are we actually supposed to call the new work?

When someone says “AI design,” everyone in the room pictures something different.

One person is thinking about using AI to generate component variations for a design system. Another is designing a chat interface. A third is structuring data so an AI agent can parse it. A fourth is defining an LLM’s behavior.

They all fall under “AI design” but they are not the same work.

I see this in job postings, LinkedIn posts, and conference talks. Someone says, “We need to figure out our AI design strategy,” and every person at the table nods — while imagining a completely different thing. Six months later, everyone’s frustrated because the “AI-design initiative” was not what they expected. 

The conversation around AI and design is forking. What used to be a single (admittedly vague) topic has split into at least four distinct orientations. Each one focuses on a different type of design work, sits in different organizational structures, and uses different definitions of what “good” looks like. Most teams are staffed for only one of these orientations, confused about which one they’re doing, or trying to dance between all of them without realizing it.

Gibbons’s agent-facing category moves the taxonomy beyond the human interface:

This one is going to feel like a departure from user experience. Stay with me.

In this type of work, you design content, data, or interactions that AI agents (not humans) will read, parse, or act on. You’re building the infrastructure that autonomous systems navigate. If AI agents are the self-driving cars, you’re designing the roads, the signage, and the lane markings. AI agents are your users.

That might mean structuring product data so a shopping agent can compare options on behalf of a user, writing instructions that an AI assistant will follow, or optimizing content for AI search and discovery instead of (or in addition to) human search and discovery.

Some of this infrastructure won’t even be human-readable. A road sign designed for AI-controlled vehicles might encode information in ways no human driver could parse — data transmitted via radio or embedded in nonvisible parts of the spectrum. The “user” of that sign is an agent, and the design constraints are entirely different.

This is the orientation most design teams are still ignoring, but mostly because many organizations don’t have anyone explicitly responsible for how AI agents experience their product. Which means it’s either not happening, or it’s happening by accident inside an engineering team with no design input.

Designing for AI agents matters because it involves design decisions. What data gets exposed? How is it structured? What can an agent do versus what requires human confirmation? These shape the end-user experience just as much as any interface, they’re just one layer removed.

She then ties that category shift to the market for design expertise:

Understanding which type of AI design you’re building expertise in matters because the market is moving fast. Right now,  few designers have deep experience across multiple orientations. However, this window won’t stay open for long. Within a year, many more designers will have meaningful AI experience. Those who build depth in a specific direction now will have a significant advantage over those who stay broadly “AI-adjacent.”

Here’s where the field is right now:

Most designers today are using AI as a tool in their workflow. A growing number are designing AI products and features. Very few are designing for AI agents or designing the AI itself.

The demand for those last two is growing. The supply of designers who understand them barely exists. So, if you’re a designer, its an opportunity gap that’s widening.

Mozilla.ai’s Alejandro Gonzalez asks a useful question for designers working through agent-native software: what is the agent actually editing in the first place?

He starts with Claude Design but the piece is really about the old software contract underneath most productivity tools:

Most human-computer interaction has been built around two patterns: issuing commands (typing, clicking, speaking) and manipulating representations (dragging, resizing, arranging, formatting). Every productivity tool ever built is designed around one or both of those. The keyboard, the mouse, the touchscreen. That is the full vocabulary. The interface and the product were, for practical purposes, the same thing.

This is a useful distinction for designers because it doesn’t treat UI as decoration. It treats UI as a historical compromise: the thing humans needed in order to reach the state underneath. Agents put pressure on that compromise because they don’t need the same surface.

Gonzalez is careful about the transition, though:

This is useful. More than useful, it is probably necessary. The world already runs on existing software. Companies have years of organizational knowledge embedded in Gmail, Slack, Jira, Salesforce, Notion. If agents are going to be helpful today, they need to work inside that world.

That is the bridge.

But the bridge is not the destination. Agents using existing apps help bring AI into the current software stack. Apps built for agents may change the shape of the stack itself.

And there is something more valuable in that process than just short-term utility. Watching where agents struggle with existing interfaces, where the translation between intent and UI operation is most painful, is probably the most honest way to find where the structural opportunity is. The friction is the signal.

The agent failing to use a legacy screen isn’t only a product bug; it may be a map of where the product’s abstraction is wrong. For design teams, that shifts the work from polishing the path through a tool to naming the real object of work.

Gonzalez’s product-strategy example makes that abstraction concrete:

The source of truth for a product strategy is not the slide deck, the roadmap doc, the ticket board, or the dashboard. It is the strategy itself: the goals, the bets, the risks, the owners, the metrics, the decisions. Everything else is a view. The memo, the board deck, the launch checklist, the customer brief are renderings of the same underlying object, shaped for different audiences.

A product launch is not a Notion doc, a Linear project, a slide deck, and a dashboard. It is a product launch.

In Gonzalez’s framing, the deliverable is no longer the deck, the board, or the dashboard. The durable thing is the structured model that can be rendered, checked, diffed, approved, and exported.

That is the part that changes the designer’s job. If the source of truth is a structured object instead of a visible artifact, then design has to specify the object: its fields, constraints, permissions, states, failure modes, and views. The screen becomes one projection among many. A human may need a deck, an agent may need a schema, a manager may need a dashboard, and the system needs a versioned record of what changed. Those are not separate products if they are all renderings of the same underlying thing.

Gonzalez closes by keeping the old tools in the frame:

The old tools will not vanish quickly. They have distribution, habits, enterprise contracts, file compatibility, and decades of user training on their side. But the center of gravity moves. The work happens in the agent-native system. The legacy app receives the export.

I do not think this transition will be clean. The old world will remain around us for a long time. People will still export PowerPoint files, update spreadsheets, paste things into email, and manage work through tools that were designed before any of this existed.

But that feels increasingly like a transitional phase.

The more interesting future is not only agents operating apps. It is applications designed so agents, humans, and existing tools can all work with the same underlying objects.

Not because every app disappears but because the source of truth may move.

Jakob Nielsen starts from OpenAI’s new $4 billion consulting arm and its acquihire of 150 Forward Deployed Engineers, the kind who embed with a client instead of building from headquarters. His argument is that they solve the wrong level of the problem: you can speed up the work without changing it. The missing counterpart he proposes is the Forward Deployed Designer.

Nielsen draws the line between faster individual work and a faster business:

With AI, the old workflows must no longer be treated as the design brief; they must be questioned at the root. AI is, in fact, a great productivity enhancer even when used in the traditional way to increase the efficiency of individual employees performing the same tasks as always, just faster and better. A paralegal can summarize a legal brief in seconds; a junior developer can write boilerplate code instantly; a digital marketer can generate campaign copy with a single prompt. We can typically improve that employee’s performance on those specific rote tasks by roughly 40%.

But at the company-wide level, such local productivity gains rarely translate into substantial profit gains and shareholder value. When you have a long chain of steps and optimize only a few, the delay simply shifts to the remaining steps, which will dominate the overall time to solve the underlying problem.

Nielsen again:

Once AI removes the cognitive bottleneck, a different bottleneck appears: authority. The limiting question becomes not “Can the system know what to do?” but “Is the system allowed to do it?” AI-native workflow design must therefore redesign decision rights, escalation rules, audit trails, and accountability boundaries. Otherwise, the organization merely replaces slow human cognition with fast machine recommendations waiting for the same old human permission structure.

Taras Bakusevych closes his walkthrough of ten dying UI patterns on the heuristic that matters:

Execution UI: Interfaces that help humans perform deterministic work — entering data, configuring rules, following process steps, executing repetitive operations. 🟠 Shrinking. As AI automates execution, these surfaces lose their reason to exist.

Judgment UI: Interfaces that help humans evaluate, guide, and correct work done by machines — reviewing outputs, verifying changes, understanding reasoning, intervening at exceptions. 🟢 Growing. As AI takes on more autonomous work, humans need better surfaces to supervise it.

The supervision problem is what Jakob Nielsen called evaluability—the new central UX metric—and Bakusevych is doing the screen-by-screen translation. Every pattern in his list gets re-examined under one question: is this surface helping the human do the work, or helping the human check the work?

The HubSpot quote flow makes the friction concrete:

Creating a single sales quote in HubSpot requires navigating seven sequential screens. The rep manually selects the contact, adds company details, configures line items, chooses signature options, sets payment terms, picks a template, and previews the result — before a single quote reaches the buyer. Each step assumes the system doesn’t know information it already has in the CRM.

Bakusevych’s replacement gives the rep a different role: review what Shopify Sidekick assembled, correct what’s wrong, ship.

That’s the test he leaves you with. Open one screen in your product and ask which job it’s doing. If it’s interrogating the user for context the system could have inferred, it’s on the shrinking side.