Roger Wong - Design, UX, AI, Technology

How retro branding is bringing warmth and fun to São Paulo’s bars and restaurants

Wed, 07 Oct 2026 15:00:00 GMT

I was lucky enough to spend some time in Brazil a few weeks ago, including two days in São Paulo. What a lovely, vibrant city.

Elaine Ramos in It's Nice That profiles the graphic design scene in the city. One of my favorites from her article:

…the identity created by Sarau for Bar Ovo in 2024 draws directly on lithographic labels – especially cachaça labels – matchboxes and other packaging, and advertising from the first half of the 20th century, with its profusion of frames, shadows, and line gradients. Pedro Almeida, one of Sarau’s partners, tells me about the reference in the original brief – the collection of chickens that inspired the owners to name the bar – and their concern with giving it the feel of a Brazilian boteco, an unpretentious neighbourhood bar (hipsterism by the book…!).

As the largest metro in the Americas, São Paulo is sprawling and constantly building. More business-focused and forward-looking than its older rival, Rio, this city is about progress over preservation.

Ramos again:

This nostalgic wave is neither new nor unique to São Paulo. Much has already been said about hipsterism and its endless pursuit of the genuine, the local, and the organic, only to be quickly absorbed into the mainstream. But in a city averse to any notion of preservation, shaped not only by rampant real estate speculation but also by a deeply rooted culture of constant renovation, where only a handful of bars have survived for decades largely unchanged – the truly authentic ones – this emulation of tradition takes on an ironic edge.

Graphic designers are left with the difficult task of manufacturing the signs of authenticity and symbolically reconstructing the memory erased by this constant transformation, giving each new bar a distinctive character that can attract its audience and restore something of the affective life and sense of belonging the city has swallowed up. Luckily, some designers are finding inventive ways to do that.

Read the full article →

Design Systems for AI Agents

Tue, 06 Oct 2026 15:00:00 GMT

Luke Wroblewski gets at something that's been gnawing at me for years: Figma as the source of truth gets stale as soon as it's handed off. The code, the final user-facing screen in the browser or on their device is the source of truth.

I've seen the same pattern play out... design teams invest a lot of time in creating a system, then struggle to keep it up to date as the actual product evolves. Inevitably the design system ends up describing a product that no longer exists.

But now with AI agents, he argues, there's another way:

When agents write most of the code, the design system can become part of what I've called the AI steering layer: the context that keeps every website update aligned with brand, design, and development guidelines. Put simply, a design system for agents is a steering layer for a site's design and front-end code.

With AI agents, anyone on a team can update a website. Marketing adds landing pages, engineering adds docs, a PM tweaks the pricing page. Each of their agents will happily implement its own tone and voice, colors, spacing, etc. unless something steers them toward a unified whole.

That's the case for collaborative steering. A design lead and front-end lead define the grid, fonts, colors, spacing, and components once, and everyone's agents are "snapped to" it. The team keeps shipping and the site keeps its integrity.

Agreed. It's DESIGN.md and other related brand, style, and design system context. Still need a design system though and shared components that live in the code.

Read the full article →

The death of web development education – Rescuing a field from disappearing

Fri, 02 Oct 2026 15:00:00 GMT

I've long seen software development as the canary for AI. Mathia⁠s Schäf⁠er details how the web dev education industry—books, courses, YouTube channels for building websites—has essentially been wiped out. Quoting developer/educators like Baldur Bjarnason, Salma Alam-Naylor, and Josh W. Comeau, there's an air of defeated bleakness because people are turning to LLMs for answers and for coding itself.

Bjarnason says the "demand for web dev ebooks had cratered." Alam-Naylor concurs, putting the blame on the training data used for LLMs:

The future feels bleak for educators. Rich curriculums we craft intentionally and carefully for real human audiences are now routinely stolen and regurgitated by predictive algorithms. The Chat Bots, with their sycophantic tone of voice, are deliberately engineered to erase our own personalities, hard work and craft entirely from the equation.

The only conclusion I can draw from this is that my experience, skills, empathy and teaching expertise no longer hold the value they once did in this volatile industry (if they ever really did?).

Schäf⁠er spends 90% of his essay laying out how the industry's been decimated. He tries to end on a positive, or at least, supportive note saying:

I just believe in a resilient web that is not that easy to lock in a cage. To rebuild the field of web development, it requires a network of people who support each other, get a grip on web technologies, dig out best practices and establish new ones, and share their insights.

Of course, this decimation is happening in other fields as well. Demand for freelance writing has dropped 30%. Translators have seen their jobs disappear. Chegg, the education company that rents textbooks and sells study help and tutoring, laid off 45% of its staff. I'd always imagined Dario Amodei's bloodbath warning to be about hiring. It is, but it's also about the shifting of work from humans to AI.

In other words, I'm not buying iStockPhoto credit packs anymore because I use Midjourney. So that part of Getty Images's business suffers, leading to lower revenue and potentially layoffs. Or I use Claude Code instead of hiring a freelance developer on Upwork. All these decisions to shift tasks to AI lead to fewer humans doing that work.

Read the full article →

The UX Double Diamond is dead, and in AI only one survives for software | by Patrick Neeman | Sep, 2026 | UX Collective

Thu, 01 Oct 2026 15:00:00 GMT

Patrick Neeman, writing in UX Collective revisits the Double Diamond and design thinking. By going back into history, he argues why the Double Diamond is no longer relevant today.

The Design Council launched the Double Diamond model in 2004: two diamonds, problem then solution, both of equal size. Four years later IDEO’s CEO Tim Brown made the case in Harvard Business Review for Design Thinking as the process, putting designers and researchers at the start of innovation and at the start of the investment cycle, not the end.

Despite Fortune’s claim that IDEO invented human centered design — I even hesistate to link to it from here for obvious reasons—the movement started with Herbert Simon, whose 1969 The Sciences of the Artificial proposed the science of design thinking, and it was built out at Stanford, where Rolf Faste ran the design program before David Kelley took it to IDEO. The Design Council drew the shape for the other.

[…]

The lineage holds more names than Simon and Faste. Robert McKim published Experiences in Visual Thinking in 1972 while teaching at Stanford, Faste expanded that work into the 1990s, and Kelley founded IDEO in 1991. The first prominent book carrying the term was Peter Rowe’s Design Thinking in 1987, about architects and urban planners.

Notice what those people had in common:

Simon wrote about engineering and administration

Faste taught mechanical engineers

Rowe was writing about buildings and urban planning

None of them were building software

Every founding discipline made things that were slow, costly, and impossible to take back, and the method inherited their constraints along with their rigor.

That's always been the crux: designers and designing is cheap; engineers and engineering is expensive. So spend more time on research and design before committing to coding the thing. But as Neeman writes, prototyping three things in an afternoon with AI is now trivial:

At that price [an afternoon] you stop debating which of three directions is right and build all three, because the debate costs more than the answer.

This gets at something I think a lot about from my time at Apple—creative selection, or exploring all the possibilities to discover the right solution. It's now made a lot easier with AI.

Read the full article →

A 25 Year Collaboration: Wilco & Lawrence Azerrad

Wed, 30 Sep 2026 22:00:00 GMT

As a young designer who was really into music, designing album covers was always something I really wanted to do. I had always admired the surrealistic work of Storm Thorgerson for Pink Floyd or the moodiness of Vaughn Oliver's work for 4AD. I had fun in art school designing mixtape covers, but that was the closest I'd ever gotten to creating cover art.

Fast-forward to 2001 when Wilco released their now-classic album, Yankee Hotel Foxtrot. You know the cover, a mostly empty beige square with twin scalloped-sided towers rising from the bottom in black and white. That photo by Sam Jones of the Marina City apartment buildings in Chicago—the band's hometown—combined with the lyrics from "Ashes of American Flags" indelibly captured the mood of America still reeling from the 9/11 attacks that happened two weeks prior. The band nor the album cover designer could have anticipated the coincidence.

Through twists and turns, the release of the album was digital at first. Wilco's label rejected the album so the band left the label, negotiated to get the rights, and released the album themselves. They streamed it first on their website before being signed onto another label and having a retail release the following spring.

When I got the album, I pored through the credits and spotted the name of the designer: Lawrence Azerrad. I was pleasantly surprised and shared it with my colleagues at the time, for Azerrad, like me and most of my designer friends, was an alumnus of California College of the Arts. He was in my graphic design class.

Azerrad and I reconnected years later. For a design conference in Chicago that I was co-producing, we held a session at Wilco's Loft, their home base and studio. Certainly one of my dreams come true!

What surprises me and what I admire about Azerrad and his work with Jeff Tweedy and Wilco specifically, is how much it's not about him. I remember him telling me about sessions where he'd just set up his computer as the band was rehearsing or recording, and they'd jam while he designed. Tweedy would come in, give some feedback, and they'd jam on the design together. Rinse and repeat. The way Azerrad designs these covers, it's more like he's channeling the artist's creative energy, and their collaboration is the output.

Rachel Cabitt recently interviewed Azerrad for the 25th anniversary of the album's release. He says:

…as our connection to culture becomes more digitized, as AI plays a bigger role in our lives, and as discovering music and art through our phones gets almost effortless, it's on creatives to find new ways to stretch toward deeper connection, to provoke more awe and wonder, not less. Because art, in all its forms, can get us to think more deeply about who we are, what we're doing with our time here, and what we want to leave behind.

Right on.

Read the full article →

AI Discourse, Writing, and Me

Mon, 28 Sep 2026 15:00:00 GMT

I’m tired of the discourse. The more I read about how AI disrupts the way we design and build software, the less I want to read and write about it. (Yes, ironically, this is about AI.)

It’s not that there aren’t interesting things happening—there are. Jev, Muse, Grok Bot, Siri AI, continuing revelations about rogue OpenAI swarms. There’s a lot.

However, I think we’ve turned the corner. AI is here to stay, regardless of whether the frontier gets paced or not, or whether data centers continue to proliferate. The models we have today have forever changed how software is made. At this point, I believe the sea changes that have been happening every two to three months have slowed. With each new model release, they might be getting faster, more intelligent, and able to perform longer-running tasks. But the major shifts have already happened. We have agents writing code, creating mockups and prototypes, doing research, and autonomously fixing bugs. Improvements will be more of the same.

For designers and product managers, it’ll be dispatching agents to take on work and then reviewing their work. I already see this on my company’s Slack using the Claude Tag. Everyone in EPD just @mentions Claude, “Fix this” and the agent dutifully does it. How fast a company can build depends on the token budget and human review bottleneck.

So the recent discourse gets more fine-grained, no longer about big shifts, but about tweaks and edges. The same topics seem to come up over and over again: design system + AI, prototyping + AI, should designers code, the bottleneck is the PR, etc. And I recently noticed that the LinkedIn posts, Medium articles, and Substacks just sound...the same.

It all has a sparkle-dusting of Opus or Sol with odd sentence constructions and overused phrasing. You recognize the phrases and words: worth, load-bearing, distinction, the X that does Y.

Mea culpa. I’m guilty too. I’ve been using AI to help me write for over a year. At first it was just a couple paragraphs here and there. But then I built a whole sophisticated writing harness to generate text that sounded like me. The flow was:

I pick the links
I add a directional note for my agent
The agent reads the article
The agent drafts the link commentary based on my direction
I tweak
The agent publishes (tags, slug, related posts, alt text)

I was fanatical about trying to catch anything that didn’t sound like me or sounded too much like AI. Here is a snippet from my very comprehensive review skill:

### Category 3: AI Writing Patterns (MUST-FIX)

10. **Structural tells.** Flag:
    - Antithesis: "It's not X, it's Y" / "The value isn't X; it's Y" — single strongest AI tell. Dan Shipper himself called this out in *The AI Sandwich* ("AI writing that reads like 'It's X not Y'"). Flag every occurrence.
    - **"The [noun] worth [verb]-ing" family** (pundit zoom-out). Flag: "the line worth keeping," "the argument worth having," "the part worth sitting with," "the question worth asking," "the distinction worth drawing." This construction zooms out from a concrete observation to a pundit-style abstraction. The reader expects a specific claim; instead they get a meta-statement about which claim deserves attention. Fix: state the concrete observation directly. "The line worth keeping is X" → "X." or "[Author] is right that X."
    - **"Lands"/"land"/"landing" as verb of arrival.** Flag: "[Author] lands the talk on craft." "That is where I want to land it too." "The piece lands on a different note." Distinct from the dramatic-impact "this lands hard" already flagged below — this one uses "land" to describe an argument's arrival point. Fix: "ends on craft" / "settles on craft" / "the piece closes with."
    - **Cute transition metaphors.** Flag: "from a different angle," "from a different door," "coming at it from another side," "approached from the other end." These present the same observation as a clever shift in vantage. Roger's voice doesn't perform vantage shifts; he just states the observation. Fix: cut the transition phrase; lead with the observation itself.
    - Fragmented rhetorical questions as dramatic punctuation: "The user? Secondary."
    - Dramatic impact phrases: "This lands hard." / "This hits different." / "That last line lands."
    - Clever zinger closers that sound like a copywriter, not Roger
    - Mid-sentence rhetorical question then enthusiastic answer: "And honestly? That's amazing." **Exception:** direct-address conversational turns at the start of a paragraph or before a plain restatement ("Interesting, right?", "You see...", "Wild, isn't it?", "Stop me if you've heard this one before...") are Roger's voice per the style guide (Section 5 — The Direct Address Turn) and should NOT be flagged. The flag targets enthusiastic self-answered questions ("And honestly? That's amazing."), not direct-address turns that invite the reader in.

Building this taught me a lot about agent skills and harnesses. The main harness orchestrated the writing and I was able to fire off 10 posts in a batch. It would dispatch sub-agents with specific jobs like researcher, writer, copy-editor, and reviewer. These were not one-shot drafts, but instead, went through an editorial process where I played the role of managing editor.

The whole workflow took about four hours to run each Sunday. I don’t think I saved much time, if any at all.

More recently I started to tire of the content treadmill. Traffic to this blog is modest at best. My overall goal with writing has never been to build a content business. It’s to have a creative outlet, share what I’m learning, and offer my POV. But it’s so easy to get sucked in and feel like I have to post something, especially when Google rewards regular posting.

I’ve decided to step back and raise the bar for myself and for you, dear readers. There will be fewer posts (still weekly), but hopefully, they’ll be of higher quality with more humanity.

Note: This post was drafted without AI. I had Claude give me feedback but asked it not to write any prose for me. I’m retiring the writing harness, except for the publishing script.

What Silicon Valley gets wrong about taste

Fri, 18 Sep 2026 15:00:00 GMT

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.

Read the full article →

Limit the number of details

Thu, 17 Sep 2026 19:00:00 GMT

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.

Read the full article →

Design’s Legibility Gap

Thu, 17 Sep 2026 17:00:00 GMT

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.

Read the full article →

Invisible Interfaces

Thu, 17 Sep 2026 15:00:00 GMT

The apps are still there. Just a step away, hidden. You ask an AI personal agent to move an appointment or cancel a subscription, and it handles the software for you. Writing in Design + AI, Felix Haas describes what happens to the products that are hidden away:

Watching this happen has clarified something I’ve been thinking about for a while. We are witnessing a new step being inserted in front of every interface we’ve ever designed. In the last years, using software meant going to the software, opening the app, learning its layout, and navigating its particular logic. Now you increasingly interact with one interface that is connected to all the other interfaces, and the moment that layer works well enough, the interfaces behind it begin to fade from view. They don’t fade because they got worse, but because nobody is looking at them anymore.

That is what an invisible interface actually means to me, and it has nothing to do with minimalism or fewer buttons. It means that the interface of the product you built, the thing your team obsessed over and tested and polished for years, basically becomes a back-end, and its primary user is no longer a person but an agent acting on a person’s behalf.

Haas gives the underlying service a design requirement of its own: make its capabilities and current state understandable to the agent. Then he turns to the person delegating the task. They may skip the app’s navigation, but the agent now has access to their money and messages. That makes the handoff back to the person consequential:

So how do you design for trust when there is no interface to carry it? I believe it lives in three places. It lives in how the agent communicates, in its tone, its honesty, and its restraint, in whether it admits what it doesn’t know and asks before it assumes, because every sentence is now a design decision and the conversation itself becomes the brand. It lives in how you show what is happening on the other side, not through a wall of logs but through a considered kind of transparency, the reassuring feeling that the machine’s work is visible whenever you care to look. And it lives in the approval moment, that brief flash where an interface does appear right before an action is taken, carrying exactly enough context for a confident yes or no. As the interface shrinks, that moment becomes one of the highest-craft surfaces in all of software, because the fewer pixels that remain, the more each one weighs.

Read the full article →

Claude Code’s New Design Plugin Is a Big Deal for Product Designers

Wed, 16 Sep 2026 17:00:00 GMT

A cyberpunk toy-robot landing page gives Nick Babich a test case for the Design plugin in Claude Code. Writing for UX Planet, he starts with /design:design-critique this design, then uses the findings to request changes:

And the nice thing about doing a critique in Claude Code is that you can use a report that AI generated for you as an input. You can provide a follow-up prompt asking AI to fix the issues it found for you.

He narrows the next pass to the primary button with /design:ux-copy primary call to action button:

The great thing about Claude is that it has a project context. It means that it can use the knowledge it has about this particular product and business to find the right words.

Similar to the previous task, Claude generated a nice report with suggested text labels. I can also prompt Claude to change the call-to-action button text to the first option it suggests (Reserve a unit).

I’d check what the button actually commits the customer to before accepting that suggestion. A reservation is a specific promise, and the copy needs to match what happens after clicking.

Babich finishes with /design:design-handoff this design and a warning about what goes to engineering:

Similar to an AI-generated design critique, it’s not a good idea to use a design handoff file as-is without any changes. You need to review the file, validate the information in it, and only after that send it to the dev team.

Take ownership of what the AI generates.

Read the full article →

Design has outgrown the traditional designer

Wed, 16 Sep 2026 15:00:00 GMT

Design educator Michael Buckley, writing for UX Collective, asks design schools to reconsider how they recruit students. He starts with what happens when those students get to class:

I see the mismatch most clearly when students reach the parts of a project that precede the visual work. They may be eager to design screens but impatient with research, resistant to technical constraints, or inclined to treat strategy as documentation to complete before the real design begins. Technology is sometimes learned well enough to operate but not well enough to question.

These reactions are not simply failures of effort. Many students entered the field expecting a professional outlet for artistic creativity. A discipline increasingly concerned with behavior, systems, evidence, and consequences can feel like a change in the terms of that promise.

An interest in making beautiful work is a good reason to study design. But students also need to learn strategic and systems thinking. The school owes them a description of the profession that makes those expectations clear. They shouldn’t have to discover the difference after they’ve enrolled.

Buckley brings the question back to recruitment and admissions:

Changing the curriculum without changing the recruitment pitch leaves that mismatch intact. Programs that present design primarily as a practical outlet for creativity will attract students who expect creative expression to organize the profession. Their frustration is understandable when the education they encounter reflects the realities of contemporary design rather than the false expectations that brought them to the field.

Design programs should therefore reconsider what they advertise and what they evaluate during admissions. A visual portfolio can remain part of the process without serving as the only meaningful evidence of potential. Applicants could also explain how they understood a problem, considered conflicting needs, or changed a decision after encountering new evidence. An imperfect artifact supported by thoughtful reasoning may reveal more than a polished portfolio organized around personal style.

Read the full article →

The point of a system is fewer decisions

Tue, 15 Sep 2026 19:00:00 GMT

When does a repeated element deserve its own component? Anton Sten is using an AI agent to build his design system. He measures its value by the decisions it saves people. Here’s his filter for what belongs:

Lately I’ve been using a simple filter before adding anything to a system. Does it show up often enough to deserve a shared solution? Does it have behavior or states that need to stay consistent? Is there an actual rule here that we want to encode rather than leave to individual judgment? And, just as importantly, is this something someone is willing to own over time?

The third question is the one I keep coming back to. Repetition alone isn’t enough. Something becomes valuable as part of a system when it captures a decision we don’t want humans or agents to keep making independently.

I’d treat the owner question as part of that decision, too. Someone has to remain responsible for the rule as the product changes. Otherwise, the team has standardized something without deciding who can resolve the next exception.

Once a rule is shared, people and agents still need to recognize when it applies. Sten uses token names to show how:

Take naming. green-600 tells you what something looks like. text/success tells you what it’s for. A designer with years of context may know which green is appropriate, and an engineer may remember which one the team normally uses, but an agent only has the system in front of it.

The more intent the system contains, the less any of its users have to infer. Semantic naming is not just a preference in that context; it carries the decision across design, code and the agents working between them. That clarity helps people too, but agents expose just how much ambiguity we’ve historically allowed humans to compensate for.

Read the full article →

I have a software factory, it’s just all skills (you can copy them)

Tue, 15 Sep 2026 17:00:00 GMT

In a YouTube walkthrough, Michael Shimeles demonstrates how a file of instructions coordinates his coding agents. His “software factory” uses reusable skills, each describing how to do a particular job:

I built my own software factory. Now, when you hear that phrase, you're probably thinking of a giant custom harness, and that could be far from the truth. To be frank, a proper software factory is more about your workflow, skills, and domain knowledge more than it is the harness. So, a software factory should be harness agnostic and model agnostic.

The harness is the software that runs the coding agent and gives it access to tools.

Shimeles’s instruction file, AGENTS.md, specifies four stages: isolate, build, prove, and ship. First, each agent gets separate working files and a branch for its task, using Git worktrees. That prevents agents from overwriting each other’s working files, though shared resources still need coordination. During the build, a skill specifies how to organize the code. Shimeles explains:

This is just basically a way I like code to be structured because if it ever come a time where I have to manually review this code like it's 2022 or something then it's written in a way that is easy for me to digest and get used to. Right?

So for the developers you might disagree with a service architecture. You might want it written in a different way. The point for this is get this skill written in such a way where the code written makes sense to you. For me, a service layer architecture makes sense for me.

Then the agent runs checks and captures the changed behavior. For a visual change, before-and-after images accompany the request to merge the code, called a pull request or PR. An automated code reviewer, Greptile, supplies feedback for the agent to address before passing the PR to Shimeles:

This is not getting merged by me until I get a five out of five. So, my software factory will continue to read the feedback from Greile and then will only give me the PR URL once it's got a five out of five. Once we've reached five out of five status, it's my job to look at before and after. It's my job to read the description and then I just merge.

The score doesn’t guarantee correct code. I’d treat the before-and-after evidence as something to inspect separately from the reviewer’s confidence. His shared skills limit the number of review iterations and spell out what’s needed to capture evidence, so there’s setup and adaptation involved in copying this workflow.

Read the full article →

AI Is Making Product Development Faster. But Where Did the Work Go?

Tue, 15 Sep 2026 15:00:00 GMT

Candace Wilson and her design team wanted engineers to reuse the code from their AI-assisted prototypes. The goal was to preserve details that can get lost when someone rebuilds a design. Writing for Bootcamp, she describes what happened at handoff:

By the time development picked up the prototype, something that looked almost finished on the surface could still be difficult to use as a starting point. We had pages that had grown into thousands of lines of code, unclear component boundaries, and sometimes implementations that didn’t match the design intent. A responsive experience, for example, could end up built more like separate adaptive layouts. In trying to reduce the visual handoff gap, we had sometimes created a different problem: an architectural handoff gap. Development then had to interpret, separate, refactor, or rebuild that work before it fit the production environment. Design had moved faster, but some of that effort had simply moved downstream.

This is the double-edged sword with designers using AI to write code. It looks done or good enough to us, but in reality, the generated code might be hiding a bunch of tech debt.

She allows for looser code when the prototype is disposable. For code another team is expected to build on, she proposes a different standard:

Prototype code does not need to be production-ready, but it should be production-useful.

For the kind of handoff I am talking about, that means the code should be structured well enough that development can extract from it without first untangling the entire thing. Component boundaries should be clear. Reusable pieces should actually be reusable. Responsive behavior should match the design intent. The prototype does not need to mirror the production codebase exactly, but it should be close enough that the handoff preserves some of the speed we gained by building in code in the first place.

Read the full article →

AI in product design: Why human judgment still matters

Mon, 14 Sep 2026 15:00:00 GMT

I joined Jason Giles on UserTesting’s Insights Unlocked podcast to talk about AI and product design. The trust discussion drew on a story from BuildOps, where our customer base is commercial contractors. From UserTesting’s episode write-up:

When Roger’s team spoke with technicians about ambitious AI capabilities, the initial response was decidedly practical.

“Just give us the basics first,” Roger recalled hearing. “Just make sure the app is reliable and it’s speedy and we can do what we do.”

Only after those needs were addressed did the conversation shift. When the team described an AI experience that could reduce tedious end-of-day typing, technicians saw the value.

That request for reliability was entirely compatible with wanting to get work done faster. Technicians were spending 10–20 minutes on job notes in their trucks after a day of hard, often sweaty physical work. When my team spoke with technicians, a feature idea came out of it:

From that customer research came an AI feature called Visit Summaries. Instead of typing everything, technicians can press a prominent microphone button and talk. AI cleans up the account and incorporates relevant context about the property, equipment, parts used, and so forth.

The sequence matters. The team did not begin with AI and search for somewhere to wedge it in. It began with observing a person experiencing friction and then finding a way AI could help.

When customers ask us to fix the basics, we should treat that as guidance for what to build next, including with AI.

Read the full article →

The Making of Cursor's Icons

Thu, 03 Sep 2026 15:00:00 GMT

It took Marek Minor about a year to redraw Cursor’s icon system: more than 600 icons in two sizes and two styles, with every exploration and final variant drawn by hand.

The scale only hints at the effort. Minor tested differences as small as 0.25 pixels, made 156 explorations of the hamburger icon, and tracked more than 155 recurring elements and visual properties. He also built the Figma files, migration dashboard, companion site, and release pipeline needed to migrate an old font with 645 codepoints without breaking references. Writing on his blog, he explains the construction method that holds the set together:

The icons in this set are closer to technical drawings than to organic shapes – diagrams with a friendly finish. The construction method is consistent across the set: start with lines that run horizontally, vertically, or at 45°, allow other angles where the concept demands them, then round the corners until the shape follows the idea. A cloud, for example, isn't built from circles. It starts as straight segments that get rounded joins. A fire icon is built the same way, from angled segments with rounded corners. Freeform curves, or curves taken from circles, are extremely rare in the set.

This construction logic is what makes 600+ icons feel like the work of one hand. It also suits a coding tool: precise and engineered, with the rounded corners and round stroke caps keeping it from turning cold.

Read the full article →

The Harness, the Horse, or the Hay

Wed, 02 Sep 2026 17:00:00 GMT

Brett Queener, a partner at Bonfire Ventures, uses “harness” at the scale of an entire product in his newsletter Tales from The Bonfire:

The Horse is the LLM model: enormously powerful, fundamentally unpredictable, not something you command so much as ride.

The Harness is the application layer fitted to that animal for one rider and the entire job that rider does, holding the ontology, the interaction model, and the learning loop.

The Hay is everything the horse and harness need to stay healthy at scale: orchestration, governance, cost routing, security, observability, data infrastructure.

The horse is the AI model. The hay is the collection of services that keeps it running. The harness is the product someone uses for the whole job. It holds what the system has learned about that job: the facts, relationships, exceptions, and rules Queener calls its “ontology.” It also decides which steps need the user’s attention and uses previous results to improve the next attempt.

The developer harness keeps its instructions, tools, and files stable while models change. Queener applies the same principle to an AI business. A company can use cheaper models for routine tasks and save the most capable models for difficult judgment. This keeps its cost of goods sold (COGS) low and protects its profit margins:

First, no smart harness maker will wed themselves to one model provider. Every good CTO I talk to has already abstracted the model away from the product. Not out of loyalty. Out of survival: which model is best changes every 60 to 90 days, and prices move by an order of magnitude.

Portability is also a margin discipline, and it’s most of the difference between the companies quietly running healthy gross margins and the ones complaining in public about COGS. A large share of what runs in production never touches a frontier model: classification, extraction, routing, summarization, retrieval. Reserve the frontier for the hard, ambiguous, high-stakes judgment and send everything else to a pony. Run every call to the biggest model because it’s easier and your gross margin belongs to somebody else’s price list.

The graph describes how jobs and results move through the system. Queener shows that the same graph can serve two roles. An off-the-shelf tool for coordinating any AI system is hay. Once a company fits that coordination to its own agents, rules, and way of working, it becomes part of the harness.

But coordinating the work is not enough. The harness must retain what it learns even when larger customers reach it through another interface, such as Claude, instead of a screen provided by the harness itself. It must also learn from results. Queener calls the tests that score its work “evals.” The system that feeds those scores and corrections back in so future behavior changes is the reinforcement learning, or RL, platform:

It owns the interaction model for that role. Not a chat box, and not necessarily a UI at all. What the rider is asked, what they approve, what they never have to look at again, what escalates and how. Which doesn’t require pixels: upmarket this increasingly gets consumed headless, rendered inside Claude or something the customer built on Vercel. Serve that, but treat headless demand as a scoreboard rather than an architecture, because yours is the surface holding the ontology and the loop and the memory of this rider, so its ceiling should be higher than a general assistant’s at your rider’s own job. The test is what survives a change of surface. Swap the front end next year: if everything they taught the system is still there, you were the harness. If not, you were endpoints with good docs.

It owns the eval and RL platform. The dividing line is whether a graded outcome changes future behavior without an engineer deciding what to change. Everybody has dashboards, and a human reading one and then writing code is a feedback process, not a loop. The test: can you point at a behavior your product has today that nobody on your team designed?

And it is singular. One rider, one harness. Nobody runs three of these at once any more than they drive to work in two cars. Not “fewer apps,” but one, per rider, per job.

Read the full article →

Build a Design OS

Wed, 02 Sep 2026 15:00:00 GMT

Patrick Morgan, writing in his newsletter Unknown Arts, starts with the boundary his system is designed around:

The problem is that prototype code and production code serve fundamentally different purposes. Production code needs to optimize for shipping and maintaining a performant product at scale while prototype code needs to optimize for speed, flexibility, and divergence. I wrote more about this distinction in my article Prototype Code Is Not Production Code (And That’s Okay).

You need both sides of that spectrum to design and ship a good product. A prototype should be able to change direction quickly, without worrying about scale or production constraints, while still benefiting from shared foundations, reusable primitives, and a connection to the product it may influence. So I started looking for an environment with the freedom of a prototype, but enough shared structure for the work to compound over time.

Morgan argues for giving exploratory code enough shared structure that designers can move quickly without severing each experiment from what the team already knows.

As more people used the environment, I started curating more of the context around the work directly into it, including our design principles, personas, and project briefs. As I wrote in AI Needs a Plan, the best agent work usually starts with a written brief, not a one-shot prompt.

By then, the environment had grown from a place to make prototypes into a shared foundation of tools and context that helps people and agents understand how our team designs.

In Morgan’s account, the prototype is not the only thing that compounds. The team’s principles, personas, briefs, foundations, and prior decisions do too, because people and agents can reach them from the same working environment. That shared home is the Design OS: a codebase separate from production where people and agents can reuse the team’s context instead of starting each prototype from scratch.

A codebase gives the Design OS somewhere to live. It lets design intent be shared, connected to other assets, and put into practice.

That has always been possible in theory, but until recently code wasn’t very accessible to designers. Agents change that dynamic by acting as translators into and out of code. They can turn a designer’s plain-English intent into working software, then translate that software back into something the designer can use and evaluate.

This builds on the argument I made in AI Runs on Text. So Should You.: when your thinking lives in plain text, it becomes an asset that both you and AI can read, reuse, and extend. Code just happens to be a more structured form of plain text, which makes it easier for agents to interpret and act on reliably.

The goal here is not to make designers write code. It’s to make design intent executable. When a codebase holds the team’s foundations, conventions, and decisions, an agent can translate a designer’s instructions into working artifacts and carry that context forward. Each new piece of work can then build on what came before it.

Read the full article →

Graph Engineering explained: what it is, when to use it and when not to

Tue, 01 Sep 2026 17:00:00 GMT

A harness is the environment around agentic work: the models, instructions, skills, tools, and files that let agents do the job. A graph describes how work moves through that environment. Anatoli Kopadze, writing an article on X, starts with two familiar parts:

A graph is just a plan for your AI work, drawn out so you can see it. It answers two questions: which jobs need to happen, and which job has to wait for which.

There are only two parts, and getting them straight fixes most of the confusion.

A box is called a node. It's one job: one agent doing one task, with one thing going in and one thing coming out. Researching a competitor. Writing a draft. Checking a claim.

An arrow is called an edge. It just means one job needs what another job produced, so it has to wait for it. And the arrow only counts when something real actually passes along it.

That last condition changes how you design the workflow. A list written as “do A, then B” looks sequential even when B never uses A's result. Kopadze's test is to remove those false dependencies so independent jobs can run at the same time:

Look at the AI workflow you run today and walk it step by step. At each step, ask one thing: does this step actually need the result of the one before it?

If yes, the edge is real. Keep the order. If no, there is no edge, and the wait is wasted. Those two jobs can run at the same time.

Take a simple one: "review file A for bugs, then review file B for bugs." It reads like a sequence, but the check on file B never looks at what file A returned. They only run one after another because that is the order you typed them in. Run them side by side and the whole thing finishes in the time of the slower single file, not the two added together.

This resembles building an automation in n8n: each node has a job, and the connections determine what data it receives and when it can run. AI adds another requirement, though. The agent checking a result should not inherit the worker's reasoning and simply agree with it:

So you never let the agent that did the work check the work.

You put a separate node on the edge. Its only job is to try to kill the finding before it moves on. If it survives, it passes. If not, it dies right there.

Here is the catch nobody names: that checker needs a clean context.

Give it the same chat the worker had and it is not checking anything, it is nodding along to itself in a different font. A graph of agents sharing one context is just a single loop in a costume, and it breaks the same way, only later and pricier.

So make the verifier fresh. Own context. Checking a real signal, not "did the agent say it is done" but "does the test actually pass."

Read the full article →