Notes on design moving closer to the work.

Four months ago, I stopped treating AI as a tool experiment and started treating it as a workflow problem.

That sounds tidier than it felt. In practice it meant building through a lot of uneven material: product prototypes, specs, eval loops, code reviews, data questions, design-system checks, source-of-truth docs, and little routines that either worked, half-worked, or revealed that my instructions were too vague to survive contact with reality.

I learned a lot. I also made plenty of weird intermediate things. Some were useful. Some were only useful because they showed me exactly where the system was lying to me with a straight face.

The main lesson was not the obvious one, that work can happen faster now. The lesson was that speed without judgment starts to look like chaos wearing a nicer jacket.

A lot can happen in a day now. A prototype can appear. A schema can be sketched. A route can be wired. A critique pass can produce twenty findings. A writing assistant can turn a messy note into something that looks suspiciously ready.

Useful, until the team starts confusing motion with progress.

Progress changes the state of the work. It answers a question, reduces a risk, exposes a constraint, improves a product behavior, or gives a real person something they can react to. Activity mostly produces more surfaces to manage.

I have a lot more respect now for the difference between a busy system and a directed one. A busy system creates files. A directed system changes what the team knows.

Speed makes weak standards more expensive.

If I do not know what good looks like, the tools will happily help me produce more almost-good things. Almost-good copy. Almost-good flows. Almost-good components. Almost-good product logic. The kind of work that looks acceptable in isolation and then quietly makes the whole system harder to trust.

The job becomes deciding which standard matters right now. Is this a sketch that needs to teach us something? Is this a prototype someone can honestly react to? Is this a public surface that needs a production-grade quality bar? Is this a spec that an agent or engineer will treat as instruction?

Those are different standards. Applying the wrong one is how teams end up either shipping confusion or polishing a cardboard box.

The obvious failure mode is moving too fast. The quieter one is calling caution a virtue when it is really fear in a nicer outfit.

I know this one well. It is easy to keep refining a private artifact because private work cannot disappoint anyone yet. A Figma file can always use one more pass. A narrative can always be cleaner. A prototype can always get one more edge case before anyone sees it.

Sometimes that care is real. Sometimes it is just a way to avoid the moment where the work has to meet another person's reality.

A real reaction from a real person is worth more than another private polish pass once the artifact is clear enough to test the question.

Ambiguity is a reason to build a better container for the next decision.

The container can be small. A sharper question. A throwaway prototype. A decision log. A glossary entry. A fake demo state labeled as fake, so nobody accidentally builds a strategy around theater. A review gate before an automated action touches anything consequential.

AI-assisted work changed this part of my practice. When a tool can generate quickly, I can use generation to test the shape of ambiguity instead of waiting until everything feels settled. The output has to make the next judgment easier.

Ambiguity becomes workable when there is enough structure to make progress. Very often, that structure is something you can build.

When a workflow gets chaotic, I try not to treat that as a moral failure. I treat it as diagnostic.

Usually the chaos is pointing to one of three things. The mechanism needs fixing. My skill needs sharpening. The instructions need rewriting.

Those are very different problems. A broken mechanism needs a repair. A weak skill needs practice. Bad instructions need better language, better examples, tighter boundaries, or a source-of-truth doc the system can actually use.

Lumping all of that together under panic is inefficient and also boring. The better move is to ask what kind of failure is in front of me. Is the tool doing the wrong thing because it cannot do the right thing, because I do not yet know how to ask, or because the underlying product logic is not coherent enough to be asked at all?

Fast work also needs directness.

If the work is unclear, say that early. If the prototype is teaching the wrong lesson, say that before the team builds a whole little shrine around it. If the design is visually weaker because I spent less time in Figma and more time making the product behavior real, say that too.

That last one matters. Spending less dedicated time in mockups has had a cost. Some visual designs would have been stronger with more quiet composition time. I do not want to pretend the tradeoff was all upside.

But the prototypes taught me things static mocks could not. Live data taught me where the story broke. Non-deterministic screens taught me where confidence language had to work harder. Product behavior taught me which beautiful states were decorative and which ones actually helped.

Real speed leaves a trail the team can use. A better route. A cleaner schema. A sharper component rule. A design critique log. A working prototype. A rejected assumption. A source-of-truth doc that prevents the same argument next week.

Frantic work leaves debris. Half-named concepts. Duplicate docs. Screens that look done but have no product logic underneath. A pile of recommendations with no owner, no standard, and no memory of why they were generated.

I care much less now about whether a process looks impressive from the outside. I care whether it improves the next decision.

That has become my practical definition of speed: the work moves, and the system gets easier to reason about because it moved.

I want to work clear over impressive.

I want to be humble about what the artifact knows and quietly determined about the standard it has to meet. I want to move fast without worshipping frantic. I want high standards without perfectionism. I want enough structure that ambiguity can become work instead of fog.

The best product work I know names the real question, builds enough to learn, listens when the artifact pushes back, and leaves the system clearer than it found it.

The hardest part of AI-assisted building was keeping the work coherent.

Making things got strange quickly. A screen could appear. A function could appear. A content model could appear. A test could appear. A respectable little draft of almost anything could arrive before I had fully decided what standard it should be held to.

Visual consistency mattered, but I mean coherence in a bigger sense: product intent, system behavior, evidence, language, constraints, and human judgment all pointing in the same direction after the tools had generated a dozen new artifacts that looked confident enough to be mistaken for decisions.

A generated screen can decide what entities exist. A generated function can decide what state matters. A generated content object can decide which user problem is primary. A generated schema can decide what the product is allowed to remember. A generated workflow can decide when a human gets asked for judgment.

Sometimes those decisions are useful. Sometimes they are just defaults with better posture.

The risky part is that they do not always look like decisions. They look like reasonable filler. A status value. A placeholder role. A clean abstraction. A demo state. A helper function. A table name. A line of copy that sounds right until someone asks whether the product actually behaves that way.

Hidden decisions start living inside the product this way.

The problems I ran into were usually small and specific.

Invented entities. Fake completeness. Abstractions that sounded right but did not map to the product. Demo states mistaken for product logic. Old decisions repeated because they were present in the wrong context. Agents extending a concept no one had actually agreed was correct.

None of that feels catastrophic in the moment. It feels like normal product fuzziness. Then the fuzziness compounds.

A card refers to a workflow that does not exist. A spec assumes a review gate that never got designed. A prototype treats a temporary reset state as if it were a real user path. A model reuses yesterday's terminology because yesterday's document was easier to find than today's source-of-truth note.

The dangerous version is a product that feels coherent only because the prose is smooth.

Spec-driven coding helped me slow the system down enough to see what it was doing.

A good spec can name the goal, the constraints, the data objects, the edge cases, the acceptance criteria, and the review gate before the code starts moving. That matters. It gives the tool something sturdier than vibes. It also gives the human a place to notice when the product logic is undercooked.

But a spec is not magic. It can still smuggle in a bad assumption. It can be too broad. It can preserve an old decision because nobody remembered to remove it. It can describe a workflow beautifully and still fail to say what happens when the user does not trust the output.

The best specs I wrote started to look less like handoff documents and more like small operating agreements. Here is the noun we are using. Here is the fake demo state we are not allowed to confuse with product logic. Here is the query parameter that only exists for testing. Here is the review gate that has to stay human. Here is the thing the system should not infer, even if it can produce a very plausible guess.

The spec helps. The judgment still has to be there.

The word guardrail can sound grand. In practice, the useful ones are often plain.

A glossary that says what a thing is called and what it is not called. A schema that uses nouns the user would recognize. Source-of-truth docs with timestamps and owners. Eval loops that check whether the product still behaves the way the team says it behaves. Review gates before consequential actions. Changelogs that make drift visible. Source checks that answer where a claim came from. Routines that catch stale assumptions before they spread.

None of this is glamorous in the portfolio sense. A glossary will not make a dramatic hero image. A changelog rarely gets applause.

But these are the pieces that keep generated work from becoming a pile of plausible fragments.

I used to think of maintenance as the boring part after the work.

I do not think that anymore. In AI-assisted systems, maintenance is how the work stays true.

The product changes. The docs drift. The model remembers an older shape. The prototype keeps a fake state because it was useful for a demo. The team changes a term in a meeting and forgets to change it in the prompt, the schema, the onboarding copy, and the eval rubric.

Maintenance is the discipline that catches those gaps before they become product behavior.

Maintenance is one of the ways the real work remains real.

The design work changed for me when I spent less time making pictures of the product and more time pressure-testing the product itself.

That shift had a cost. Some visual work would have been stronger with more dedicated Figma time. There are screens I would still like to make quieter, sharper, more composed. I do not want to pretend that moving closer to behavior automatically makes every visual decision better.

But the legibility was real. Working prototypes showed where the interaction collapsed. Live data showed where the story got too neat. Non-deterministic screens showed where confidence, uncertainty, and recovery had to be designed as first-class product states. Evals showed where a flow looked reasonable until the system had to explain itself.

A static mock can show intention. A working artifact can reveal behavior.

Design keeps intent legible as it moves through product, code, data, docs, agents, and people.

That makes the designer's job more editorial and more systemic. What belongs? What is a duplicate? What is a temporary demo shortcut? What does this term mean in the user's world? What evidence does this claim need? What should the system be allowed to do without review? What should it never do without a human stopping to think?

Designers do not need to become more technical for the sake of it. We need to help the product keep its meaning as more of the work becomes generated, summarized, retrieved, and acted on by tools.

Someone still has to notice when the thing sounds right but does not belong.

One person can hold a lot of context for a while. Many teams run on that. It works until it does not.

AI-assisted work makes that failure arrive faster. More artifacts exist. More drafts circulate. More agents can act from partial context. More polished output can be produced from stale assumptions. The team can look productive while slowly losing the thread.

Coherence cannot live only in one person's head. It has to live in the system: the glossary, the schema, the product principles, the critique routine, the source-backed docs, the eval loop, the review gate, the changelog, the boring little places where current understanding gets recorded and corrected.

The product keeps its shape when those records move as fast as the work does.

I am skeptical of any AI workflow that celebrates generation and treats maintenance as an afterthought.

More output is not automatically more progress. More artifacts can mean more ways to forget what the team actually decided. More screens can mean more places for fake logic to hide. More summaries can mean more confidence attached to context nobody checked.

The goal is to make sure what gets generated still belongs to the product, the user, and the decision the team is actually trying to improve.

When generation gets cheap, coherence becomes the work. It makes the real design work harder to ignore.

For years, I treated a prototype link like a finished object. I would send the URL in a team chat with a few paragraphs of context and some version of: lmk what you think. The person on the other end would click around for a few minutes, maybe send back a nice work!, maybe ask one polite question, maybe say nothing at all. Then the prototype would slowly disappear.

I thought the problem was the message. Maybe I needed a better headline. Maybe I needed to explain the flow more clearly. Maybe I needed to ask a sharper question. Really, I was handing someone a doorway and calling it a house.

A prototype URL gets someone into the work. It does not tell them what they are looking at, how it relates to their world, where it would live in their workflow, what parts are real, what parts are provisional, or what kind of feedback would actually help. A prototype without a handoff is a suitcase left on someone's porch. They can open it. They can see what is inside. But they do not know what trip it was packed for.

The handoff is the interface around the prototype.

I now think about prototype handoffs as having four surfaces: the message, the schema, the integration map, and the living workspace. Each one answers a different question. Each one prevents a different kind of silence.

The message is the part most designers already do. It matters, but it cannot carry the whole handoff by itself. A good handoff message has five jobs:

The right link. Not the root URL. Not the homepage. The specific starting state you want them to see first. If the prototype supports query parameters, use them. Set the persona, the demo state, the starting view. Do not make the recipient assemble the scene before they can understand the play.

The words that might trip them. Three lines of glossary. Not the whole product dictionary. Just the terms that do not mean exactly what they sound like. This prevents the recipient from spending the first five minutes wondering whether they are missing something obvious.

The demo rules. How to reset it. What personas exist. Which one to try first. What is safe to break. People are oddly polite inside prototypes. Tell them where they have permission to be messy.

The view they will not find on their own. The toggle two clicks deep. The state that makes the whole thing make sense. The little corner of the product that shows the actual idea. Point them there.

The one question you want answered. "Any feedback welcome" sounds generous, but it makes the recipient do strategy work before they can respond. Ask one question, and make it small enough that the answer can fit in one sentence.

The message gets them through the front door. It does not tell them how the house is wired.

The hardest thing for a stakeholder to do with a prototype is figure out how the objects in the prototype relate to the objects in their actual life. The prototype is full of nouns: requests, queues, reviewers, statuses, versions, comments, templates, rules. Whatever they are. The stakeholder is also full of nouns: the artifacts their team already uses, the tools they already maintain, the meetings they already run, the spreadsheets they already quietly depend on.

The handoff needs to show how the prototype's nouns map onto the recipient's nouns.

I now include a one-page schema with every serious prototype handoff. It lists the core objects in the product, their fields, their relationships, and the nearest equivalent in the world the recipient already lives in.

For example, in a generic intake workflow:

A request is the item someone submits because they need action from another team. You might call this a ticket, intake item, submission, case, or ask.

A queue is the organized list of requests waiting for attention. You might call this an inbox, backlog, triage list, worklist, or pipeline.

A decision note is the short record of why something moved forward, changed, or stopped. You might call this a comment, rationale, review note, approval note, or summary.

The schema lets the recipient stop translating in their head and start evaluating the product. Without it, the first part of the demo is spent decoding vocabulary. With it, they can spend that time deciding whether the model is right.

The schema also produces the best feedback.

When someone says, "I don't think of it that way. For us, a request is not owned by one person. It moves between teams," I have learned more in one sentence than I would have learned from an hour of polite clicking.

The UI shows whether the experience is legible. The schema shows whether the mental model is true, which is usually the deeper question.

The second-hardest thing for a stakeholder to do with a prototype is figure out where it would go. No product enters an empty room. It enters a room already crowded with team chat, ticket trackers, shared docs, design files, project plans, email threads, spreadsheets, rituals, habits, permissions, workarounds, and people who are tired of adopting new tools.

Throughout the demo, the recipient is quietly asking: Where does this fit? What does it replace? What does it sit beside? What happens to the tools we already use? How much behavior change are you asking for? If the handoff does not answer those questions, the recipient will answer them alone. Usually badly.

They may decide the product is a chat replacement when it is not. Or a ticketing replacement when it is not. Or another destination their team has to remember to visit, when the real idea is to feed the places they already work. The wrong assumption made privately is much harder to correct than the right framing offered early.

So I include a simple integration map: what they already use, what stays the same, and where this fits.

Team communication stays. Important activity from this product can post into the channel, thread, or inbox where the team already works. We do not replace communication. We make the useful parts easier to surface.

The delivery system stays. Work items can link back to the system the team already uses to manage delivery. We do not replace the tracker. We add context around it.

The documentation space stays. Summaries, decisions, or handoff notes can move into the place where the team already keeps durable context. We do not replace docs. We make the boring parts easier to maintain.

The integration map does a job no demo can do. It positions the prototype inside the stakeholder's existing world before they have to invent that placement themselves. It also reveals what they actually care about.

A stakeholder may nod politely through the product tour, then light up at one line in the integration map: "Wait, could this fit into the review process we already run every week?"

That kind of side comment often tells you where the product wants to attach.

The most underrated part of the handoff is the part that lives after the conversation. A prototype that changes daily needs somewhere the recipient can find the current truth. Not just the current URL. The current truth.

What does the product do this week? What changed since the last version? Which parts are real? Which parts are fake? Which flows are ready for critique? Which flows are there only to make the demo coherent? What is the team working on next?

I now give serious prototypes a workspace outside the prototype itself. It has a simple structure: Start here. Prototype link and demo instructions. Schema. Integration map. Glossary. Design critique log. Evaluation results. Known gaps. Open questions. Changelog.

The workspace needs to be returnable.

A lot of product work is easy to visit once and hard to find again. The chat thread disappears. The URL changes. The prototype gets updated. The notes live in someone else's doc. The feedback is scattered across a meeting recording, a DM, and a comment no one can find.

The workspace is the prototype's memory. It is also the prototype's query surface.

The workspace should be structured so someone can search it, skim it, feed it into their own AI tools, or ask questions against it without needing me in the room. Context only helps if people can use it.

A PM should be able to ask the handoff: What changed since the last version? Which flows are ready for customer feedback? What decisions are still unresolved? What assumptions does this prototype depend on? Where does this diverge from what we learned in research?

An engineer should be able to ask: What are the core objects and relationships? Which states are fake demo states versus intended product behavior? What edge cases have already been identified? Which parts of the prototype imply new data requirements? What implementation questions should we answer before building?

The alternative is hidden labor. Without a structured handoff, the next person has to click through every page, infer the product model, reconstruct the edge cases, guess which flows are real, and translate all of that into tickets, acceptance criteria, technical questions, implementation notes, or customer-facing explanations. That is too much parsing, and intent gets lost there.

The workspace gives the work a stable place to accumulate context. The recipient can come back weeks later and understand what changed without asking me to re-explain the whole thing.

The best version of this is partly automated. A script or workflow pulls the latest docs into the workspace on a schedule, so the workspace is never very stale. The recipient does not have to ask, "Is this current?" The answer is yes by construction.

This piece can feel least like design work because it looks like documentation, operations, or process. But the workspace determines whether the prototype has an afterlife.

Without one, the prototype gets a few days of attention and then falls out of orbit. With one, it stays available. It can be re-entered, forwarded, challenged, queried, compared, and improved.

The prototype becomes less like a performance and more like a place.

AI makes this kind of handoff more important. When prototypes were slower to make, the artifact itself carried more proof of effort. If someone received a detailed prototype, they could assume a meaningful amount of thinking had already happened around it. That assumption is weaker now.

AI-assisted tools can produce convincing screens quickly. They can generate flows, copy, components, dashboards, empty states, sample data, and code. Useful, and risky, because a prototype can look more resolved than it is. The interface can become fluent before the thinking is finished.

A handoff is how you prevent that fluency from becoming false confidence. The schema says: here is the model underneath the screens. The integration map says: here is where this would live in the real workflow. The workspace says: here is what is real, what is provisional, what changed, and what still needs to be tested. The message says: here is the exact conversation we need this artifact to produce.

In an AI-assisted workflow, the handoff becomes a calibration layer. It helps humans understand what the prototype means. It also gives PMs and engineers something structured enough to use inside their own AI tools.

They should not have to manually parse each page of the prototype before they can do useful work with it. They should not have to reverse-engineer the product model from screens. They should be able to connect the handoff docs to the tools they already use for planning, implementation, research synthesis, critique, writing, or technical review.

A strong handoff turns the prototype from something someone has to inspect into something they can work with. It also gives AI tools the context they need.

If a coding agent, writing assistant, research synthesizer, or evaluation workflow is going to operate around the product, it needs more than screens. It needs names, relationships, constraints, integration assumptions, open questions, known gaps, source links, and a current version of the truth.

Otherwise the agent is just as likely as the stakeholder to misunderstand the object. It may generate copy for the wrong user posture. It may treat a fake demo state as production logic. It may preserve a concept that was supposed to be challenged. It may confidently extend a data model no one has agreed is correct.

A prototype is visual. A handoff makes it legible. A queryable handoff makes it usable by the whole team, including the AI tools now sitting inside their workflows.

If the only artifact is a prototype link, the next person has to become the parser. If the handoff includes the model, the assumptions, the open questions, and the current truth, the next person can spend less time reverse-engineering the work and more time improving it.

The faster prototypes get, the more the handoff has to slow the right things down. Not the making. The meaning.

Each part of the handoff does a different job. The message gets the recipient oriented. The schema maps the product to their world. The integration map shows where it fits. The workspace gives them somewhere to return.

None of these parts substitute for the others. A great message with no schema produces a recipient who can open the prototype but not evaluate the model. A great schema with no integration map produces a recipient who understands the product but cannot see how to adopt it. A great integration map with no workspace produces a recipient who agrees in the moment and forgets by next Tuesday. A great workspace with no clear message produces a beautiful pile of context no one knows how to enter.

When all four surfaces are in place, the quality of feedback changes.

People stop saying "nice work" and start saying useful things.

They send annotated screenshots. They forward the prototype to colleagues. They challenge the object model. They ask whether a specific integration is possible. They point to the part of the schema that does not match their world. They tell you which workflow would make adoption easier.

They can also query the handoff instead of asking me to re-narrate it. That changes the shape of collaboration. The prototype is no longer a fragile artifact that only makes sense when the designer is in the room. It becomes a shared object with enough context around it for other people, and their tools, to participate.

The prototype starts producing the conversation it was built to produce.

Handing off a prototype is a UX problem. The recipient is a user. The handoff is their experience. The prototype is only one surface in that experience.

The message is onboarding. The schema is the data dictionary. The integration map is positioning. The workspace is the home screen they come back to. And the workspace is the layer their AI tools can query when they need to understand what the prototype means.

This is more work than designers are usually taught to do because it crosses into territory that looks like product management, engineering, documentation, and operations. It crosses on purpose.

A prototype handoff fails because the surfaces around the prototype were missing. The person receiving it could not tell what mattered, how to evaluate it, where it fit, what changed, or what to do next.

A handoff should make the work usable, durable, queryable, and integrated into the recipient's existing world.

A prototype that disappears into team chat gets dropped at the door, never opened.

Build the interface around the prototype. Most of the value is in the parts that do not look like design.

I once sat in a meeting where four people used the word "update" to mean four different things.

For one person, an update was the message you posted in Slack on Friday afternoon. For another, it was the record in the system showing what had changed since last week. For a third, it was the act of refreshing a dashboard. For a fourth, the most senior person in the room, it was the conversation you had with your manager when something was off track.

We had been talking past each other for a month. The roadmap had three "update" features on it, and each one was being designed by someone with a different mental model. We discovered the disagreement on a whiteboard at the end of a long meeting, and we spent the next two hours just renaming things.

Two of the features collapsed into one. One was cut. The third was rebuilt with a clearer scope. The product that came out of that whiteboard was meaningfully better than the one we had been about to build. We had not changed the design yet. We had changed the vocabulary.

Vocabulary is one of the most underrated parts of design work. Words are load-bearing walls. When you change a word, you change what the product is.

The first thing a word does is choose a metaphor, and the metaphor brings affordances with it.

If you call the thing a thread, the user expects it to have replies, expects it to live alongside other threads, expects it to be findable by participant. If you call the same thing a channel, the user expects it to be persistent, broadcast-shaped, joinable. If you call it a room, presence becomes relevant. If you call it a document, editing does.

These are not interchangeable. The thread, the channel, the room, and the document may share a lot of underlying mechanics: text in, text out, timestamps, participants. But they imply different futures. Users will request different features from each. Engineers will architect each differently. The PM will roadmap each differently.

When you pick the word, you have made an enormous number of downstream decisions you may not have realized you were making.

I worked on a product that had something called check-ins: small, recurring moments where a user confirmed how something was going. For six months I treated check-ins as a single feature. They had a single page, a single data model, a single design language.

Then a user said, in passing, "I do my check-ins in three different ways depending on what triggered them."

It turned out that check-ins on a schedule, check-ins prompted by a system signal, and check-ins the user initiated for their own reasons were three different things wearing one name. The data looked similar. The user's posture in each was completely different.

We split the word. Scheduled check-ins kept the name. Signal-prompted check-ins became observations. User-initiated check-ins became something else. Each got its own page, its own data shape, its own design treatment.

After that split, we shipped more useful product than we had in the previous six months. Three distinct things had been frozen inside one word, and the word was the lock.

This happens constantly. A fuzzy term is a junk drawer with a roadmap hidden inside it. Everyone keeps putting different work into the same drawer, and then the team wonders why nobody can find what they need.

The roadmap cannot be built because the team cannot agree what it is. The team cannot agree what it is because the word does too much work. The fix is fewer words doing less work each.

Words also tell the user what kind of person they are while they are using the product.

A task implies someone with a list, ticking through obligations. A goal implies someone with ambition, picking a direction. An objective implies someone in a meeting, accountable to others. A priority implies someone with too much to do, choosing among items.

These are different identities. The product that calls the same artifact a task vs. a goal vs. an objective vs. a priority is a different product, even if every screen, every field, and every flow is identical. The user shows up differently. The product gets used differently. The product sells differently.

Choosing the word is choosing the user.

A working glossary is one of the highest-return design artifacts I make. It is a single page. It lists the dozen or two terms that do the heaviest lifting in the product. Each entry has a definition, an example, and a not-this list: the meanings the word does not carry, with the alternative words that do.

The glossary is the map legend for the product. Without it, everyone is looking at the same terrain and reading it differently.

The glossary is owned by design, but used by everyone. Engineers consult it before naming variables. PMs consult it before writing tickets. AI agents, in my workflow, consult it before writing copy. Stakeholders read it to learn the product. Customer-facing copy uses it.

When the glossary changes, the product changes. A renaming is a real change, even if no pixels move.

The two rules I follow:

No silent synonyms. If two words are doing the same job, one of them is wrong. Pick one, kill the other, update everywhere. Synonyms in a product vocabulary breed disagreement.

No double-duty words. If one word is doing two jobs, both jobs are getting underserved. Find the seam, split the word, name the pieces.

AI makes vocabulary work more important.

When a product starts using language models, agents, retrieval systems, generated copy, or conversational interfaces, the product's vocabulary becomes part of the system's operating environment. The model reads your words and uses them as handles.

If your product has three different meanings for "update," the AI will not magically resolve that ambiguity. It will inherit it. Worse, it may perform the ambiguity back to the user with a tone of confidence that makes the confusion harder to catch.

A fuzzy product vocabulary used to create fuzzy meetings. Now it creates fuzzy model behavior.

The glossary becomes more than a copy artifact. It becomes prompt context, retrieval context, evaluation criteria, tool-routing logic, and a shared contract between the product, the team, and the machine.

If the AI is deciding whether to draft a response, open a form, summarize a record, recommend a next step, or ask a follow-up question, the words in the product shape that decision.

In a traditional interface, bad vocabulary creates friction. In an AI-mediated interface, bad vocabulary creates drift.

The AI may choose the wrong object. It may retrieve the wrong examples. It may generate the right-sounding sentence for the wrong user posture. It may collapse two different workflows because the product gave both of them the same name.

The glossary, in this context, becomes a kind of semantic API. Not an API made of endpoints and payloads, but an API made of meanings. It tells the system: these things are different, these things are the same, this word carries this intent, this word does not.

That difference separates an AI layer that sounds fluent from one that understands the product it is operating inside.

The more AI a product contains, the more dangerous it becomes to treat words as decoration. Language is no longer just the surface. It is the material the system reasons through.

The temptation, when a word feels wrong, is to coin a new one. Sometimes that is right. Most often it is not.

Coined words have to earn their keep. They cost the user a moment of learning every time they are encountered. They cost the team a vocabulary entry, a glossary line, a translation in every external conversation.

The bar for a coined word should be high: no existing word fits, and the new word picks the right metaphor. If a borrowed word is close, borrow it.

The signal that you should coin is that no available word picks the right metaphor without dragging in the wrong affordances. The signal that you should borrow is that the word almost works and the parts that do not work are negotiable.

The reason vocabulary work is undervalued is that it looks like copywriting from the outside. Someone changes a button label. Someone renames a feature. Someone updates the glossary. The diff is small. The artifacts look the same.

But every word in a product is a decision about what the product is. The button label is a strategy document compressed to two words. The feature name is a roadmap compressed to one. In practice, the glossary often becomes the spec for what the team will build next.

Designers who treat vocabulary as a polish step at the end will keep being surprised that the team cannot agree on what they are building. Designers who treat vocabulary as the first move will be surprised by how much less arguing they have to do.

And in AI products, this gets sharper. The product acts through the words that describe it.

Pick them on purpose.

Designers are used to designing for a person.

We give that person a goal, a context, a job to be done, a level of confidence, a set of fears, a few constraints, maybe a name if the team still likes personas. Then we design the path through the product: what they see, what they understand, what they trust, what they do next.

That work still matters. I do not think human-centered design became old-fashioned because agents can click buttons, call APIs, write code, or summarize a dashboard.

But something is changing underneath it. More products are becoming platforms that are not primarily consumed through a human-facing screen. They are consumed by agents: fast, parallel, literal, persistent, and sometimes wildly overconfident. The product still has users. They are just not always looking at the UI.

I used to think of this as below-the-surface work. Now I think that phrase is too gentle. In agentic systems, below the surface is where a lot of the user experience actually happens.

A headless product can look invisible from a traditional portfolio lens. There may be no beautiful dashboard to photograph. No onboarding flow. No hero interaction. No tidy persona journey from awareness to activation.

But there is an interface.

The interface is the API contract. The schema. The tool description. The examples in the docs. The naming of an endpoint. The default value. The permission boundary. The retry behavior. The error message. The source label. The confidence score. The audit log. The moment the system decides to continue, pause, escalate, or ask a human.

If a human sees a confusing label, they might hesitate. They might ask someone. They might ignore it. If an agent reads a confusing label, it may confidently do the wrong thing one hundred times before anyone notices.

Design has to account for that.

Traditional persona work assumes a relatively bounded human actor. The user has motivations, attention limits, emotional states, mental models, social pressures, and a context of use. We design for those things because they shape behavior.

Agent users have a different shape. They do not get tired in the same way. They do not skim because they are bored. They do not feel reassured by a well-composed empty state. They may call the same tool thousands of times, chain outputs into other tools, misread an affordance, overfit to an example, or treat missing context as permission to guess.

So the design object changes. Alongside a deterministic path for one human persona, we need operating conditions for a population of agent behaviors.

That means personas start to look more like capability profiles. Retrieval agent. Planning agent. Execution agent. Reviewer agent. Support agent. Research agent. Coordinator agent. Each one needs different permissions, context, failure handling, and evidence standards. And behind all of them is still a human steward who needs to understand what happened and why.

I have become slightly obsessive about names because agents make sloppy naming expensive.

A vague field name is a little product decision that will be reused by every downstream workflow. A tool called update_status might sound harmless until nobody knows whether it updates a draft state, a customer-visible state, a planning state, or a compliance-relevant state.

The same is true for data objects. If the system has a weak noun, the product will eventually inherit weak behavior. Agents need clear nouns, clear verbs, clear scopes, clear preconditions, and clear consequences. Humans need those too, but humans are more likely to notice when something feels off.

Headless design has a quieter craft layer: structured names, crisp descriptions, examples that do not teach the wrong behavior, and defaults that guide the system toward the safest useful action.

In a screen-based product, documentation is often treated as support material. In an agent-consumed product, docs are part of the runtime experience.

The model reads them. The tool caller uses them. The engineer copies from them. The agent framework may turn them into available actions. The examples become patterns the system repeats.

This makes documentation a design medium. Not the boring afterthought kind. The actual product surface kind.

A strong tool description should answer the same questions a good interface answers. What is this for? When should I use it? What should I never use it for? What inputs are required? What evidence should I check first? What happens next? What does success look like? What are the failure modes? When should a human be pulled in?

That work is UX writing and product design, even when the reader is partly machine.

If agents are real users of the platform, then evals become a kind of usability testing.

Agents are not people, but the platform still has to prove that its instructions, contracts, permissions, and feedback loops produce reliable behavior under pressure.

A human usability test might ask whether a person can complete setup without getting lost. An agent usability test might ask whether a planning agent chooses the right tool, respects the review gate, keeps its sources attached, refuses an unsafe shortcut, recovers from a missing field, and explains what it did in a way a human can audit.

The questions are different, but the design instinct is familiar. Where does the user misunderstand the system? Where does the system make the wrong thing too easy? Where is the recovery path? Where does confidence exceed evidence? Where does the product need to slow down?

A designer working with agents in the product should be comfortable moving between both kinds of testing.

For a human-facing interface, trust is often expressed through hierarchy, language, confirmation, progressive disclosure, and visual clarity. Those still matter when a human is in the loop.

For an agent-facing surface, trust has to be more structural. Source health. Permissions. Versioning. Trace logs. Confidence thresholds. Reversible actions. Dry runs. Human review gates. Clear authority boundaries. Evidence attached to outputs.

Design leadership gets very real here. You have to decide where trust is earned, where it is displayed, where it is recorded, and where the agent is not allowed to act without more evidence.

The product has to make good behavior the path of least resistance for users that do not have human hesitation as a built-in safety feature.

I do not want a future where designers ignore humans because agents are the immediate consumers of the platform. That would be a category error.

Agents act on behalf of humans, teams, businesses, and communities. The human journey still tells us what matters. What risk is the person trying to reduce? What outcome are they accountable for? What judgment should never be silently delegated? What does the person need to understand after the agent has acted?

The difference is that the journey now includes invisible stretches. A user makes a request. Agents gather context, call tools, transform data, check policies, generate a plan, ask for review, execute a step, leave a trace, and update the system. The human may only see the beginning and the end, but design has to shape the middle.

That middle is where a lot of product quality will live.

Designers need to get more fluent in the materials of headless experience: schemas, APIs, tool contracts, event logs, prompts, evals, permissions, observability, and source-of-truth systems.

Not because every designer needs to become a backend engineer. Because if the product is being used by agents, those materials are part of the user experience.

We need to ask different critique questions. Is the tool description too broad? Can this action be taken without enough context? What happens when the source is stale? Does the agent know when to stop? Can a human reconstruct the decision? Are the nouns in the data model the same nouns the user would recognize? Are we designing for one happy-path assistant, or for many agents operating at once?

It is still design, with fewer surfaces to decorate and more systems to make legible.

I think headless platforms are going to expose which teams have been treating design as styling and which teams have been treating it as product judgment.

If design only means the visual layer, then yes, a headless platform can appear to need less of it. But if design means shaping how a system is understood, trusted, used, constrained, recovered from, and improved, then headless platforms need more design.

The agent user is fast. The agent user is many. The agent user will amplify whatever the product makes easy, clear, ambiguous, or dangerous.

The agentic lens changes the interface: intent, data, models, tools, judgment, and the people who remain accountable when the system acts.

The software development lifecycle was built around scarcity.

Scarce engineering time. Scarce prototyping fidelity. Scarce access to data. Scarce research bandwidth. Scarce ability to test an idea before asking a whole team to believe in it. Scarce capacity to polish the last mile once the first version finally made it into production.

That scarcity shaped everything: roadmaps, handoffs, discovery rituals, design artifacts, sprint planning, MVP definitions, backlog hygiene, and the amount of compromise everyone learned to treat as normal.

But the scarcity is changing. Unevenly, with risk, no magic. Enough to make the old operating beliefs look suspicious.

Five months ago, a serious MVP still felt like a six-month undertaking in many teams. Not because everyone was slow. Because the path had so many gates: clarify the problem, align stakeholders, map the journey, design the flows, define the data needs, negotiate scope, wait for implementation, discover the edge cases, cut the delight, cut the polish, ship the thing, then live with the half-baked version longer than anyone wanted because the team had already moved on.

In my own recent work, I have watched something that once felt like a six-month MVP become a six-day first product slice. Not because the work got easy. Because the cost of learning from something real collapsed.

Every product should not be built in six days. The old MVP was often the smallest version the team could afford to build. The new MVP can be the smallest version honest enough to learn from.

That is a higher standard. It is permission to stop pretending that a brittle, ugly, under-instrumented product is the natural price of moving quickly.

One of the biggest changes is that designers can get closer to the data schema. That sounds dry until you have watched an entire product get distorted because the interface had to inherit a data model nobody questioned early enough.

A designer does not need to become the database architect to have useful influence here. But we can now inspect fields, sketch object relationships, prototype with real API responses, notice when the system is missing a concept users clearly need, and ask sharper questions before the schema hardens around the wrong nouns.

Journey maps used to stop at emotions, touchpoints, pain points, and opportunities. Those are still useful. But now a good journey map can also become a first draft of the product's object model. What has to be remembered? What changes state? What needs a source attached? What belongs to the user, the team, the system, the model, the source, the review gate?

This is where design becomes more consequential. The schema is one of the forces shaping the user's experience.

For all the new machinery, I keep coming back to one very manual first step: map the user journey.

It almost never fails as an anchor. Not because journey maps are sacred. Because they force the team to name the sequence of lived experience before the tools start producing artifacts at inhuman speed.

Who is trying to do what? What do they know at each moment? What are they afraid of? What proof do they need? What does the system know that the user does not? Where does trust get earned or lost? Where is the handoff? Where does the product need to remember something on the user's behalf?

Once that map exists, the rest of the work can flow from it: data objects, API needs, copy, permissions, states, empty states, AI prompts, eval criteria, analytics events, onboarding, support patterns, and backlog items. The journey map becomes the manual human first pass before the machine starts helping with scale.

The backlog used to be where ideas went to wait. Sometimes patiently. Sometimes forever.

With AI in the workflow, the backlog can become more alive. Not a junk drawer. Not a graveyard. A product intelligence system that keeps changing as research, data, product usage, technical constraints, design-system patterns, and customer evidence change.

A good backlog item should be able to carry more than a title and a priority. It can carry the user journey moment, the evidence, the source, the confidence level, the related schema object, the design-system implication, the AI risk, the measurement plan, and the reason it matters now.

That changes planning. If the backlog is alive and trustworthy, planning no longer has to cosplay certainty six months to a year in advance. The team can hold a stronger 1-2 month planning horizon, keep the longer-term direction visible, and let the work respond to what the product is actually teaching them.

A vestigial belief is something that used to be adaptive and now quietly gets in the way.

One belief is that design should stay out of implementation details. That made sense when touching implementation meant derailing engineers or pretending designers were experts in systems they could not inspect. It makes less sense when a designer can use AI tools to explore the system, build a prototype, understand the shape of the data, and bring a better question to engineering.

Another belief is that MVP means ugly, thin, and temporary. That was often a resource compromise disguised as product wisdom. If production-quality UI, real data, instrumentation, accessibility checks, and thoughtful copy are more accessible, the minimum bar should move.

Another belief is that roadmaps become safer when they stretch farther into the future. Sometimes they do. But often they just make everyone defend guesses for longer. If the team can build and learn faster, the more responsible move may be a shorter planning loop with better evidence and clearer decision gates.

This might be the part I feel most strongly as a designer. Teams have tolerated half-baked live products because the alternative was not available. Fixing the awkward flow, polishing the empty state, instrumenting the event, improving the data view, adding the missing review step, tightening the copy, making the prototype production-ready: all of that competed for scarce time.

When resources become more available to more builders on the team, the moral math changes. The product can get better sooner. The awkward thing does not have to sit there for three quarters while everyone apologizes for it in sales calls and customer conversations.

That does not mean every builder should ship whatever they want. It means teams need better guardrails. Design systems, review gates, source-of-truth docs, test routines, observability, and clear ownership become more important because more people can now move the product.

Abundance needs stronger quality practice.

The old lifecycle was a relay race: discovery hands to design, design hands to engineering, engineering hands to QA, QA hands to launch, launch hands to learning. Every handoff leaked context.

The new loop is tighter. A designer maps the journey, sketches the objects, builds a prototype against real or representative data, tests the interaction, identifies schema gaps, ships a small production slice, watches the evidence, updates the backlog, and does it again.

Engineering still matters enormously. Product still matters. Research still matters. Quality still matters. The difference is that the borders are more permeable. More of the team can work closer to the product reality, and the artifacts can be alive instead of ceremonial.

The SDLC becomes less like a factory line and more like a human-legible system.

It asks us to get braver about the parts of product development we used to stand beside.

Brave enough to ask what the schema assumes about the user. Brave enough to prototype with real data even when the first pass is messy. Brave enough to ship a small feature and measure it. Brave enough to say the MVP bar is higher now because the tools changed. Brave enough to make the journey map the anchor, then let the backlog, prototype, data model, and release plan evolve from it.

It also asks us to protect taste. When everyone can generate something, the scarce thing becomes judgment. What should exist? What should wait? What is true? What is overfit? What is humane? What is shippable? What needs one more review gate before it touches a user's real workflow?

I want product development with AI in the workflow to become a way for teams to stop accepting mediocre software as the inevitable first step.

The promise is that more builders can get closer to what the product is actually doing sooner.

When that happens, planning gets shorter and sharper. Backlogs get more alive. MVPs get more honest. User journeys become operational artifacts. The live product improves before everyone has learned to route around its flaws.

I want the shift to mean less wasted time living with work we already know how to make better.

For most of my career, the distance between a good idea and a shipped product was treated like weather. You planned around it. You made peace with it. You learned which ideas could survive the trip through roadmaps, handoffs, analytics backlogs, engineering queues, research plans, data gaps, and the normal entropy of teams trying to do too much with too little time.

Designers got very good at making work legible across that distance. We made flows, prototypes, workshops, diagrams, journey maps, research readouts, and design system documentation. The best of that work still matters. I am not interested in pretending that taste, facilitation, systems thinking, or user understanding suddenly became obsolete because a model can write React.

But the distance changed.

The old model often forced designers to stop right when the work got interesting. You could see that a product needed a richer data layer, but the schema lived somewhere else. You could tell that a dashboard needed a better way to explain uncertainty, but the evaluation logic belonged to another team. You could imagine a more useful workflow, but the automation, permissions, source data, and edge cases were scattered across the organization.

So design became a translation layer. We translated user needs into artifacts. We translated complexity into screens. We translated ambiguity into alignment. That was valuable work, but it also kept us one step removed from the system we were trying to improve.

Tools that generate, summarize, retrieve, or act make that removal less inevitable. A designer can now explore data structures, write small scripts, inspect APIs, generate prototypes from source material, test variants, record workflows, draft eval criteria, and ask better questions of the implementation itself. Not as a replacement for engineering. As a way to arrive at the conversation with more evidence in hand.

I think this is the real shift. AI gives designers access to speed, but speed is the least interesting part if it only helps us produce more rectangles.

The better opportunity is proximity. Proximity to the science behind a recommendation. Proximity to the data that makes a visualization honest or misleading. Proximity to the edge cases that usually hide until late QA. Proximity to the actual text a user will read, the event a system will log, the source a model will cite, and the review gate a human will need before trusting the output.

That proximity changes the quality of design judgment. Saying 'this needs to be trustworthy' is easy. Inspecting the source data, writing the confidence language, designing the review path, and making sure the system never pretends certainty where it only has a guess is the actual work.

It also changes what evidence means. A useful model-mediated workflow should be able to tell the difference between a claim, a behavioral signal, a traceable outcome, and a controlled test. Those are not the same thing. Treating them as the same thing is how teams end up with dashboards that look confident and products that quietly drift away from reality.

There is a lazy version of the future where everyone becomes a prompt person and craft gets flattened into vibes. I do not buy it. The more AI enters the work, the more teams need people who can make judgment calls across messy boundaries.

Designers are trained to sit in ambiguity without immediately turning it into machinery. That matters. But now we can also build enough of the machinery to understand its shape. We can prototype with live data. We can notice when the data model is fighting the user's mental model. We can see when an automation creates a trust problem before it creates a productivity win. We can make the last mile feel humane.

The work is now interface design, system understanding, scope of authority, and what gets left behind for the next team to reuse.

That last question matters more than I used to think. The strongest work includes the durable pattern left behind: the critique routine, the source-of-truth rule, the design-system update, the eval rubric, the skill another person can run without needing me in the room.

A shipped thing teaches you differently than a static artifact. Even a small working prototype changes the conversation because it forces reality into the room. The copy either holds up or it does not. The data either arrives or it does not. The interaction either reduces cognitive load or creates a new little tax. The team can see it, use it, dislike it, improve it.

I care so much about live artifacts because they make the process visible: motion clips, public-data prototypes, Notion workspaces, skills, routines, working product surfaces.

I want designers close enough to the work that our judgment becomes more useful, more grounded, and harder to hand-wave away.

I want design to be less precious and more powerful. Less trapped in critique theater. More willing to touch the data. Less satisfied with a beautiful empty state if the underlying workflow is still broken. More fluent in the systems that produce the interface.

The once spark-deadening space between idea and shipped product is smaller than it has ever been. That should make us more ambitious. The designer who can cross that space with taste, care, technical curiosity, and a quality bar is going to matter a lot.

For most teams, the first problem is shared understanding.

The roadmap says one thing. The Figma file says another. The implementation has moved on. The research notes are still accurate but buried. The support tickets know what is breaking. The analytics know what people are doing. The design system knows what the product wants to be. The code knows what the product actually is. The AI chat knows whatever someone pasted into it at 11:43 p.m. while trying to get unstuck.

Then everyone wonders why the team feels out of sync.

Before AI, stale knowledge mostly slowed people down. Someone asked around. Someone remembered the decision. Someone found the doc. Someone corrected the slide. Annoying, but familiar.

With AI in the workflow, stale knowledge can scale. A model can helpfully repeat the wrong strategy, generate UI from outdated patterns, summarize a decision that was reversed, or create five polished artifacts from a premise nobody believes anymore. The output looks productive. The shared understanding is off by three weeks and one architectural decision.

AI adoption is not mainly about teaching people better prompts. Prompting helps, sure. But if the team does not know where the current version lives, the prompt is a very confident fishing pole dropped into muddy water.

I do not think every team needs to shove all work into one platform. That usually creates a different kind of mess. Designers need Figma. Engineers need GitHub. Product needs planning surfaces. Researchers need room for nuance. Customer teams need their own intake paths. Leaders need visibility without flattening the work.

The trick is making the tools answer to the same version of the product.

That shared version has to stay current. Not a wiki graveyard. Not a folder called Final Final. Not a strategy artifact fossilized at the exact moment everyone stopped believing it. A useful system has owners, update routines, source-of-truth rules, and visible timestamps. It knows what is canonical, what is draft, what is deprecated, what is evidence, and what is merely a good idea waiting for proof.

It also needs reconciliation rituals. Not glamorous ones. The boring, necessary ones: stale-reference checks, duplicate cleanup, link audits, version bumps, decision logs, and lightweight rules for what an agent is allowed to treat as current. Without that, the knowledge system slowly becomes a haunted house with very nice typography.

When I design an AI-assisted workflow, I am usually thinking about loops before screens.

What enters the system? A customer quote, a product decision, a research finding, a bug, a metric, a design critique, a schema change, a support pattern, a leadership constraint. Where does it land? Who reviews it? What does it update? What can an AI agent safely use? What should never be automated? What should be turned into a reusable skill or routine?

A good knowledge loop lets the team move fast without turning memory into folklore. It lets a designer ask an agent for a surface audit and know the audit is using the current principles. It lets a PM draft a brief from real research instead of vibes. It lets engineering see why a design decision exists. It lets leadership understand progress without needing everyone to perform status theater.

The best loops also preserve dissent and uncertainty. They do not convert every note into a fake answer. They keep open questions open, mark assumptions as assumptions, and make it clear when something came from research, a stakeholder decision, an implementation constraint, or a model's best guess.

Teams often try to solve context drift with meetings. Some meetings are necessary. Many are just humans manually rehydrating a shared brain that the tools failed to maintain.

A better system reduces the need for re-explaining. The design system knows which components are current. The product principles are written in a way an agent can apply. The research is tagged to personas, workflows, and decisions. The roadmap links to evidence. The prototype can be audited against the same standards the team uses in critique. The AI outputs leave behind source links so nobody has to ask, 'Where did this come from?'

That is what working in unison looks like to me. Not everyone doing the same thing. Everyone making decisions from the version of the product the team is actually working from.

Designers are natural stewards of context because our work already crosses the borders: user needs, product intent, interaction details, visual systems, language, edge cases, adoption, trust. AI makes that border-crossing more operational.

A designer can help define the shape of the knowledge system. What is the canonical front door? What has to be captured during the work? How do we make reasoning visible without turning every artifact into a legal deposition? Where should AI accelerate the team, and where should it slow down and ask a person to decide?

In old portfolio terms, this is unglamorous infrastructure work, the kind that lets a team keep making good decisions after the workshop ends.

I want teams to build fewer performative artifacts and more durable ones. A good playbook. A current schema atlas. A source-backed copy atlas. A design critique routine that actually runs. A customer loop that does not rely on one person remembering everything. A set of skills that makes the team's best judgment repeatable without making it rigid.

AI-assisted work is going to reward teams that can keep their knowledge usable: updated, disputed, reconciled, reviewed, and available to both humans and agents.

That is when the tools start to feel like one system instead of six tabs and a prayer.

A lot of AI ideation still feels like someone opened a confetti cannon in a strategy meeting. More concepts. More feature names. More cheerful little suggestions that sound plausible until they touch the product.

I do not need a model to give me twenty ideas for improving onboarding if none of them know the user's goal, the current failure pattern, the product's constraints, the behavioral load of the workflow, or the trust problem hiding underneath the interface.

The better use of AI is disciplined, evidence-aware product thinking at a speed that used to be impossible.

Traditional ideation often depends on whoever is in the room, whatever research people remember, and whatever constraints happen to be visible that week. Good teams try to correct for this with pre-reads, synthesis boards, metrics snapshots, heuristic reviews, competitive audits, and design principles. I love those tools. I have used them for years.

But they are usually static. They require people to manually reload context before every decision. A heuristic checklist lives in one doc. Behavioral science lives in someone's head. HCI papers live in a researcher's Zotero library. Product analytics live in a dashboard. Customer quotes live in Notion. The code knows what actually shipped. The model only knows what you paste into the prompt.

So the ideation surface gets weirdly thin. The team is technically surrounded by evidence, but the evidence is not operational.

An AI-assisted ideation system should start by gathering the right judgment layers. UX heuristics catch the classic interface failures: unclear status, hidden affordances, weak error recovery, mismatched mental models, overloaded memory, dead-end flows. Behavioral science adds a different lens: motivation, friction, habit, cognitive load, timing, salience, default effects, loss aversion, trust calibration.

HCI research adds the interaction layer that product teams often flatten: how people form mental models, how they recover from uncertainty, how automation changes attention, how explanations shape trust, how adaptive interfaces can help or overwhelm, how collaboration changes when an AI system becomes a participant instead of a tool.

AI product work adds another necessary layer. Generative systems are probabilistic. Agents can act across tools. LLM-powered interfaces can adapt, summarize, infer, and propose. Product ideas now need to be evaluated for usability, uncertainty, model failure, hallucination risk, prompt brittleness, privacy boundaries, source clarity, and whether the user still knows what the system is doing on their behalf.

I trust AI most when it is not pretending to be the designer. I want it to behave like a tireless product-review partner with access to the team's actual knowledge base.

First, feed it the current product reality: screenshots, flows, events, research notes, support patterns, analytics, known bugs, roadmap intent, design principles, component rules, accessibility standards, and source-of-truth docs. Then ask it to inspect the surface through specific lenses instead of asking for generic ideas.

What violates basic heuristics? Where is cognitive load too high? Where does the system ask for trust before earning it? Where does the default nudge the wrong behavior? Where are we hiding uncertainty? Where would an agent need a confirmation gate? Where is the user forced to remember something the interface should carry? Where does the data model fight the user's mental model?

That kind of prompt produces a map of product pressure.

The next step is to turn that map into a testable claim. Not 'make this better,' but 'this intervention should reduce boilerplate answers,' or 'this review gate should increase confidence without lowering completion,' or 'this explanation should improve transfer to a novel scenario.' The claim needs to be inspectable.

The useful move is running structured disagreement instead of asking one model for ideas and shipping the prettiest answer.

One pass can use Nielsen-style usability heuristics. Another can use behavioral-science lenses like friction, motivation, commitment, defaults, and timing. Another can use human-AI interaction principles: uncertainty visibility, reversibility, calibrated trust, controllability, and human review. Another can use product evidence: conversion drop-offs, repeated support issues, failed tasks, empty states, and qualitative pain. Another can use ML risk: confidence, explainability, data availability, privacy, and failure modes.

Then the system can cluster the findings, separate symptoms from root causes, and rank opportunities by user harm, business value, implementation cost, evidence strength, and reversibility. AI gets powerful here because it can hold more lenses in working memory than a tired team can on a Tuesday afternoon.

I also want at least one pass that is explicitly adversarial. What would make this idea fail? Who would misunderstand it? Where could it encourage shallow compliance instead of reasoning? What pattern would look successful in the metric while making the product worse? If the system cannot survive those questions, it is not ready to become a roadmap item.

A raw idea is cheap. A constrained idea is where design starts.

The best AI-assisted product-improvement routines I have built or used do not say, 'Give me ten features.' They say: propose three interventions that reduce cognitive load without adding a new step. Propose five copy changes that improve trust calibration without making the system sound defensive. Propose two workflow changes that keep review in place before automation acts. Propose one small design-system update that would prevent this class of mistake from repeating.

The model is there to help turn product quality into a repeatable practice.

Fluency is dangerous. A model can make a weak product idea sound mature. It can give a fake sense of completeness to an analysis that never touched a user, a metric, or the implemented surface. It can generate recommendations that feel thoughtful because the prose has good posture.

I want UX heuristics, behavioral science, HCI literature, and AI research embedded into the workflow because they slow down the parts of ideation that should not become smooth.

The pattern I keep seeing in AI product work is practical and unglamorous: users need clearer boundaries, visible uncertainty, recoverable errors, better mental models, and control over consequential actions.

The output of this kind of workflow can be a backlog item, but that is not the only valuable artifact. It can also produce a critique memo, a design-system rule, a copy pattern, an eval rubric, a risk register, a research question, a prototype variant, or a reusable skill that lets another designer run the same analysis next week.

That last part matters. If an AI-assisted review catches a recurring onboarding problem, the win is encoding the pattern so the team can catch it again. If a behavioral-science lens reveals that users are being asked to commit before they understand value, the fix should travel into onboarding principles, empty-state standards, and future design reviews.

This is how product improvement becomes compounding instead of episodic.

I do not think this makes designers less important. It makes our judgment more exposed.

When AI can generate options quickly, the designer's job is to decide what deserves to exist. Which insight is real? Which recommendation is overfit to one metric? Which idea manipulates behavior instead of supporting agency? Which automation changes the user's relationship to the product? Which intervention is small enough to ship and meaningful enough to matter?

The designer becomes the person who can integrate evidence, psychology, interaction theory, system constraints, and taste into a product decision. It is a bigger job than making screens, and a more interesting one.

I want ideation to get less theatrical and more rigorous. Fewer sticky-note forests. Fewer generic AI brainstorms. More living critique systems. More source-backed product audits. More product-improvement routines that run against the live product, not a generic premise.

Automating ideation should not mean outsourcing imagination. It should mean building a better review loop around human judgment: one that brings evidence into the room, remembers what the team already learned, notices patterns we would otherwise miss, and helps us turn good design instincts into repeatable product improvement.

Taste gets sharper when the review conditions get sharper.