175 posts tagged with “process”

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

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

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

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

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

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

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

Neeman on teaching that judgment to a machine:

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

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

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

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

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

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

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

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

Most of the time, intuitive just means familiar.

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

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

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

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

Drew Breunig, an analyst and developer who writes about AI infrastructure, has a name for the slow accumulation of fixes, workarounds, and escalating all-caps instructions that eventually choke an AI application: prompt debt.

The plain-English prompt that makes prototypes effortless turns out to be a poor way to specify how a system should behave, and the bill arrives slowly, disguised as ordinary progress, until the application can barely move. The problem is not any single prompt. It is that natural language was never meant to be a specification language for engineering, and treating it as one quietly caps what you can build.

Breunig’s model-lock-in evidence is the warning sign. A recent Datadog report shows GPT-4o is still the most-used model in observed traffic; Breunig also says multiple large inference providers put GPT-4o and similar-vintage models above 50% of all calls. His proposed escape hatch is to stop treating hand-written prompts as the durable layer:

Every mature engineering discipline eventually stops doing by hand the very thing it once prided itself on doing by hand. Assembly gave way to compilers, hand-tuned queries gave way to planners, and manual memory management gave way (mostly) to machines that do it better. Prompt-writing is no different.

Coaxing the model with exactly the right words is a real skill, and for one-off tasks it’s often optimal. But to build reliable, improvable, and portable systems we should not be hand-tuning prompts.

For designers, the useful warning is not that prompt craft goes away. It is that fragile prompt craft stops scaling once the AI behavior becomes part of the product. If the system has to survive a model upgrade, the design work has to move into measurements and typed specifications: schemas or contracts that constrain what the model can produce and give the next model something stable to inherit.

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

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

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

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

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

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

Nolen Royalty, a software maker who writes at eieio.games, gets at a problem with AI-generated work that shows up before judgment: the effort signal. His examples include tldraw, the collaborative drawing tool, closing AI-generated pull requests, warm-cream Claude websites, and record collecting, but the point is simple. Polish used to be a proxy for care. Now it isn’t.

What software (and writing, to an extent) is missing now is legibility of effort - the ability to tell at a glance whether something took a human meaningful work.

Until recently, “someone cared enough to write this” was an ok heuristic. Plenty of writing on the internet was bad, but you could convince me that you cared about something just by writing it down.

Of course, generating plausible-looking text - or a plausible-looking website - is trivial now.

For designers, that broken proxy is already visible on the surface. We can all spot the default Claude style now, which is funny until you realize that a visual pattern has become an accusation about how much thought went into the site.

There’s nothing objectively wrong with making a website with a warm-cream background and hero text in a sans-serif font with a single accent word that uses an eye-catching color and a different font.

But when I see a website that has the default Claude style I assume that the author put ~no thought into how the site should look. And I often assume that the author didn’t put too much thought into the rest of the site either.

That’s not fair of me! But “someone made this website” is no longer enough to tell me that the website was important to them. So “default Claude style” is one of my new heuristics.

Taste sounds less mystical when you put it this way. A designer doesn’t make a screen human by avoiding beige or picking a stranger typeface. The work is in the decisions: why this hierarchy, why this contrast, why this interaction, why this amount of friction.

The proliferation of digital music and streaming made having a music collection easy and frictionless. And so a subculture evolved to re-add that friction.

And in small ways I think you see the same things happening now.

I’ve seen people joke about adding typos to emails to prove that they wrote them. MS Paint-style image macros read as more human than detailed, funny images (the image could be AI slop). Websites that look intentionally bad are more interesting than websites that look beautifully bland.

The easy story about AI in creative work is that it closes distance: idea, prompt, output, iteration, all compressed. It’s Nice That gets at the more designerly version of that question by putting creative technology’s appetite for “happy accidents” next to design’s need for control:

“From the technology approach, the metaphor I equate it to is the classic ‘happy accidents’ you have when you are in a design tool,” Seth says, finding expected moments of creativity. “The best happy accidents aren’t just between a person and a tool; they happen between people.” It’s perhaps in this notion that co-creation is at its most visible, not in the technology itself, but rather in the conversations and unexpected developments that occur when people with different perspectives work closely together. For Talia, however, this isn’t the case. “Nothing we do is experimental by nature,” Talia says, “everything is incredibly controlled – or, better yet, ‘designed’,” stressing the importance of the role of the designer and the meaning behind design itself. “Design is about creating solutions; there is a sense of control, there is a purpose, there is a function,” she continues, “even the beauty is controlled to a degree.” An example is the generative motion graphics system that Talia created, in collaboration with Mother, for the Crypto coin USDC.

Designer and coder Talia Cotton’s line clarifies the whole piece: “controlled – or, better yet, ‘designed’.” Cotton’s point is that the speed of generation only makes the designer’s eye more important, because someone still has to decide the boundaries before the machine starts producing variations.

Cotton’s USDC system makes that concrete:

Within the visual identity, Talia developed a custom tool that generated guilloché patterns, in reference to the historical patterns used in traditional finance. Alongside set, systematic parameters – including height, width, density, and speed – Talia had to create algorithmically constrained rules within those limitations. “As you adjusted one parameter, another parameter would automatically change its available range,” Talia says, “that ensured every possible output looked good.” As Talia suggests, especially considering the ease with which people can generate things, the “designer’s eye” is now more important than ever. “The designer’s job is to create an airtight generative system that considers every possible case and every possible output,” she says, “so that every single output always looks great, no matter how different it is.”

Karo Zieminski, in her newsletter Product with Attitude, is writing for builders, founders, and PMs, but the design translation is straightforward: AI fluency without critique is just a faster way to lose your ability to evaluate the output for yourself.

She draws the distinction:

Plain AI literacy means knowing how to use AI tools. It means learning to prompt, create automations, and bring AI into your workflows.

Critical AI literacy goes further. It adds systems awareness: understanding that AI is not just a tool on your screen, but part of a larger system of model choices, product decisions, business incentives, policy constraints, ethical tradeoffs, and human consequences.

Attitude is the posture that turns AI literacy into critical AI literacy.

That word, posture, matters. It is the same split in not outsourcing the learning: the tool doesn’t determine whether you get sharper or softer; the way you use it does.

Zieminski puts research behind that concern:

The data is on the table now. Microsoft Research surveyed 319 knowledge workers in 2025 and found that higher confidence in the AI is associated with less critical thinking, while higher confidence in yourself is associated with more. MIT Media Lab’s “Your Brain on ChatGPT” study measured the same erosion at the level of brain activity. The muscle is real, and it atrophies on schedule.

For designers, the warning is: don’t let the tool do so much of the looking, choosing, and checking that you stop building those muscles yourself.

Zieminski defines the working posture plainly:

AI with attitude means using AI with judgment, boundaries, curiosity, and scrutiny. You enjoy powerful tools without worshipping them, panicking about them, or letting them decide how you think, work, create, and learn.

Sen Lin, writing in UX Collective, has a useful reference for designers who want Claude Code to fit their workflow instead of acting like a generic engineering agent:

Claude Code is an agent, and an agent is only as good as how you configure it. That’s the part worth paying attention to as a designer: Out of the box it leans engineering, but you can set it up to fit how you actually work — to understand design, respect your workflow, and carry the right capabilities — so it produces better results, faster.

A technical stack is the set of technologies you decide on before writing a line of application code. A design stack is the same idea, applied to Claude Code: the brief, the design knowledge, and the tools you hand the agent upfront.

The useful move is treating Claude Code setup as a design operation, not a prompt-writing trick. Give it a project brief, a design-system guide, and the right tools before it starts touching the work.

If CLAUDE.md is the brief, DESIGN.md is your design system translated into something an agent can read and obey. It’s a format specification that describes your visual identity to a coding agent: the exact values, and the reasoning behind them.

The file works on two layers, and both matter.

The first is machine-readable design tokens, written as YAML front matter — the exact values, so the agent never has to guess what gray-500 resolves to or which surface color a modal should use: […] The second is human-readable design rationale, written as prose — the part that explains why a value exists and how to apply it. Tokens tell the agent what primary is. The prose tells it there should never be more than one primary button per view, that a primary action is always paired with a neutral or subtle one for cancel, that button width is set by the parent and never hardcoded.

The tool/instruction split is the part worth saving:

MCP gives the agent access to tools.

Skills give it the knowledge to use those tools well.

Where MCP is access, a Skill is a markdown-based guide that teaches Claude how to perform a specific task in a specific way. It’s a set of instructions, scripts, and resources — a training manual that keeps the agent from wandering down expensive detours and burning tokens on the wrong approach.

Good checklist. The designer’s job is not just to ask Claude Code for UI. It is to onboard the agent into the product, the design system, and the working style before generation begins.

Designer and writer Christopher Butler is writing about AI, but this also lands on the mechanics of agent loops. A loop can keep running, but useful output still depends on the constraints, preferences, success criteria, and taste made explicit before it starts.

Butler, on what stays human:

The more interesting situation is the one where we keep the thinking and hand off only the doing — and what happens when we do.

What happens is more than speed. When you have to describe what you want to the agent — with enough precision that what comes back is what you actually wanted — you begin to think about the thing differently. Description, it turns out, is where the idea often actually gets made. You start by knowing roughly what you want, and the act of articulating it produces a clearer want, which produces a sharper specification, which produces a better thing. Then you do it again. The thing improves; so does the thought.

That maps to the AI bottleneck I keep seeing: production speeds up, but judgment still happens at human speed. Butler isn’t arguing for slower tools. He’s arguing that useful AI makes the thinking more explicit, not less.

The friction is part of the point:

The agent’s current maturity requires a level of input precision that a competent colleague does not. At first, this can be a frustrating blocker; we’ve depended upon a different kind of intelligence in our peers — the kind that requires no elicitation. The machine does. But in a sense, this is a gift. It forces you to think the thing through in places you might otherwise have left fuzzy.

That’s the designerly translation. The machine doesn’t infer your hierarchy, tone, edge cases, or tolerance for risk unless you put them somewhere it can use. That friction is useful because the agent forces you to specify the fuzzy parts before it starts generating the same mistake everywhere.

Butler’s word for that retained work is investment:

This system depends upon me to provide the thinking. The agent does the doing. The structure is, I think, the practical form of the argument: the systems carry the doing, and they carry it well precisely because I have spent the time to think them carefully through. We like to call this intellectual property, which I think is a bit obnoxious. It’s really intellectual investment. Every technological advance should be measured not by the measure of intellectual property it absorbs — how much it can do without us — but by how much intellectual investment is worth sowing in it.

That’s the useful correction to “AI will do the work for us.” It will, but only the part of the work that can be expressed well enough to delegate. For a design system, that means brand rules, component logic, editorial standards, and good taste have to become rules, prompts, specs, tokens, and checklists the agent can actually use.

That leaves the tool in its proper place. Using AI lazily will produce plenty of forgettable output. The more interesting use treats it as a medium that rewards the thinking you put into it.

Of course, there is tension between expressing our specs as words and spatial manipulation as visual thinkers.

Claire Vo on her How I AI podcast gives a plain-language walkthrough of agent loops in Claude Code and Codex. The episode is technical, but the useful translation for designers is familiar: define the job, give it tools, decide what good output looks like, and make the system prove it. Once an agent can run without you, the interface problem moves into instructions, permissions, and checkpoints.

And then a couple other foundational things that I think are helpful when you’re running loops. And why are these things helpful before we get into what they are? They just keep the work clean.

If you are going to be yolo-ing loops all over the place, you’re going to want some consistency in execution, you’re going to want clean workspaces, you’re going to want conflicts resolved and avoided. And so, all these things are really to make those loops effective.

And so, what are the things? They are work trees. I feel like this entire podcast could be Git 101. But work trees are just basically a way to isolate the work, especially the coding work of an agent away from other agents’ work in a sandbox. There are skills, repeated ways to do common tasks. We have a full episode on what skills are from earlier last year when they came out. Plugins and connectors, these are just the tools that your agent has access to. […] Sub agents, both Codex and Claude Code allow you to kick off sub agents. This is just a way to federate out work from the main thread, so that sub agents can do specific tasks, especially validation. And then there’s some way to track state. And essentially just think of this is like a to-do list.

The practical translation for agent orchestration: write the operating conditions around the work before asking for the artifact.

Calling it a loop makes it sound like automation plumbing. The design work is the brief: what the agent can touch, what tools it can use, and how it knows it is finished.

The employee comparison makes the loop feel less exotic:

Now, people are going to ask, “What should I use a loop for?” And when you’re designing loops or designing agents, I say this is the time for the manager. You are designing a job. And so, just imagine that you’re onboarding an employee. That employee could be an executive assistant. That employee could be a customer service agent. That employee could be a software engineer.

Every Friday, EA, I would like you to review my calendar, see who canceled on me, where I could have used my time more effectively, if there are any follow-ups, and send me a Slack to get this done. Um and I want you to do that every Friday. Guess what? You’ve just designed a loop for your executive assistant. […]

So, I really like to think about loops as designing workflows and designing jobs to be done for people. It just happens to be that you can put this intelligent agent against the loop, and then it’s ready to go.

For designers, that last sentence is the translation layer. A designer already knows this move from creative direction: clear constraints produce better work than a blank request. The only difference is that the worker now happens to be software.

A loop without success criteria is just a faster way to make someone review the same ambiguity at a higher token cost.

We all want our agents to work for us on a schedule whenever we want, doing work that we don’t want to do. It’s great. What are some of the problems? One, loops can get expensive. So, I just kicked off an automation that happens on a regular basis. It does wide-ranging work. It decides when to spin off sub agents.

And it does loop-based validation, which means it’s burning tokens until it hits a threshold that it decides is successful. If you do not write that loop well, or your validation criteria is too thin, guess what? Your agent is going to burn tokens. I think we’ve seen this with open claw in particular or some of these agent harnesses is they’re really good at loops. They’re very diligent. They get interesting work done, but man, do they love to burn tokens.

[…] Loop-based prompting is just its own thing. Goal-based prompting in specific is just its own thing because you have to be very precise about evaluation and success criteria. If you are not, you will be very disappointed and use a lot of tokens for not a lot of output.

Jenny Xie, writing for Figma, talks with Vice President of the Pantone Color Institute Laurie Pressman about color as a cultural language, not a decorative layer. Pressman’s starting point is that color is read, not just seen:

Color is tied to our emotions and how we interpret the world. It’s a language that reflects what’s taking place in culture.

The practical questions Pressman gives designers are “What message am I trying to convey?” and “how do I use color to help me get there?” That’s the design-system version of brand strategy: what does this choice need to make legible before anyone reads the copy?

Xie follows that with examples where the same hue changes meaning across cultures, media, and materials:

Like any language, the language of color comes with its regional dialects. While black is worn at funerals in the West, mourners in the East wear white. Depending on the context, red can convey love, anger, or urgency in the West; in the East, it’s associated with luck, prosperity, and celebration. Brand and marketing teams can’t just follow color trends or assume universal meanings. “Someone seeing a product on the shelf in Japan versus France is going to have a different color sensibility,” says Laurie, “because they’ve built up certain associations.”

Pressman also brings this back to process:

Colors don’t exist in a vacuum. They show up differently depending on the material, medium, or surface. Something that resonates on a screen may look garish in person; a hue that exists in fabric dyes may not be achievable on, say, a Band-Aid. “This is why you must consider color at the inception of the design process,” Laurie advises, “so you can make decisions with full context of the material and surface finish on what it will appear.”

There are two versions of the same design-systems worry. One is about craft: AI can make an interface look considered without teaching anyone how the system works. Design-systems expert TJ Pitre pushes on the governance version: once the system is machine-legible and agent-friendly, who owns the calls the machines are allowed to make?

So when I say I have a beef with “agentic design systems,” understand that it isn’t a beef with agents. It’s a beef with one specific move that the term smuggles in, and that most people repeating it haven’t noticed they’re endorsing.

Here’s the move: handing the judgment layer of a design system to an autonomous agent loop that no human owns.

That’s the whole problem. Everything else is just tooling, and the tooling is great.

Design systems as AI infrastructure only works when the infrastructure still has an owner. Make the system machine-readable. Let agents generate, document, test, and check against it. But Pitre is correct that the library is only useful if the standards still have an accountable owner.

Strip away the Figma libraries and the Storybook instances and ask what a design system actually is. It’s a set of decisions an organization has agreed to and committed to enforcing over time. What does “primary action” mean here. When do we break our own grid. Does this thing deserve to exist as a component at all, or are we about to enshrine a one-off into the canon forever.

Those aren’t generation problems. They’re judgment calls, and they carry consequences the organization is accountable for, to its users, its engineers, its brand. A design system is, underneath all the tooling, a way of encoding collective judgment and holding people to it.

Pitre turns that into a test:

Which gives you a clean test for any “agentic design system” claim you encounter. Ask: what rejects the agent’s output, and who decided the rule it’s being rejected against? If the answer is a human-owned gate, it’s the real thing. If the answer is “another agent checks it” all the way down, you’ve built vibe coding with extra infrastructure and a more confident logo.

And that version is arguably worse than a person vibe coding in a scratch repo, because it launders drift through the authority of the system. The output looks sanctioned. It came from “the design system.” Nobody chose it.

In the end the invisible hand of the designer must still be felt.

Murphy Trueman isn’t worried that AI makes bad design. She’s worried that it can make passable designs, enabling designers to bypass contact with the material that teaches them how systems actually behave:

UI is starting to feel disposable in a way that unsettles me. Not as a complaint about quality. Structurally.

The pace of generation means nobody dwells in a screen long enough to notice whether it’s actually considered or just plausible, and plausible is increasingly good enough because the bar for “does this look designed” keeps dropping when the tools do the designing. The decisions are still there, technically, but the attention that turns decisions into craft has somewhere else to be.

You can produce a lot of considered-looking work without any of it being considered.

This is the craft problem hiding inside the productivity story. The danger isn’t only that teams will ship screens faster. It’s that they may lose the habit of noticing the small decisions that make an interface hold together after the first glance.

Trueman gets more specific about what Figma gave her:

But the specific thing that made Figma matter to me wasn’t efficiency. It gave me a way to hold abstract structural ideas in my hands — the relationship between a component and a style, between a token and a decision, between a change made in one place and every instance that inherits from it, made visible, made editable, made something you could touch and understand by touching it. That’s how I learned to think about the work.

That’s the part I don’t want AI tools to flatten. The best design tools don’t just make results; they make relationships inspectable. You learn by manipulating the system, getting it wrong, and seeing which decision moved. Difficult to do in code and see it cascade in the product.

A Singaporean software engineer who goes by Airing is writing for devs who can already see the AI curve from inside their own work: docs, code, review comments, all moving faster than the human capacity to verify them. The design translation is pretty direct. AI changes who can produce, but judgment stays human, and the more production accelerates, the more expensive weak judgment gets.

Over the past year, every piece of my work that I could hand off, I handed off to AI, piece by piece. The design doc — it wrote. The code — it wrote. The first drafts of documents and review comments — it wrote. What I can now run in parallel in one evening would have taken a full quarter two years ago. By rights I should be idle, but the truth is the opposite — I am busier than I have ever been. The content of “busy” has simply changed: I almost never produce anything with my own hands now. I spend the whole day reviewing what it produces.

This is the embryo of the end-state workflow. In it, there are only two things left for humans to do: review the design, and verify the result.

Notice what these two have in common: neither of them is production. They are gatekeeping.

That changes the clock as much as the craft: more time spent checking outputs, less time making the first pass by hand.

That gatekeeping word applies to designers too. When AI can generate the interface, the screen, the copy, and the prototype, the remaining work is deciding whether any of it should exist in that form. Airing says the temptation is simple: “lower your own standards.”

Read one fewer line of code. Skip one step of reasoning. Don’t ask one of the “whys.” When the little voice in your head says “eh, probably fine,” nod and let it pass. Project this forward and you can already predict the next few years: nearly every collapse in engineering quality will not be because one specific person was lazy — it will be structural. When production is infinitely fast, the verification standard becomes the only compressible variable in the system, and every incentive in sight pushes you to compress it: the boss’s expectations, your peers’ speed, the performance-review whip — they’re all telling you to let go.

But think clearly about what letting go means. The reason you have not yet been optimized away from the verification step is precisely that your standard is higher than the machine’s. A gatekeeper who keeps lowering the standard is personally building the case for their own replaceability. My stance on this has never moved: slower is fine. The standard, not one inch.

Airing refuses to make this only a productivity story. The professional risk is cognitive atrophy: forwarding the problem to the model, forwarding the answer back, and losing the stretch where judgment is formed. For designers, the warning runs through the same place: don’t outsource the taste-building, the principled refusal, or the logic of why a thing should be this way and not that way.

A real question, most of the time, does not have a deterministic answer. Cognition does not fall from the sky. It is ground out by humans through derivation, argument, and exchange — bit by bit, through a process that cannot be skipped, because that process is the human. If cognition is handed to you directly by AI — whether or not it is comprehensive, whether or not it is critical — the mere absence of that middle stretch of thinking is enough to let subjecthood retreat, inch by inch, until what is left is the silhouette of someone waiting in front of a Jenny to be retired.

AI cannot replace humans in perceiving and experiencing the world — and this isn’t a pep talk; it has a structural basis. I wrote, in an earlier essay on AI and psychological healing: human cognition is not just information processing — it is an experience interwoven from sensation and emotion. We perceive the real world through our bodies; we assign meaning through feeling. AI is unmatched at processing information and generating text, but what it lacks is precisely this dimension of experience — it can process data, but cannot experience the real world that the data represents. In one line: AI’s understanding is instrumental, not existential. It can help us understand certain facets of the human condition, but it cannot replace the insight we obtain through lived experience and inner reflection. A painting can imitate nature, but it can never become nature itself.

The reed’s entire dignity is in its thinking. Please do not hand it over.

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.

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.

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.

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.

Fulya Lisa Neubert, writing for the Slack Design blog, starts with a familiar design handoff problem:

For most of my design career, Figma was where the real work happened. I’d design screens, build prototypes, then hand off the designs for someone else to build. If something felt slightly wrong in production, we’d go back and forth trying to articulate what “it should feel like” in words. This process worked well enough, but there was always a gap between what I could show in a static design tool and what someone would actually experience in the product.

The piece gets concrete when Neubert moves from screens to Slack search. She points to a kind of interaction where static prototypes can suggest the flow, but can’t prove whether the experience works under someone’s hands:

The search experience in Slack is a deeply keyboard-driven feature: typing states, focus management, the way content scrolls and reflows as you interact. These are things you can sketch in Figma and even prototype to a degree, but a Figma prototype can’t tell you whether the focus ring moves correctly between elements when you press tab, or whether a scrolling gradient feels right as content overflows. You need to actually use it.

I don’t read this as an argument that designers need to become frontend engineers. Neubert came in with the basics and figured it out:

I came into this with basic HTML and CSS — enough to roughly understand what I was looking at, but not enough to write it myself. That turned out to matter less than I expected. The first time I described a focus interaction in plain language and had a prototype working in minutes, I stopped thinking of code as someone else’s territory. […]

My setup is fairly straightforward. Cursor is my main environment. I use Figma’s MCP integration to pull in components I’ve already designed and Slack’s design tokens, so I don’t have to rebuild spacing, color, and type from scratch every time. I tried working directly in Slack’s codebase — years of accumulated complexity that made every small change feel like a bigger undertaking than it needed to be. […]

The Figma integration matters because the prototype isn’t starting from a blank toy environment. It pulls real components and tokens into a lighter workspace, which makes the thing shareable without pretending to be production. For Slack search, that means the team can review behavior instead of debating screenshots.

Neubert is also clear about the tax:

AI also doesn’t always preserve what you’ve already built. You prompt it to change one thing, and it quietly breaks something else. If you’re not testing after every turn, you won’t notice until you’re sharing the prototype with someone — or worse, presenting it — and that’s when you realize something’s broken.

That is the right caution. AI changes the distance between intent and working behavior, but it doesn’t remove verification. If anything, it makes the habit of testing after every small change part of the design process itself.

Dan Carey leads product at Anthropic Labs, the team behind Claude Code and Claude Design. In a talk on how a three-person team shipped Claude Design in ten weeks, he describes what happened to everyone else after their engineers got fast:

And so once Claude Code took off, the bottleneck moved. The bottleneck moved from building the feature to figuring out the right things to be building for your users, in a lot of cases. So the option was either skip those early steps, just try and decide on the fly, and potentially build the wrong thing really fast, or try to find ways for the rest of us to speed up. So our designers, our PMs, were having trouble keeping up. We needed our own accelerator tool.

Carey just relocated the bottleneck onto the exact work designers and PMs own: figuring out what’s worth building. That’s product discovery becoming the real constraint. When building gets cheap, what’s left to get right is the decision about what to build at all.

How does the team make that call? Not by writing it down:

So we like to use prototypes because documents are imprecise. It’s so easy for two people to look at the same doc and have two different products in mind about what the experience should be. […] Prototypes are more concrete, more visceral. They let you get hands on with the thing and really feel the experience yourself.

They skipped the PRD and the vision docs entirely. A working prototype immediately aligns people, and it doubles as the discovery tool: you build the rough thing to find out what the right thing is.

And it helped that the team was small enough to skip coordination entirely. Here’s Carey:

Everyone on the team does everything. The engineers talk to users, PMs write code, designers do data analysis. All of these things are enabled in part with Claude. And the lines between the roles on this team, they have essentially dissolved at this point. You do have your specialization, you do have the unique perspective and diversity that you bring to a team, but at any moment, any one of these people on this team can talk to 10 users, you can realize what the underlying problem is, you can design a solution to it, you can ship it to users, you can listen for feedback, you can keep iterating solo if you need to.

On Carey’s team, the designer who spots the problem also builds the solution and ships it. That’s the kind of role a lot of designers are now being asked to grow into, and it looks less like a handoff between specialists than one person carrying an idea from problem to finished screen.

Speed doesn’t guarantee you build the right thing, though, and Carey is candid about the team’s misses. They built a set of advanced, fine-grained controls for power users. A few vocal testers loved them—I know I would have. But the usage showed everyone else hated them, and the team pulled the controls in a week. Two lessons came out of it:

So this taught us a couple of things. One, this taught us that we should be a tool that lifts the level of craft for everybody, not just the ceiling on power users. It also taught us that we want to be as open as possible, because there will be users that we never meet the full needs of. There’s going to be some power user out there who wants to do something very specific that we’re not going to support. And that’s what convinced us that we wanted this to be a very open tool. That’s why if you export from it, you get HTML, CSS, JavaScript.