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.

Designer and writer MC Dean thinks most AI design demos are still asking the old workflow question: can the machine draw the screen I had in my head?

For Dean, that is too small. The useful shift is underneath it: if an agent is composing the interface, the designer’s job moves from final artifact to operating conditions.

Right now, in design teams everywhere, the same experiment is running. Someone feeds a prompt to Claude Design, or one of its cousins, and waits to see whether it can produce the screen they would have designed themselves. Some people are delighted. Some are frightened by how good it is. Some are disappointed in the results. A few are furious, and I understand why. When a machine can do in 10 seconds the thing you trained 10 years for, it’s annoying.

I want to move us off this question for now, because (nearly) all of us are asking it wrong.

Here is what we are really doing. We have been handed a tool that can grow an interface out of intent, something genuinely new in the world, and we are pointing it at the oldest task we know. Draw a fixed screen. Convert the canvas to code. Hand it down the line, faster and cleaner and with fewer late nights. Useful but look closely at what we are optimising for: We’ve been given something revolutionary, and we are using it to do old school design. A better-preserved version of the old way of doing things.

Dean’s line about “old school design” gets at the trap in a lot of canvas-to-code excitement. Faster handoff is useful, but it still treats the UI as the thing to preserve instead of the thing a system can produce when the context changes.

Dean again:

Canvas to code is a brilliant answer to a question that is already on its way out.

You can watch the whole industry racing to perfect it. Figma put an agent right on the canvas that generates and remixes and respects your design system, then made it possible to push those changes into a real codebase and open a pull request without ever leaving the file. It is clever work, and if your job today is getting a fixed design into fixed code, you should use it. Just notice what it is for. It is the most beautiful possible version of the handoff we have always done. It is the road getting smoother, right before it all changes.

Because here is where this is all heading, and it is so much more interesting than a faster mockup.

This is where designers have to be careful. If the interface becomes runtime output, then judgment has to live in components, constraints, refusal rules, and briefs the agent can actually use. The screen is still how the user experiences the product. It just stops being the primary thing designers hand over.

For a design team, that changes the evaluation. The first pass can be rough and still useful if it exposes which rules, components, and intentions are missing. The important artifact is the environment you can improve, not the individual screen you can rescue.

Dean on the method:

You stop finishing screens and start preparing materials. A set of components an agent can compose from, with the rules of combination written down: what sits next to what, how space behaves, which piece to use and when. Then you write your intentions in plain language, the way you would brief a thoughtful designer who is about to make a thousand small decisions without you in the room. How should this treat someone who is rushed. What does it never do, whatever happens. What should it feel like when the news on the screen is bad. You are not producing the outcome any more. You are designing the infrastructure, architecting the full experience, and curating the best outcomes.

Then you do the part that surprises people. You let it build, and you watch what comes back across many different moments. You correct the environment and the intentions, never the single screen. It is closer to coaching than to drawing. You train judgment into a system, and then you trust it in the places you will never get to enter.

You could start with one flow. Instead of designing the screen, write down everything an agent would need to know to design it well: the taste, the priorities, the hard refusals. Hand it over. Look at what it makes. Then resist every instinct to fix the pixels, and fix the instructions instead. That small discipline, correcting the brief rather than the output, is the whole new craft in miniature.

In designer and investor Soleio’s South Park Commons interview, Rasmus Andersson, creator of Inter and an early Figma designer, draws a useful distinction between software and type. Regular software decays fast; Andersson says that if he hasn’t touched something in two weeks, he usually trashes it and starts over. But a typeface can keep gaining value years later.

Andersson starts with how complex modern software is:

Today there’s just this towering complexity of making software, and for a very good reason, right? For like 15, maybe 20 years by now, our industry as a whole has been hyper-focused on scale because it’s just been an economic evolution that’s been out of this world. So it makes sense that we’ve been trading off and trading away things like shareware, concepts like that, and things like simplicity and ease for the ability to scale and for the ability to things at scale to actually work and break apart. But in the wake of all of that, which is great in so many ways, we’ve given up these things that are listed, and I feel like at least me and many people like me and who sort of are trained to build this thing, enjoy making software at a smaller scale.

That’s like a metaphor that I think can be helpful is imagine your room, apartment, house, whatever, your dwelling place. It’s probably different from the person next to you. And it’s not so that we go out and we buy the Apple apartment and all the furniture is there and everything is perfect and we can change the carpet, and that’s about it. That’s ridiculous, no one would do that. Yet that’s what people do with software.

Manufacturing software was professionalized and gentrified. The stack got so optimized for global products that it left less room for the small, personal, weird things people used to make for themselves.

Andersson’s Figma story keeps that from becoming nostalgia:

First off, something that was just amazing about working at Figma at the time was that there was just this culture of doing things differently. That was amazing. And every single individual who I worked with were just like, if that person went to start a company now and they put me with it, I’ll come. Every person was like that. Every person had an opinion about something that was really exciting.

Another thing that I think was so fascinating about how things were done at the time at Figma was this deep intention around everything and moving slow. But moving slow with many things in parallel, like staggered, right? So from the outside, Figma would ship something every month, maybe even more often than that. But internally, a person would work on one thing for one year. And sometimes at the end of that one year, it would just go into the bin and never ship. So that I think was really cool to see from the inside and then having a very different effect on the outside.

That distinction matters in an AI tooling moment where output is getting cheap. Figma looked fast from the outside because slow, deliberate work was happening underneath. Speed at the surface depends on judgment below it.

On Inter:

One thing for sure is finding the right ratio between impact and effort. I think Inter is one of those things. Sure, I’ve spent like 10 years on it, and who knows how much of my time on it, right? So there’s a lot of effort behind it. But I think it’s one of those types of efforts that has a very disproportionate impact from the effort.

[…]

I gotta say though, something that is amazing about working at Typeface is, it’s something like, it’s almost like in the field of design, you might think about cars as a unique type of thing to design because it’s both like, and architecture’s a little bit like that too. It’s not strictly the sign as in signage for roads, right? It’s very technical and it’s not the sign as in expressing myself through art, like graphic design, like a poster, it’s somewhere magically in between.

And another aspect of it that’s kind of cool is that you can put in 10 minutes here and 10 hours there and they add up over time which I don’t think is true without a software because the rate of decay of any type of regular software is very high. Two weeks is my cutoff. If I have not worked on something for two weeks I have trashed it and start over but with a typeface like that decay is extremely extremely low, in some cases zero.

The useful thing about this AI layoffs simulator is that it turns an abstract workforce problem into something you can see: if every company cuts workers to save money, fewer people have money to spend.

Raj Nandan Sharma built the interactive page from “The AI Layoff Trap,” an arXiv paper about what happens when many companies automate at the same time. Sharma summarizes the mechanism this way:

Rational, forward-looking firms competing on cost are trapped in an automation arms race. Each captures the full savings of replacing a worker — but bears only 1/N of the resulting collapse in demand. The rest falls on rivals. The race is a dominant strategy. This simulator makes the trap visible as parameters change.

In the default model, each company keeps cutting until about 65% of workers are replaced. The healthier stopping point for the whole market is closer to 35%. That thirty-point gap is the trap.

The default setup is simple: each company has 100 employees, workers earn $50k, only 30% of lost income is replaced, and workers spend half their income at the same local companies. The key moment is when the chart crosses from “this is good for my company” to “this is bad for everyone”:

Past the sweet spot. At 31% automation, profits hit their peak. But every company is still cutting — because each firm saves the full wage bill privately, while only 1/1,000 of the lost demand lands on its own books. Profits are now falling, but still above the starting line.

The policy section gets denser, but the plain-English point is this: helping workers afterward matters, but it does not change why each company keeps cutting. The simulator argues that the cost of the decision has to change too:

Foresight alone cannot prevent the race toward the cliff.

I’ve been broadly bullish about AI, and regular readers here know that. The tools are useful already, and designers who learn to direct them will have a real advantage.

That is why I want to make room for Matthew Butterick’s more pessimistic argument. Butterick is a typographer, writer, programmer, and lawyer who has been directly involved in legal challenges to generative-AI training practices. His argument belongs in the AI conversation precisely because it does not require a rogue model or a Skynet story:

Among AI risks, we should take more seri­ously the poten­tial conse­quences of AI working as intended. AI is a capi­talist instru­ment. Its prin­cipal func­tion is to concen­trate capital. Its intended mech­a­nism is large-scale labor replace­ment. But it is also inher­ently polit­ical tech­nology. As AI makes it harder for workers to capture value from their labor, they will increas­ingly have to rely on goodies from Big AI, priva­tizing what were once func­tions of govern­ment. If Big AI subsumes the func­tions of workers and govern­ment, both will tend to realign polit­i­cally around Big AI’s inter­ests. What­ever term describes this system, it is not liberal democ­racy as US citi­zens have tradi­tion­ally under­stood it. AI-centered capi­talism risks an extinc­tion of demo­c­ratic possi­bility. It will be America. But it will no longer be Amer­ican.

Alex Harper, writing for Web Designer Depot, describes the new baseline for web design work:

For decades, a significant portion of a web designer’s value was tied to the act of building: moving pixels in Figma, translating those pixels into CSS, ensuring the flexbox behaved, and troubleshooting why a specific button looked “off” in Safari.

But with the arrival of high-fidelity “Agentic UI” and the rise of what industry insiders are calling “Vibe Coding,” the barrier between a thought and a fully functional interface has effectively vanished.

Today, a founder can speak into a prompt—”Give me a high-end, minimalist FinTech landing page with a Swiss-style grid and a sense of ‘quiet luxury’ using deep emerald tones”—and receive a production-ready, accessible, and responsive site in seconds.

This is the AI design conversation with dollars attached. Once a small business owner can get a polished page for almost nothing, “pretty page” stops carrying much economic value.

Harper describes the commodity pressure as a loop:

The primary problem with Vibe Coding is that AI, by its very nature, is a statistical engine. It generates the most “probable” result based on your prompt. If you ask for a “Modern Minimalist” site, the AI isn’t going to innovate; it’s going to give you a composite of every modern minimalist site it has ever seen.

This creates a Feedback Loop of Averageness. 

1. Designers use AI to generate “vibey” layouts. 2. These layouts are published and become part of the web. 3. Future AI models are trained on these new layouts. 4. The aesthetic “mean” becomes tighter and tighter.

Designers have to take that feedback loop seriously. While the taste in the models are slowly getting better, AI nudges taste toward whatever the training set keeps rewarding. Notice a lot more serif fonts online recently?

That’s why “clean and professional” worries me less as a style than as a business model: if everyone gets the same acceptable answer for almost no money, the designer’s value moves into judgment, story, and constraints.

Harper adds:

To survive the Vibe Coding crisis, designers have to move away from the “Vibe” and toward the “Mechanism.”

If the “look” of a website is now a commodity, where does a designer provide value? The answer lies in the areas that AI still struggles to grasp: Nuance, Narrative, and Friction.

AI can create a page that looks like a brand, but it cannot yet build a page that feels like a story. Vibe Coding creates “scrollytelling” templates, but it doesn’t understand the emotional arc of a user journey. A human designer understands that a specific user might need to feel “uncomfortable” or “challenged” at a certain point in the flow to make a realization. AI only knows how to please.

An AI can generate a screen, but can it generate a philosophy? Designing a design system in 2026 isn’t about making components; it’s about defining the “Ethics of Interaction.” How does this brand handle data privacy through UI? How does it signal inclusivity without being performative? These are high-level strategic decisions that a “vibe” prompt cannot solve.

Cash App product designer Brad Wrage on moving design from handoff to production ownership:

Across this project, I personally merged 25 pull requests across three codebases — Android (14 PRs), iOS (8 PRs), and Server (3 PRs). As a designer.

And zooming out further — over the last two months, I personally authored ~45 PRs merged across 5 repos. As a product designer:

Wrage stayed accountable for the experience after Figma, across Android, iOS, and server. That is where the delay in a traditional handoff becomes obvious. It maps to Cash App’s org-speed bottleneck: building faster only matters if approvals, reviews, and deployment move with it.

Wrage describes the operational core:

This is where the traditional dynamic flips. Instead of filing bugs and waiting for engineering to prioritize them, I lead the charge — logging issues, kicking off fixes, and drive them to completion.

The process: visual feedback and bugs drop into a dedicated Slack channel. Builderbot — which intimately knows our codebase — picks them up and posts rapid fixes, often within minutes.

[…]

I pull the code down, test on a real device, reference my Figma file via MCP, and approve or adjust until it’s right. Every PR still gets a human review.

The guardrail is in that last sentence: code review remains part of the process. The result is a tighter loop between taste, implementation, and product judgment without removing engineering accountability.

Wrage’s phrase for that distance:

This is the inflection point. The designer isn’t on the sidelines filing tickets anymore — the designer is in the driver’s seat, leading the last mile to ship.

The last mile. The difference between “shipped” and “crafted.”

B. Prendergast revisits atomic design:

Atomic design is nearly ten years old. Brad Frost’s atoms, molecules, organisms hierarchy did something genuinely useful when it arrived: it gave teams a shared language for the idea that components are made of other components, all the way down. For a lot of people, including me, that was the conceptual unlock they needed to start building modular reusable front ends instead of pasting the same button in seventeen places. It worked. The industry absorbed it wholesale.

But I think we can probably retire the metaphor now.

Brad Frost’s watershed atomic design concept solved a real communication problem. It helped designers and engineers talk about components as things that compose, not screens that get pasted together. The problem starts when a teaching metaphor becomes the operating model.

Prendergast describes the tax teams pay when that happens:

The problem I keep running into with teams over the years isn’t that they don’t understand atomic design. It’s that they’ve understood it too literally. They’ve set up their Figma and Storybook libraries with Atoms, Molecules, and Organisms sections. They’ve had the naming convention conversations. And then, reliably, they get stuck arguing about whether a card with an avatar and a label is a molecule or an organism. That conversation is a tax. It doesn’t produce better components. It produces friction, disagreements, and the occasional afternoon lost to taxonomy instead of building.

That’s the part I care about in design systems. A good library should make the useful path obvious: which pieces can be reused and which contracts they have to honor. If the library mostly teaches people to sort objects into clever buckets…well, that’s a distraction from the work.

Prendergast closes with the on-ramp caveat:

I’m not arguing against atomic design as an on-ramp. If someone on your team is new to component-based thinking, the atoms/molecules/organisms scaffold is still a powerful and reasonable way to introduce it. Use it. Just don’t park there. The abstraction to keep is composability. Components compose up from smaller components. There are no real required levels between the smallest useful unit and a whole page or view. Whether an intermediate component is a molecule or an organism is a naming problem, not a design problem. We can stop solving it now.

The real test of a design system isn’t whether every component sits neatly in the correct layer of a hierarchy. It’s whether people can understand it, trust it, use it, and extend it without breaking it.

Nobody ships a better product because they correctly identified a component as an organism instead of a molecule. Atomic design succeeded because it taught people to think in terms of composition. Components built from components. Small pieces combined into larger ones. Clear contracts. Predictable behaviour.

Everything else is bookkeeping.

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.

Jason Cyr, writing at The Human in the Loop, starts with the AI-design conversation’s taste claim and points to the work teams need before agents start producing anything:

There’s a popular narrative that design’s value in the age of AI is taste — the human eye that says “not that, this.” I think that undersells us. Taste matters. But what organizations actually need from design right now is clarity. The ability to wade through ambiguity, make invisible systems legible, and give teams something they can act on. That’s always been the real (often under-appreciated) superpower, and AI just made it an urgent need.

Cyr’s earlier piece on agentic-era design teams covered the move from making outputs to directing work. Here, he describes the coordination layer that had been hiding inside the old process:

The old product development process had shock absorbers we never realized. Meetings where people quietly aligned on things that were never written down. Hallway conversations that resolved ambiguity nobody had formally surfaced. Design reviews that were really translation sessions — designers decoding what product actually meant, engineers decoding what designers actually intended. PMs who held critical context in their heads and dispensed it as needed.

None of this was in any process document. It was human labour — invisible, unacknowledged — absorbing the ambiguity that the formal process couldn’t handle.

We called it process, but it was actually a buffer.

Cyr puts that clarity work inside design leadership:

Here’s the thing about this problem: it’s not a tooling gap. It’s not a project management gap. It’s a clarity gap.

Design earns its seat at the table when it moves beyond artifacts and starts shaping how a product organization delivers work. Not just the screens. Not just the system. The operating model itself — who decides what, when something is ready, how context travels, and what “good enough” means at each stage.

Fabrizia Ausiello, writing for UX Collective, uses Apple’s Liquid Glass transparency slider to ask who is supposed to make interface judgment calls:

Apple just introduced a transparency slider for its Liquid Glass UI — a control that lets users dial up or down the translucency of system elements. On the surface, it’s a thoughtful accessibility gesture (especially considering the criticism that Liquid Glass has accumulated), but in practice, it’s the manifestation of a deeper tension that designers have been circling for years: when you give users a knob, are you empowering them or just finishing your job somewhere more convenient?

Ausiello on the older design assumption that users shouldn’t have to make these calls:

For most of the history of digital product design, designers have been making decisions so users don’t have to. We studied, tested, iterated, and then shipped something that worked. Interface design is opinionated because it has to be.

It might sound arrogant, but it really isn’t, it’s simply part of the craft that’s baked into the role. The whole point of a well-designed system is that it removes cognitive load; the moment you ask a non-technical user to evaluate the “level of transparency” of their interface, you’ve already failed them because they don’t have a mental model for it, they just want to read their notifications.

I agree. As designers, we should be making this call. Ausiello turns the same question back on us:

If you work in digital product design, this moment is worth paying attention to for the precedent that it’s setting.

As AI takes over the execution layer — generating screens, producing variants, handling repetitive interface decisions — the value of a designer is shifting and the role that remains is the harder one: understanding the problem deeply enough to know which decisions shouldn’t be delegated at all.

Some things should be personalised, some should not, and knowing the difference, having the conviction to hold that line, is a skill needed and worth having. Dumping a slider in onboarding isn’t personalisation — it’s a designer who didn’t finish their job.

The future of adaptive interfaces is exciting, but getting there doesn’t mean abandoning judgment in the present. It should mean being more deliberate about which decisions belong to the system, which belong to the user, and which belong to you.

Interestingly, Ausiello also gives Apple an out. That maybe, Apple is playing the long game here and gathering data to make personalization more automatic in the future. The author again:

The reasoning goes roughly like this: we don’t need to commit to a specific default, because the AI will figure out the right setting for each user eventually. Siri will learn your preferences and you’ll just ask it to make things more readable and it’ll handle the rest. Seen from this perspective, the slider isn’t a UI failure, but rather an early, manual version of something that will eventually be automatic.

Honestly, I think it’s a bit of a stretch. Nice thought exercise though.

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.

Jack Maguire writes about AI displacement as a grief problem, not only a labor-market problem:

Knowledge workers hold a different relationship to their labor than manufacturing workers did. For a cognitive professional, expertise is not only an activity. It is a large part of the self. A data scientist who has spent a decade building statistical judgment does not experience that judgment as a detachable tool. It is closer to a personality trait. When automation threatens the work, it reaches past the income and touches the identity.

I can certainly relate—my profession is my identity and sense of self, unhealthy as that may be.

Maguire on disenfranchised grief and AI layoffs:

Even where grief exists, workers are denied social permission to feel it, and the denial makes the grief worse.

The relevant concept is disenfranchised grief, a term coined by the grief researcher Kenneth Doka for loss that is not acknowledged or socially supported. As one accessible summary puts it, disenfranchised grief is “grief that is not acknowledged or socially supported, often because the loss does not conform to societal expectations of what should be mourned.” When a loss is not recognized by others, the grieving process stalls, and the grief stays “hidden and unresolved.”

Tech layoffs are engineered to produce exactly this condition. They are framed as strategic pivots, restructurings, and efficiency measures. The language is designed to read as ordinary corporate hygiene, and it forecloses mourning by refusing to name a loss at all. There is no ritual for the end of a profession, no obituary for a career, and no socially sanctioned grief leave for the worker who has watched the meaning drain out of work that technically still pays.

The default cultural model for grief still tends to be the five stages of grief, popularized by psychiatrist Elisabeth Kübler-Ross: denial, anger, bargaining, depression, acceptance. Maguire’s point is that AI displacement does not behave like a bounded loss moving toward acceptance:

The Kübler-Ross framework assumes that acceptance is reachable, because the loss it was built to describe is finite. When a person dies, the absence becomes permanent. The bereaved adjusts to a stable, if painful, new reality. Acceptance is possible because there is something fixed to accept.

AI displacement does not offer a fixed endpoint. The process is ongoing and accelerating, with no stable post-AI equilibrium to adapt to. A worker who retrains into the safe role of this year may find that role automated within two years. There is no permanent absence to grieve, only a moving frontier. Workers are being asked to accept a process rather than an outcome, and the process keeps advancing.

Apple’s developer conference WWDC kicked off on Monday with a keynote. They announced various OS improvements, including refinements to Liquid Glass, and most importantly, a revamped AI strategy.

In the days leading up to the keynote, longtime Mac journalist Jason Snell wrote about building his first Mac app with Claude Code in just a couple of hours. We’ve heard this story before. We’ve been talking about it here for months. And yet, here’s a veteran technologist who’s just now discovering Claude Code’s power and building an app.

It’s easy to get caught up in the Silicon Valley AI hype bubble and think the whole world has changed and is using AI for everything. But no, that’s not actually the case.

Snell on what the experience actually required:

The process of building the app reinforced something I’ve been thinking about for quite a while: coding is a specific skill, but it’s only one part of a much larger process. Great developers aren’t necessarily great coders, though they can be. Apps must be envisioned, their specifications defined. The act of trying to describe an app to an AI coding engine is a clarifying one. The more you describe the app, the harder your brain has to work, because it’s always more complicated than you think it’s going to be. The decisions you make determine what the app comes to be. […]

Yup, tell me about it. Tell us product builders about it! The code was never the hard part.

Where I’d push back is on the optimism around it:

We now live in an era where, if you can dream an app, you can probably build it. Especially Mac utilities. And who cares more about native Mac software than Mac users? Certainly not those companies that gave up on Mac development and focused all their energies on giant cross-platform code bases to attract venture investment and big payouts.

Snell himself calls his app “ugly and incomplete” a paragraph earlier, so “if you can dream it, you can build it” is a bit of a stretch. The gap between a thing that runs and a thing you’d ship is where the real work lives: envisioning, deciding, refining.

And it’s a reminder of where the next barrier sits. Snell ends on the tooling:

Which brings me to a final point: Apple’s development tools, most notably Xcode, are nightmarish. My developer friends are used to them, but as someone who has never really used Xcode before, I was shocked at just how deeply unintuitive it is. As in, Claude would tell me to click on things, and I would have to reply, “I have no idea what that is or where it’s supposed to be.” And I’ve been a Mac user for a long time! I’ve gotten very good at intuiting where stuff is in a Mac interface.

[…]

While AI tools have made it more possible to build apps on Apple’s platforms, the developer tools themselves are still a formidable barrier. As the definition of “developer” changes, so, too, must the definition of developer tools.

I wholeheartedly agree with Snell that Xcode is a mess. For those like me who only open it on occasion, it’s baffling that Apple developers live with such a nutty application. Take a look at the best of Apple’s first-party apps like Keynote, Final Cut, or even Numbers, and Xcode is just…bizarre.

Apple did announce something at WWDC 2026 that was interesting—that nods to where they could go if they wanted to—users can ask Siri AI to vibecode Shortcuts and Safari extensions. Will have to see if that’s the seed for something.

Arpan Patel wrote a nice consolidated Claude Code reference: the directory layout, CLAUDE.md the way Anthropic’s Boris Cherny writes it, skills, subagents, MCPs, the underused commands. The whole guide turns on one shift:

Claude Code clicked for me once I quit treating it like ChatGPT in a terminal. The mental model flipped from “I need to write this code” to “I need to set Claude up to write this code well.” Setup is the work. Execution is verification.

If you use Claude Code daily, bookmark it.

Emma Webster, writing for Figma, argues that AI tools are pulling prototyping earlier in the product process: teams can validate with more fidelity, then carry design context forward instead of recreating it at handoff.

Product teams are rapidly adapting to the new way of working in the AI era. They’re prototyping before writing specs, testing in code before designing, exploring at unprecedented scale, and shipping with design system context that used to get lost in the handoff. We talked to product builders at FloQast, Merkle, Affirm, and Accor about how that’s playing out in practice.

The shift is about when the hard questions show up. Specs used to be the artifact that let teams pretend they had alignment. The team behind Claude Design skipped the PRD entirely and prototyped its way to the answer instead. With AI tools, a prototype can become the first serious question: does this flow hold up when the data, logic, motion, and system constraints are present?

Webster describes the code-to-canvas loop this way:

Testing an idea against intricate constraints—things like multi-step flows where one action triggers the next, or interfaces that behave differently depending on the data behind them—used to require significant developer investment. Today, AI coding tools have made it possible for more people on a product team to quickly build and test these kinds of interactions before committing to a direction. That’s opened up a new workflow. A product builder can create a working prototype in code, then move it onto the Figma canvas using Codex to Figma to see the full picture and refine it together. From there, if more work needs to happen in code, they can move back via MCP with the design context intact.

This is the version of AI-assisted design I care about. Not “prompt a shiny UI from a blank page.” A working model becomes the place where designers, PMs, and engineers can see the same problem at once. Figma is still the canvas for style exploration and visualizing complex flows, but the decision surface is becoming more product-shaped.

That matters because prototype fidelity changes what a team is allowed to learn. A flat mockup can test preference and comprehension. A working prototype can test sequencing, edge cases, permissions, motion, and whether the idea survives contact with real constraints. Bringing that earlier into the process should make design less speculative, not less thoughtful.

The Accor example shows why this matters before anyone commits to a build:

Justine opened Figma Make and prototyped something she wouldn’t have had time to build by hand—a webpage that reorganizes itself based on what the user types. Search for “golf” and the page reshapes around properties with golf courses, curated outings, and relevant experiences. Make handled the micro-interactions and transitions, and the Figma MCP server kept everything connected to the brand’s design system. Within days, she had a working prototype ambitious enough to show leadership what was possible—and concrete enough to start a real conversation about what to build next.

Webster’s Affirm example carries the same logic all the way into production:

A PM prototyped the badge variations in Figma Make—going from idea to working prototype in two days instead of the usual six weeks. Designers refined the winning direction on the canvas, and when the team was ready to move that design into production, they loaded the design artifacts into the Figma MCP server and connected it to Cursor. MCP passed the components, tokens, and layout structure directly into the coding environment, where an AI agent generated the front-end implementation. Developers used that as their starting point, building production code that already reflected the designs instead of reinterpreting them from scratch.

Preserving components, tokens, and layout structure turns the prototype into a rehearsal for the real build. It has enough fidelity to expose bad directions early and enough context to keep the winning direction from being rebuilt from memory.

Simon Willison thinks the AI labs have found product-market fit. Here’s his own monthly usage priced at API rates against the $200 he actually pays:

• $1,199.79 for Anthropic Claude Code
• $980.37 for OpenAI Codex

That’s $2,180.16 worth of tokens for $200—not bad at all! I’m a moderately heavy user of these tools, but I’m certainly not running agents every hour of the day and night.

That discount is gone: since April 2026 enterprises pay full API rates. Willison’s read:

Coding agents really did change everything. These are tools which burn vastly more tokens, but are also quickly becoming daily drivers for the work carried out by extremely well-compensated professionals. Right now that’s still mostly software engineers, but a coding agent is a tool that can automate anything you can do by typing commands into a computer… so they are clearly applicable to a much wider set of skilled knowledge workers.

Right now the bill falls on engineers. Designers may be next. Anthropic has already rolled out a separate usage meter for Claude Design. And Figma is charging for AI usage overages.

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.

The line usually attributed to Einstein goes like this: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” It is a warning against racing to the answer. Gale Robins, writing for UX Collective, makes the same case for product teams—then moves it one step earlier than Einstein did.

Her subject is the decision that rarely gets scheduled: whether a customer signal deserves discovery at all. She calls it Signal Evaluation, and she describes it bluntly:

Signal Evaluation is not a box to tick on the way to the real work. It is a filter, and a good filter is defined by what it keeps out. If most of what reaches your team makes it into discovery, the filter is not working; it is just a turnstile.

This is Einstein’s 55 minutes, relocated:

It is tempting to think discovery begins when you start talking to customers. It begins one step earlier, with the call to research this rather than something else. Every signal that reaches a team […] arrives carrying an implicit claim: this is worth your attention. Evaluating a signal is the act of testing that claim before you spend anything on it.

The difference she leans on is between a feature signal and a job signal:

The distinction that matters is whether the signal is about the customer’s job or about your product […]. “The export button is confusing” is a feature signal: it concerns your solution and usually warrants a quick fix rather than a discovery effort. “I cannot get my insights to my stakeholders” is a job signal: it is about what the customer is trying to accomplish, and it may hide an underserved need worth real investigation.

That is the trap Einstein was guarding against. The seductive request arrives pre-packaged as its own solution—add the widget, fix the button—and it is tempting precisely because it lets you skip the 55 minutes. Robins’s point is that a signal can be strong, genuine, and still aimed at the wrong job.

Here is where she goes past Einstein. His hour is already committed: he has a problem and is deciding how to spend time inside it. Robins is working a layer earlier. Her question is whether the signal has earned the hour in the first place. In her words, the skipped judgment is “whether to begin it at all.” Signal Evaluation is the gate before Einstein’s clock even starts.

AI is what makes that gate matter more now, not less.

AI can scan your entire feedback corpus, cluster signals by frequency, surface correlations with churn, and tell you in minutes that the widget request appeared in twenty-three of forty calls. That is genuinely useful and genuinely predictive: pattern-finding at a scale no human can match.

But notice what AI cannot do in that example. It can tell you the signal is strong. It cannot tell you the signal is pointing at the wrong job. That judgment, that “more widgets” is really “I cannot see what matters,” and that building the literal request might make things worse, is meaning-making, not pattern-matching.

Tokyo Design Forum publishes former Facebook and Dropbox design leader Soleio’s closing talk from this year’s conference, where he previews a book-sized thesis called The Geometry of Luck. Soleio’s move is to treat luck less like a mood and more like a design problem: a question of arrangement, position, and conditions.

He starts with geometry because geometry gives the argument its discipline:

When we say something has a geometry, we mean it has structure.

Not just parts, but relationships between parts, distances, angles, arrangements that produce specific properties.

For example, a triangle just isn’t three lines, it’s three lines whose arrangement do something. The interior always sum to 180 degrees, no matter the triangle. That is geometry. It’s structure that produces reliable properties.

So when we talk about the geometry of a room, or the geometry of a negotiation, or the geometry of a network, we’re saying something very specific about its nature. We’re saying its composition, its arrangement, tells us more than a list of its parts.

That saves the talk from becoming another self-help riff on “making your own luck.” Soleio is more precise than that. He is saying luck has variables, and designers already understand the work of arranging variables toward a purpose. He links that to industrial designer and architect Charles Eames’s definition of design as a plan for arranging elements toward a purpose.

When something has a geometry, it can be measured, it can be reasoned about, it can be taught.

[…]

So geometry is a language of arrangement.

For designers, it’s like the vocabulary of our craft.

From there, the framework becomes practical:

I believe luck has three facets, three independent variables that work together in concert. They are the basic elements of good fortune.

The first I call orientation, how we perceive our environments and place ourselves within them.

The second is surface area, the degree to which we’ve made it easy for good fortune to find us.

And the third is novel action, our capacity to act on what we perceive, what we do with the opportunities that the universe presents to us.

The useful distinction here is agency without control. You don’t command the outcome. You arrange the conditions: what you can see, who can find you, and whether the value you create can keep circulating after it leaves your hands.

That is why the talk eventually turns back toward software design:

As software designers, we shape the environment where luck happens.

We are very, very lucky to be here in this room today.

Few inventions touch the fabric of people’s daily lives, such as software.

Every interface, every space, every system we create either amplifies or dampens the flow of opportunity for the people who encounter it.

With every over-the-air update we push to production, we alternate the networks through which luck flows.

And so I hope designers put as much consideration to luck as they do look and feel and utility.

I like that as a design brief. Not “be lucky.” Not “hustle harder.” Arrange yourself, your work, and your systems so more good fortune can pass through them. Test hypotheses. That is a useful bar for products too.

The line running through Tobias Van Schneider’s interview is simple: designers complain about tools all the time, but the better move is to build the environment you wish you had.

Nikolas Wrobel interviews designer Tobias Van Schneider, founder of Semplice and mymind, and the profile traces that pattern directly: Semplice for portfolios that didn’t fit the platform/template world, then mymind for thinking without the performative noise of social media.

Van Schneider:

How do you protect yourself against consuming, draining effects from Social Media, or disenchanting tech-mechanisms?

This question almost too perfectly leads into what I do everyday. In part, I protect myself by using mymind.com (which I created) — there are no ads, no vanity metrics, no social media features, nothing but myself. Only me and the things I care about. Over the years, mymind has become so valuable to me, it’s the first place I go to look for inspiration. In fact, while I am answering this interview, I find myself going back and forth between old notes and musings inside mymind.

Social media still drains me, just like everyone else, but it’s nice to at least have one place just for myself. And thats mymind.

Aside from that, I just get offline and out into the world. Or I create something.

Van Schneider isn’t pitching another social layer; he’s describing a private room for memory, taste, and reference.

He later explains where that product idea started:

As with many things, it was a total coincidence. When we initially worked on the mymind product and brand, we didn’t even have the name “mymind” yet. The whole thing was called AWMT, which stands for “As We May Think” and is a reference to an old essay by Vannevar Bush from 1945 in which he wrote about a machine called “The Memex” which was some sort of machine that collects and connects your personal knowledge.

Coming off of that inspiring essay, we came up with a slogan called “Think for yourself” which is sort of the antithesis to the cloud/hive mind of what we call social media today. Especially since we position mymind as a private sanctuary, it just made sense to us.

All of this eventually got me into the rabbit whole to search for ideas for our logo. The classic “Thinker” statue immediately came to mind. I always loved that one, a man deep inside his own thoughts, unfazed by the world around him. But the statue was a bit too literal to me, too well known, too sharp and serious. We needed something more abstract, more playful. Eventually I found out about Cycladic art, originating from the Aegean islands during the Early Bronze Age. Very famous for their minimal and stylized marble figurines. Now, the rest is history. I immediately fell in love with the simplicity of it and it felt like a great canvas to build our visual universe on it. The rest is history (:

Wrobel asks Van Schneider about the conditions he works best under:

The creative me enjoys being alone. Completely isolated, nobody even in the other room. It gives me freedom and clarity to think for myself and be myself. My real creative being thrives in these moments, untouched by the opinions and desires of others.

My ultimate solitude tends to arrive at midnight. It almost transforms me. The dark brings focus. Silence brings new ideas. No voices interrupt, no chance of emails, just me and my thoughts. It’s this time I feel most creatively alive.

Now, add a soundtrack to it and I’m in creative heaven (:

I don’t think every designer needs midnight solitude. But design work does need stretches where taste can form before it becomes consensus. In a work culture that treats collaboration as a default good, that distinction matters.

This is also why the tools question matters. A portfolio system, a private reference space, even a type foundry site are not neutral containers. They either protect the conditions where taste can develop, or they pull the work back toward the defaults of the platform. Van Schneider’s career makes that feel less like a manifesto and more like a working habit: when the available environment makes the work smaller, build a different environment, then keep using it until it changes the work.

Van Schneider’s favorite advice turns complaint into output:

“The best way to complain is to create something” by James Murphy, founder of LCD Soundsystem. It has become one of my guiding principles. It turns useless, negative energy into productive, positive energy.

Design leaders spend a lot of time telling teams to experiment with AI. Nathan Lavertue, a Design Program Director for IBM Z and LinuxONE, turns that advice back on leadership itself:

We spend a lot of time helping designers understand how to work with AI. The question I keep coming back to is simpler. How many of us are doing the same for ourselves in ways that meaningfully support the business?

So instead of just encouraging my teams to experiment with AI tools, I put myself in the work. I built a design program signals website using IBM Bob. What started as a wireframe to sketch out an idea became something I realized I could actually build myself. That surprise is the whole story.

I appreciate the reciprocity here. If designers are being asked to work through this shift in public, leadership cannot treat AI as a strategy deck it reviews from a comfortable distance. You cannot build useful judgment about these tools by asking other people to absorb the uncertainty for you. That is why I’ve been reading about them, writing about them, and experimenting with them on my own. Whether it’s OpenClaw, Hermes, running a local LLM, ComfyUI, or Claude Design, curiosity is key here.

The interesting part of Lavertue’s example is not that he made a dashboard. Dashboards are cheap. The useful part is that he used AI to make a leadership problem legible enough to discuss. His signals site pulled together team health and business impact, then sorted indicators into required, expected, and optional categories so the absence of a signal became something to interpret, not just a blank cell to punish.

Lavertue is clear about this:

I had to remind myself of that more than once while building it. The signals site was useful. Bob was a capable collaborator. But the risk with any tool that comes together quickly is mistaking the build for the point. The site was never the outcome. It was infrastructure for conversations. Design’s impact on the business was the outcome. Keeping that distinction clear required the same discipline I would ask of any designer getting excited about a new tool.

The site did not replace leadership judgment. It grounded it. Instead of reacting to delayed updates or anecdotal signals, I could engage teams with shared context and a clearer ability to look forward rather than back. This was another form of walking the walk. Not just encouraging teams to work differently but building the system that made that work visible and meaningful.

That feels like the better bar for AI-native leadership. Not “leaders should code now.” Not “every management problem needs a custom tool.” The bar is whether leaders are willing to put their own work through the same change they are asking from their teams.