2026-05-11 22:00:00
With AI, anyone on a team can generate mockups in minutes. That was never the hard part. The difficult work is, and always has been, maintaining coherency and intention across a product so it works for people, not the other way around. And perhaps unintuitively, everyone making mockups can help.
I was recently in a meeting discussing improvements to a specific part of a product. The backend engineer came in with a mockup. The product manager came in with a mockup. And the front end developer already had a working build. Three different disciplines all showing up with their version of what the UI could be, all enabled by AI tools. Given this reality, designers should worry about AI taking their jobs right? Well if the job is making mockups, then yes.
Here's what happened in that meeting. Seeing each person's concepts led me to ask the more important design questions. How do these features interact? What are the relationships between them? We discussed the system, its objects, and the mental model that made most sense for our target users.
We got to a shared understanding of the data we needed to support the UI, how it should be structured and how it interrelates with the rest of the product. Back-end, front-end, PM, and design on the same page. Which makes sense because these are the conversations that drive clarity and coherence in a product. Not "do you like this in my mockup or that in some other person's mockup?"
Later, I was reminded of a point I heard an educator make at the recent Design Futures Assembly. He noted at their business school, they'd give students case studies to analyze. Pretty much every student used AI to blast through the analysis in minutes. At first, the professors tried to stop students from using AI. But quickly they realized they should encourage it.
When all the students came in with the baseline analysis behind them, the conversation could progress to the next level. Before, it took the whole class hour just to get to the basic conclusions. Now, within ten minutes, they're on to much deeper and meatier topics. The majority of the class is spent expanding from the baseline as opposed to getting everybody there.
When everybody comes in with a baseline, we can skip past "here's my idea, here's my idea" and get straight to the meaty questions. The ones that rarely got discussed because we used to spend our time analyzing one person's mockups.
It's not that where things lay out on an application screen doesn't matter (it does). It's that the layout should stem from the underlying purpose of an application and how we represent the system that enables it to people.
The mockup was never the hard part. AI has made that abundantly clear.
2026-05-05 22:00:00
About a hundred senior designers and leaders from AI labs, big tech companies, and startups got together in San Francisco last week for the Design Futures Assembly. The public conversation about AI and design tends to live at the extremes: either everything is about to be automated or none of this works and we're killing the planet. The conversation in that room was different.
Almost all designers are using AI tools multiple times a week. The average number of AI tools in a designer's toolkit doubled in the last year. And that's just off-the-shelf tools. It doesn't include the ones people are building themselves.
At the same time, design leaders and organizations are looking for the go-to stack: what tools should my team be using? The honest answer from the people closest to the frontier was... there isn't one. At some of the best teams, the stack is dozens of internal tools that change month to month. The muscle we all need to build might not be picking the one tool. It might be getting comfortable with a highly dynamic toolkit.
Because designers aren't just using new tools. They're making them. And the gap between "off-the-shelf tool" and "thing I built this morning" is collapsing. People at the assembly were building custom agents that crawl codebases and write wikis of user mental models. They were shipping to internal app stores, building custom workflows, and more.
Close to half of designers shipped AI-generated code to production. At early-stage companies, it's more. At public companies, it's less. But in all cases, designers are asking themselves: now that anyone can ship code, what can I uniquely do that others cannot?
When seeing all this, organizations start asking designers to change how they work, ship code, build tools, move faster. But they haven't made any formal changes to job roles, performance reviews, etc. The expectations are moving way faster than the incentive structures.
At one of the big companies, designers who were empowered to ship to production started fixing small annoyances that customers hit 50 times a day. The customer response was overwhelmingly positive. But those fixes weren't what product management would have prioritized. How does that get resolved?
When everyone can ship, you get a different kind of problem. One design leader described it perfectly: they let everyone build and push whatever they wanted. And you could feel it in the product, because nothing made sense together.
Several people at the assembly used the word "editorial" to describe where design leadership is heading. Less about making the thing, more about deciding what gets made and ensuring it all holds together. The skill of saying no is becoming one of the most important skills in the profession.
One tool company founder used the word "coherence" instead of editorial, which I liked even more. Across every medium, you know when something feels singular, like it came from one shared point of view. That's what's at stake when everyone has the power to build.
Yet anything you think the models can't do, they probably will do faster than you expect. And taste, the thing designers most often cite as their safe island? Consensus was choosing a good UI or even generating one is pattern matching, and models do that and will keep doing it better.
But several people pointed to something harder to automate: figuring out what to ask in the first place. Reading between the lines in a user research session. Noticing the tiny turn of phrase that reveals what someone actually needs. Deciding what matters, not just what works. Will models also outpace us there? We'll find out soon.
The role is expanding. The boundaries are blurring. Designers are building, coding, shipping, making tools. Whether the organizations around them are ready for that is a different question. The measurement, the incentives, the processes, none of that has caught up yet. And until it does, we're in a strange in-between: doing different work in the same old organizations.
Someone at the assembly asked the question directly: what do we call ourselves? It got a laugh but it's a real tension underneath all the practical changes. Designers can ship code. PMs can make prototypes. Engineers can generate UIs. The boundaries that used to define the role are blurring.
For my part, I've always held the most important role of designers is fighting for the coherency, simplicity, and visual communication needed to humanize technology in a way that makes it work for people, not the other way around. New tools don't change this. New ways of working together do. Which is what we dug into into our Design Futures session Finally, the Handoff is Dead (full notes at the link).
Big thanks to Jeffrey Veen for hosting and everyone I got time to reconnect with and meet. Let's do it again soon.
2026-04-30 22:00:00
The designer/developer handoff has been with us for years. And even though today's AI tools are dramatically increasing everyone's output, the walls between disciplines haven't changed. So now we're throwing more stuff over the wall, faster. We've been iterating on a different workflow, which Amelia Wattenberger and I demoed at Design Futures Assembly.
Most companies have years of cemented process. Changing how designers and developers work together means unwinding habits, tools, and politics that have been building for a long time. We're in a different situation because we're spinning up new companies regularly. Which means we can recreate the design/dev process each time. And as the technology evolves and we learn what works, we adapt and carry those lessons into the next one. Today we'll share our current approach.
Where a lot of the discourse on AI is these days, and where a lot of AI tools are at, is individual empowerment. Designers saying: "I can finally ship code, I don't even need developers anymore." Developers saying the reverse.
But very few people are actually asking the question: how do we use AI to work better together?
Because pretty much everybody, in this room and beyond, is working with other people. And that's where the magic lies. Being able to pull multiple folks, their skills, and their experience together to create something better than you could do yourself.
Why doesn't this kind of collaboration happen already? As user experience, front-end development, and product management have matured as disciplines, we've fallen into a throw-it-over-the-wall modality. Partially because as these roles have matured, specific tools have been made for designers, like Figma. Likewise specific tools for developers, tools for PMs, et.c
And now we're adding a lot more tools, thanks to AI. So we're all able to produce more at a higher rate. Which means we're more throwing stuff over the wall faster. That's why you hear stories of developers just being overwhelmed with PRs as everyone starts "shipping" their ideas.
That applies to big complex projects but also nearly everything we do. Like publishing a blog post on your Web site. Maybe these days, the PM writes the content in ChatGPT, the designer makes the assets in Nano Banana, the developer writes the code in Codex. Everyone's productive, but are they aligned?
To help solve this, we've been building an app called Intent. The goal: make it easier to build software together. For any task, you spin up a workspace, which is a bundle of everything you need. Files (an isolated copy of the codebase, so you can change without messing up what others are doing), context (specs, scratchpad, data from external systems via MCP, etc), and agents (with tools and the ability to delegate and orchestrate work). Because these are all in one bundle, it becomes easier to put things down, pick them up, and hand them off.
Here's why that matters in practice. A designer keeps working where they already work (like Figma or paper) and brings their expertise into the workspace: grid, typography. That all gets encoded. A developer gets to work in their tools: CSS frameworks, deployment, structure. Same surface, different expertise.
The same surface that makes it easy to collaborate with people on your team is the same one that makes it easy to collaborate with agents. And true collaboration means respecting everyone's taste. So any workspace that gets spun up will align with how the designer encoded the styles to work and how the developer encoded the code to work.
To illustrate as a designer, I've got a Figma file with a grid and layouts. I go into a workspace in Intent and say: "Agent, look at the Figma file. Create the grid. Here's what the breakpoints are." Now that's encoded in the workspace and anybody that creates a new page or drops in a new asset, it works within that system.
I can also set up how animations should work to give everything made in the workspace silky smooth transitions.
Same idea on the developer side. The dev can say: here's the agent's MD file, here's how we're testing the code, here's the tailwind config. The agent encodes all of that.
Taste gets baked into code files and markdown files in the repo. And because things are built on top of the same version control that developers use, it gets automatically included into every new workspace.
The great thing is that this same pattern works for anybody on the team. An illustrator can use their own tools to make assets. A content writer can write their copy in Word.
Then anybody on the team can spin up a workspace and say: we're making a blog post, here are the assets, here's the Word doc. Because that workspace already includes the designer and developer's tastes, what pops out the other end is a blog post that's fully aligned with the rest of the site.
You can also run these workspaces in parallel so many people can be working on different parts of the experience simultaneously. And because every workspace is encoded in the same way, everything that gets added ends up unified by default.
This gives us massive parallelism and the ability to accommodate all kinds of last-minute requests. Which, even in an age of AI, still happen. Here's me busting out 10 last-minute 8pm asks in minutes using multiple workspaces without messing up the design or code integrity of the site.
AI tools are making individuals faster, but speed isn't the problem. Cohesion is. When taste is encoded into a shared workspace in Intent, designers keep designing, developers keep developing, and everything that comes out the other end holds together. No handoffs necessary.
2026-04-24 22:00:00
I recently sat down with Mark Swaine on the UX Institute podcast to talk about where interfaces are heading, what's changing for designers, and why most of the software we use today is still kind of crappy. Here's some of the threads we pulled on.
We don't call carpenters "hammer users." We call them carpenters. We focus on what they make. Yet the tech industry turned everyone into "users." The goal should be letting people accomplish what they came to do without forcing them to be conscious of operating a computer. That's been the north star for decades, and it's finally starting to feel possible.
Photoshop has thirty-plus years of interface built around manipulating pixels. But when you want to edit a photo, you're thinking "make her hair flow to the left," not "select these pixels and apply a transform." At Reve, we've been building around object-oriented editing, where you interact with semantic objects (a woman, hair, a vase) instead of drawing selection boxes. It matches how people actually think.
A developer I work with has this great framing for how people relate to AI agents. Some treat them like pets and some treat them like cattle. If you design for pet people, you show the full trace, every step expanded, every decision explained. But that creates walls of information that cattle people will never read. If you design for cattle people, you roll everything up into a clean result. But pet people feel blind and anxious. Depending on which group you're hearing from, you may up end up with very different UI.
Across every AI product I've worked on, three challenges keep showing up. Capability awareness: what can this thing actually do? Context awareness: what is it paying attention to right now? And walls of text: reasoning traces, tool calls, all streaming at you. We're making progress, but some of these may never fully go away.
Everyone talks about using a company's data with AI agents. The problem is most of that data is stale. Your CRM gets touched when someone remembers to. The real source of truth is the sales call happening right now, the Slack conversation from this morning. Code is a rare exception because the codebase is actually current. Almost nothing else is.
I've lived through the birth and growth of the Web and mobile. Designers who aren't adapting to the new reality of AI are going to feel the ground shift even more than in those earlier tech transitions. You have capabilities right now that didn't exist a year ago. Go make things.
Listen to the full conversation on the UX Institute podcast.
2026-04-15 22:00:00
There's lots of ways to build a website. Most of them involve designers working in one tool, developers working in another, and a painful handoff process somewhere in between. We recently used Intent to design, build and ship a well-crafted website in about three weeks, and the collaboration model that emerged shined a light on how things could (no, should) be.
We started the way most Web projects start these days: in Figma. Visual explorations of what the style, wireframes for the structure, then bringing the two together into full page layouts. Our designer set up the grid, typography scales, color variables, buttons, and reusable components. Your typical design system.
This process took about two weeks and was pretty standard. Desktop and mobile comps, a couple rounds of feedback on visuals and copy, iterating until we had a visual style, a rough structure, and directional content. Just a solid Web design process.
Once the designs were in a good place, our developer jumped in. But not by staring at a Figma file and manually translating pixels into code. Instead, he opened up Intent, set up the project scaffolding (Astro, Tailwind), connected to the Figma MCP, and wrote an agents.md file that pointed to all the artboards.
Then he kicked off a series of workspaces. The first one pulled the design tokens into Tailwind. The second started laying out the first page using those tokens. After that, he was able to break off into parallel workspaces, one for each page. Desktop layouts first, then separate passes for mobile.
This whole phase, the front-end infrastructure, took maybe one or two days of actual work. And by the end, every page existed in code, using the design system, at roughly 85% fidelity. Not pixel perfect, but pretty damn close.
Once he deployed the site to a staging URL, the three of us started working in Intent simultaneously: our designer, our front-end developer, and me handling product/project management. Though we all were using the same tool, we each worked our own way.
Our designer set up a grid overlay so he could visually verify alignment. He would tell the agent "align to column three" and it would snap things into place (way better than guessing at percentage values). He preffered staying in one workspace to tweak alignment and refine grid positioning across a full page before committing things.
Once the pages were structurally solid, he moved on to animations. Entrance effects on homepage elements, scroll-triggered transitions, etc.. Work that normally takes days of back-and-forth between a designer specifying timing curves and a developer implementing them happened in about hours. He still maintained manual control where it mattered, finding the exact easing curve he wanted then telling the agent to use it. The implementation was handled for him so he could focus on how things felt.
Meanwhile, I was doing content and product work. Dumping in blog posts from Word docs, adding image assets, making text changes based on feedback from the broader team. My approach was simple: small discrete tasks with a single agent. Fix one thing, commit. Fix another thing, commit. Once I had four or five commits, I'd open a pull request, toss out the workspace, and start a new one. The design tokens and setup our developer created ensured my changes were all inline with our design and development architecture.
Our developer's job during this phase was partly creative and partly managerial. He handled the templatized pages (news, product detail) where variable content meant design rules mattered more. He also kept an eye on pull requests, merged changes, resolved conflicts, and updated the agents.md file when he noticed patterns emerging in the code that should be standardized.
For example, when he saw icons being added in a way that wouldn't scale, he set up a better pattern and documented it. The next time anyone needed to add icons, the agent just followed the convention automatically. He used Intent for conflict resolution too, pulling up conflicting branches and having the agent sort them out. Out of maybe 30 or 40 pull requests across the project, only five needed real manual intervention.
Same tool, three different workflows, nobody waiting on each other.
Every web project has a crunch period right before launch and ours was no different. The broader team started paying attention (as they always do at the very end), and feedback flooded in. But because the three of us could all be in Intent making changes at the same time, the crunch was way more manageable than usual.
The biggest win was that any one of us could contribute meaningfully to the codebase without breaking the design system, code structure, or the site. That's a fundamentally different dynamic than waiting for a developer to make every change.
It wasn't perfect. CSS layout struggles are still a thing. Git seems to keep finding ways to bite you. And there's still a learning curve for non-developers, even with agents handling the hard parts.
But without the handoff, everyone builds. And that makes all the difference.
2026-04-07 22:00:00
There's a question that never goes away in design: should designers code? My answer has always been yes. But for a decade or so, the complexity of front-end development made it impractical for most. Thankfully, AI coding agents have reopened the door.
Just like a sculptor needs to know how marble chisels, breaks, and buffs, a Web designer should know how CSS, HTML, and Javascript construct interfaces within a Web browser. You need to be intimate with your medium to know what it can and cannot do. Whether Web apps, iOS native apps, AI apps...
For years, many designers did exactly that. Looking at my personal GitHub history tells a story familiar to many. Steady coding until about 2014. Then almost nothing for a decade. Why?
Before 2014, a designer could build a lot with HTML, CSS, and Javascript. Then React and Angular gained traction, and "web app" went from "pages with some interactivity" to single-page applications with state management, routing, and build pipelines. The gap between "I can code a website" and "I can code in my team's dev environment" widened fast.
Tooling got heavier and frameworks churned constantly. Deployment went from dragging files to a server to CI/CD and cloud infrastructure. So little wonder that a designer who coded comfortably in 2012 could look at the 2015 landscape and reasonably decide to go back to Sketch (dated reference, I know.)
Thankfully technology never sits still and AI coding agents are now collapsing the gap between designing and building. Zooming in to the last few years of my GitHub history tells that story well.
For years, it was faster to mock up software than to ship it. Designers stayed "ahead" of engineering with prototypes. Now AI coding agents make development so much faster that the loop has flipped. Henry Modisett described this new state as "prototype to productize" rather than "design to build," and that sounds right to me.
Designers can now work iteratively with production code, not just prototypes. This kind of hands-on work creates better designers, ones who work through issues that previously got left for developers to figure out.
As always, designing software is better when you work in the medium, not a level or two abstracted away. AI tools make that possible again.
