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

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

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

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

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

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

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

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

Celine Nguyen, writing for Asterisk Magazine, questions the promise that taste will protect us from AI. She asks how we acquire taste and why we’d make economic survival its purpose. This is how she describes the tech industry’s view:

Taste, then, is that ineffable thing that makes you, and your business, irreplaceable. It separates the winners from the permanent underclass. It seems to be objectively measurable, or at the very least hierarchical, much like employee compensation or financial capital. To have good taste is to have more of it than other people. But to understand what taste is and how it’s cultivated, we may need to return to an earlier moment in history — when automation led to similar anxieties about human distinctiveness and economic competitiveness.

The promise depends on taste being beyond AI’s reach. Nguyen questions that premise: as literary scholar Leif Weatherby tells her, models already draw on human judgments of taste.

Her history of design education offers another approach. Britain responded to industrial competition by funding schools and museums. She describes how Bauhaus artist and educator Josef Albers taught at Black Mountain College:

The key insight of the Bauhaus’s foundation year was to treat aesthetic perception as a domain-independent skill — shaped by material literacy and craft knowledge, but not in thrall to a particular medium. But the foundation year that Albers brought to America wasn’t just about transmitting a single, preferred form of perception from teacher to student. Instead, students developed a shared “understanding of different ways of seeing and representing” through critiques “coming from the [other] students and then from the teacher.” (These critiques, Albers noted dryly, also “diminish[ed] the tendency to overestimate one’s own work.”) His approach encouraged students to sharpen their “intuitive perception,” and simultaneously practice conveying these perceptions to others.

Nguyen also describes how her interest in Belgian fashion informed her work designing software. She resists reducing those influences to status-seeking or imitation. By the end, she’s asking technologists to reconsider what cultivating taste is for:

Anxious technologists ought to free themselves from tyranny, but that doesn’t mean they need to give up on taste. They may need, however, to reconsider how they pursue it. Our tastes may be personal and idiosyncratic — but they are refined, by and large, when we relate to each other. Explaining our tastes is how we train our perceptual abilities, and our ability to participate in a pluralistic world. It’s a world in which our differences are energizing, not deflating: “The goal,” as the critic Carl Wilson wrote, “is not that we all end up with the same taste.” In an essay on musical taste — republished, years later, as a book with the seductively judgmental subtitle Why Other People Have Such Bad Taste — Wilson suggests that we learn to “relish the plenitude of tastes,” including when someone else’s tastes are “alien to our own.”

It’s true that our tastes can help with minor decisions: the music you listen to in the evenings, the shoes you buy when your Salomons wear out, and when to use an em dash (or, for the advanced aesthetes, an en). And they inform our larger decisions, too: what research problems to pursue, which films get screened, what startups get funded, what features you ship. But the lifelong project of training our tastes might serve a higher purpose than building a personal brand or profitable business. Our tastes are how we understand ourselves — and communicating them is how we understand each other.

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.

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

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

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

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

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

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

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

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

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

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

Two podcast conversations with frontier-lab design leaders on what designing at an AI lab looks like day-to-day. I previously linked to Lenny Rachitsky’s interview with Jenny Wen, head of design for Claude, where she described a redistribution of designer hours: less mocking, more pairing with engineers, a sliver of direct implementation. The activities themselves still look like design.

Ian Silber, head of product design at OpenAI, on Michael Riddering’s Dive Club, describes work that doesn’t fit the same list:

Designers working on this are hopefully spending a lot less time in Figma or whatever tool you use to draw pixels, and more time really thinking about how you interact with this thing, and the fact that the model really is the core product.

Silber’s concrete example is onboarding. Instead of building a first-run tutorial, his team shapes what the model already knows about the person:

We have this super intelligent model that could probably do a much better job trying to understand what this person’s goals are […] We’re really stripping back a lot of what you might traditionally do and trying to say, “Well, actually […] let’s think about like how we should give this context to the model that this person is brand new and they might need some handholding.”

The traditional response adds UI around the problem. Silber’s team takes it out and gives the model enough context to meet the user where they are.

That kind of work needs its own scaffolding, and OpenAI is building it:

We have a whole system called the Dynamic User Interface Library, which allows us to design things that the model can then interpret.

Primitives the model composes at runtime, shaped by system prompts and context rather than drawn flow by flow. Wen is describing a redistribution of designer hours inside activities that still look recognizable. Silber is describing activities that don’t quite have names yet. And yes, that is still design.

Thariq Shihipar, a member of Anthropic’s technical staff, offers a field guide for finding the context an agent needs before and during implementation:

The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run into.

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.

The design-specific version is tacit judgment: criteria that become visible only after there is something concrete to react to. Shihipar’s recommendation is to use prototypes to surface those criteria while changing direction is still cheap.

When I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.

It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code, and it can be more difficult for your agent to revert previous changes.

For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.

This makes exploration part of specifying the work. The prototype helps the designer discover what the brief could not yet contain, while implementation notes preserve the choices that emerge after the plan meets the code.

The better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it’s likely you need to spend more time defining your unknowns or creating an implementation plan that allows for you and Claude to adapt through them.

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix.