Notes from the future of design

I’m not entirely sure I deserved to be in such esteemed company, but I was lucky to blag a spot from my friend and event organiser Jeff Veen.

The gathering brought to life that old, slightly overused William Gibson line: “The future is already here — it’s just not evenly distributed.” It gets quoted so often that it can feel a bit tired, but sitting in that room, it felt unusually apt. Not because everyone there had the answers. Quite the opposite. It felt like an early warning from the part of the industry where AI is already changing the day-to-day mechanics of design work.

I have no doubt we’ll start to see more gatherings like this over the next year. In fact, I’m helping organise something similar in Brighton in a few months’ time. Maybe not with the same concentration of people from Californian AI labs and design tool companies, but with the same underlying questions. The conversations happening in that room will start spreading through the rest of the tech world soon enough, because the same pressures are coming for everyone: faster tools, blurrier roles, more people able to generate plausible product work, and design leaders trying to work out what quality means when making the thing is no longer the main bottleneck.

Most design teams are not working this way yet. AI only really seemed to reach the right level of sophistication for product teams over the past year or so, and the current window of opportunity still feels relatively small. But I suspect many of these conversations will feel familiar within the next 12 months.

Who gets to design when everyone has access to design tools? Who gets to ship when the distance between prototype and production collapses? What happens to product quality when more people can generate something plausible? And what is the job of a design leader when making the thing is no longer the main bottleneck?

What I found was not a room full of leaders confidently pitching a brave new world. Instead we had a room full of thoughtful practitioners comparing notes on what had changed for them over the past six months, and speculating about what changes were yet to come.

The sessions had a strange mix of excitement, opportunity and anxiety. People talked about AI speeding things up, giving them capabilities they had never had before, and getting them closer to decision-making, or at least shipping. There was a renewed sense of making in the room. But people also talked about feeling tired and discombobulated by the pace of change. So while there was plenty of quiet optimism, there wasn’t much certainty.

One of the post-event write-ups captured the mood nicely. Even in a room full of people working close to the edge of design and AI, almost everyone seemed to be saying some version of “I feel behind.” That felt a lot more honest than most public commentary on AI, which still swings between “design is about to be automated away” and “none of this stuff works, it’s just a parlour trick burning through GPUs.”

The borders are getting blurry

One of the most obvious tensions was the slow collapse of role boundaries.

PMs can now generate decent-looking interface ideas. Engineers can produce usable screens from a prompt and an existing component library. Founders can create landing pages, brand routes and prototypes over a weekend. Domain experts can describe a workflow and get something that looks quite a lot like software.

You can see why this makes designers nervous. The defensive version of the conversation asks: if everyone can do design, what are designers for?

Except that wasn’t really the vibe I got from the people in the room. If anything, several of the speakers seemed to have the opposite problem. Demand for design had gone through the roof. Teams were scaling up fast and shipping faster than before.

The bottleneck that once existed between product, design and engineering seemed to have evaporated, at least for the time being. Design teams were building their own internal tools and releasing them themselves, rather than pleading with an executive for budget or fighting for a slot in the backlog. Things that once would have sat on the backlog for years were now getting shipped. Design teams were no longer asking for permission, but forgiveness.

One of the write-ups after the event described designers being “unleashed” by the ability to work in code, ship their own pull requests and solve customer problems that would never normally make it onto the roadmap. This points to a real shift in the politics of design. A designer with good product judgement, a bit of technical curiosity and access to the right AI tools can now do more than describe the opportunity. They can build enough of it to see whether the opportunity is real.

So does this mean we all need to become design engineers now?

I’m not sure. But the question cuts both ways. If designers can ship, PMs and engineers can also create more of the interface work that designers used to own. Some designers will find that uncomfortable, especially if their confidence comes from being the only person in the room who can operate Figma.

And if engineers are starting to get annoyed with designers shipping half-baked code into production, we’re definitely going to see designers get frustrated with executives, product managers and engineers shipping “designs” that only have a cursory relationship to the brand, break common paradigms, and push the product in a thousand different directions at once.

In a world where everybody can and does ship design, design leaders are about to get very busy thinking about product quality. Do we empower everybody to become a designer, or do we end up becoming the arbiters of quality and taste?

Taste is not a magic shield

At some point during the event, a friend in the audience mentioned that I had strong views about the role of taste, and asked me to speak up. While I appreciated the shout-out, I honestly wasn’t sure what they were referring to. As you probably know, I have strong views about a lot of things, so I was sitting there trying to remember whether I’d written something about taste recently.

I also wasn’t sure if it was a bit of a set-up, because “taste” feels unusually polarising at the moment. It reminds me a little of the way empathy was treated in design circles ten years ago. First there were endless posts about how empathy was the designer’s secret weapon. Then, a few months later, there were endless counter-posts calling bullshit on the whole thing and accusing designers of gatekeeping. As if only designers were empathetic. Now we seem to be doing something similar with taste.

So I decided to proceed with some caution in a room full of my peers.

The reason taste matters at the moment is that our current crop of AI design tools are still basically slot machines. You pull the lever and something plops out. Sometimes it is good. Quite often the results are mixed.

Current AI-driven designs might have the right spacing, the right gradients, the right soft shadows, the right empty-state illustration, the right slightly over-polished AI product look. If you’re lucky, they might even be drawing from an existing design system.

For somebody creating a design for the first time, this can feel magical. If you’re not a trained designer, you may not notice that the gradients are a bit of a cliché, the typography is subtly off, or the images don’t match the current brand guidelines. Instead you proudly admire the piece of design you just magicked out of the air and hit merge.

But plausible is not the same as good. A generated interface can look competent while being strategically wrong, behaviourally confused or completely forgettable. It can satisfy the visual grammar of a modern product without understanding the context it is meant to serve. Often the result is all UI with no UX: the aesthetic-usability effect writ large.

One speaker demoed a browser plug-in they had created that could detect whether a design was using common generative AI tropes. The talk was both funny and telling. We are already at the point where AI-generated design has its own vibe. First we shape our tools and then our tools shape everything else. Or as one friend is prone to say, “You can almost smell the LLM on that interface.”

So yes, taste matters. Someone needs to be able to look at the output and say, “This looks fine on the surface, but it is not good enough.” And if engineers are allowed to look at the code an AI tool produces and say, “This doesn’t meet our coding standards,” then designers should have the same authority when it comes to design quality.

However, I think taste starts to matter even more when we move beyond pulling a lever, judging the output, and writing a new prompt to tighten something up. It starts to matter when the tools produce multiple viable directions and ask us to choose. Not one answer, but one hundred. All technically acceptable. All stretching the product in different directions.

At that point, somebody versed in design needs to be able to make a reasoned argument about why one direction is better than another. This reminds me of Cayce Pollard, the character from William Gibson’s Pattern Recognition, who would get physically ill when exposed to bad, aggressive or overly commercial design. A slightly extreme reference point, perhaps, but there is something useful in the idea that taste is not just liking nice things. It is sensitivity to what feels off before you can fully explain why.

This is why taste has become the design world’s latest hot potato. Everybody thinks they have good taste. And while it is relatively easy for an engineer to explain why a piece of code is not up to standard, it can feel very personal when a designer tries to explain to an executive why their vibe-coded prototype is a good start, but doesn’t work as a piece of product design.

This is where taste becomes stewardship. Not taste as personal preference. Not taste as “I know good when I see it.” Taste as the ability to protect coherence across a system.

What belongs in the design system? What should be reused? What should be retired? Where should teams be allowed to diverge? When is inconsistency a reasonable cost of speed? When is a small exception actually the beginning of product decay?

Design systems become more important in this world, but also less sufficient. A design system is not just a library of components. It is a set of product decisions. It encodes behaviour, hierarchy, brand, judgement and restraint. If everyone can generate interface work from that system, the quality of the system matters more than ever.

However, this is also one of the risks for design. In a world where everybody can and will design, do designers get relegated to creating, managing and policing the design system?

Because that would be a pretty grim outcome. The irony of AI making design more widely available is that it could leave professional designers doing less design and more quality control.

The tool stack is not really a stack

Another theme that kept coming up was the search for the “right” AI tool stack.

You can understand why. Senior leaders want to know what to buy, what to standardise on, what to train their teams in and what to ban. They want a clean answer because clean answers are easier to put into a plan.

But the people doing the most interesting work didn’t seem to have a neat stack. They had a shifting collection of tools, workflows, scripts, agents, prototypes and internal experiments. Some were using public tools. Some were using internal tools. Some were building their own. The stack, if you can even call it that, looked less like a stack and more like a messy workbench.

So the leadership question is less “which tool should we adopt?” and more “how do we keep learning as the tools change?”

Companies are going to need people who can try things without turning every experiment into a procurement process. They will need shared standards, but not so much process that nobody can move. They will need to let designers, PMs and engineers explore the edges of what the tools can do, while still keeping an eye on privacy, security, quality and product coherence.

The hard part is not adopting AI tools. The hard part is creating a culture where experimentation does not immediately become either chaos or theatre.

A lot of organisations are bad at this. They either lock everything down until the interesting people give up, or they encourage everyone to play with tools without giving them any meaningful way to connect the experiments back to the product. Neither approach feels likely to work.

I’m already seeing problems emerge. Companies that tried to codify their AI design practice six months ago, only to realise their new process is now holding them back. Companies that fired half their engineering team, went hard on token-maxxing, only to be forced to cut their spending and hire half the team back. Sometimes being an early adopter gives you an advantage. Other times you become a cautionary tale for somebody else.

So when is the right time to move, and how fast and how far should you go?

Coherence is the real leadership problem

The visible parts of design are getting cheaper. Not free. Not necessarily good. But cheaper.

Generating a screen is cheaper. Creating five versions of a landing page is cheaper. Turning a rough thought into a prototype is cheaper. Producing something that looks enough like software to fool a busy executive is definitely cheaper.

That forces the less visible parts of design to prove their worth: the framing, the judgement, the critique, the decision about which problem deserves attention, the ability to notice when something is technically correct but experientially wrong, the discipline to reject plausible work, and the capacity to hold a product together when more people are able to contribute to it.

When everyone can ship, someone has to hold the product together.

This is not really a craft problem. It is an operating model problem.

How do design leaders create space for designers to experiment without creating chaos? How do they encourage PMs and engineers to work with design systems without reducing design to component assembly? How do they preserve quality when production speeds up? How do they evaluate design contribution when the work no longer lives neatly inside Figma files?

How do they stop design becoming either a bottleneck or a decorative service?

I don’t think many organisations have good answers yet. Most are still trying to pour new capabilities into old role definitions. The incentives are lagging behind the tools. Designers are being encouraged to code, prototype, generate, ship and automate, while still being assessed through job descriptions written for a slower, more separated world.

That tension is going to break something. It might break the design function in some companies. It might break the old product trio model in others. It might also break the habit of treating design as the team that makes ideas presentable once the real decisions have already been made.

One of the more useful frames from the Assembly was that AI does not simply automate design. It exposes what design was responsible for all along. In a healthy organisation, it can amplify judgement, taste and craft. In an unhealthy one, it can amplify confusion, inconsistency and weak decision-making.

I’d add something slightly more uncomfortable. AI also removes some of design’s excuses.

If designers can prototype, test, generate, ship and learn faster than before, then the discipline has to stop defining itself mainly through critique from the sidelines. It has to get closer to the material of product work again.

That will be good for some designers and deeply uncomfortable for others.

The value of coming together

The thing I found most useful about the event was the sense that I wasn’t alone. The ethical, creative and process challenges I’d been thinking about were on everybody’s radar. Some people were slightly further along than others, but nobody had a definitive answer. Not yet. Just thoughts, questions, ideas and experiences to share.

I think this is why one of the recurring sentiments was that the event felt a little like the early days of SXSW. Not in terms of size, obviously, but in terms of experience density and community. There was a feeling that the rules were being rewritten while we were in the room. That turned out to be a great leveller. You can no longer rely entirely on 20 years of tool and process experience if the tools and processes are suddenly changing.

For some people this might rightly be scary. But for the people in the room, I think there was also a real sense of excitement.

Design has felt pretty stale for the past 10 years. Essentially since the industry went from shaping products to shipping PRDs, and we moved from using a wide toolbox of skills — mental models, personas, wireframes, journey mapping, service blueprints, workshop facilitation — to becoming Figma operators.

AI is blowing that world open. Figma is still an important design tool, but the best designers are using it 20% of the time rather than 90%. The work is starting to sprawl again. Tools, processes and skillsets are all changing at once.

If you’re the kind of person who relishes the chance to learn a new thing, it’s a great time to be a designer, even if we don’t yet know where this eventually lands.

That uncertainty is also why I think we need more rooms like this. Not because a handful of people in San Francisco have cracked the future of design, but because the questions are going to spread much faster than the answers. The same conversations will soon show up in quarterly planning meetings, design critiques, roadmap debates, hiring conversations and slightly awkward Slack threads where somebody has shipped something they probably shouldn’t have.

Maybe the real question is not whether everyone can design.

It is what happens when everyone can ship.

---

Andy is helping to curate the new design + ai summit taking place in Brighton on the 25th Sep. The day before he'll be hosing an invite only leadership forum at Soho House Brighton. Apply here.