3 Ways in Which Product Design Is Changing, and One Way in Which It Isn't
I've spent the last thirteen years building data-driven products, and the last six in AI – when it was called ML, before it was cool. Here's my attempt to name what's changed without the AI hyped-up buzzwords, with a few stories from the work, and the one thing I'm betting won't change.
The talk
In April 2026 I’ve given a talk about this at the ML-Ops community meetup.
The original wasn't recorded, so this is me re-recording it at home – same script, same slides, just a comfier chair.
Three levels, three shifts
Design operates on three levels. Changes spread across all of them:
Vision and strategy
Prototypes are finally replacing decks.
Experience
Behaviour is becoming the new UX – and the back-end tools that define and tune it are becoming the design tools that matter.
Delivery
Pull requests are quietly taking over from the traditional handoffs.
1. Prototypes are (finally) replacing decks
Traditional consultancy work was often narrative-first, and plenty of consultancies still work this way: 8–12 weeks of research, concepting, Figma prototypes and “testing” (user opinions really), ending in a gorgeous deck full of insights, design principles and recommendations – all of it still needing "translation" before it reaches production.
This process over-values process and under-values product thinking. It distrusts intuition and existing knowledge: blank-slate thinking is enforced, so the team burns weeks getting up to speed on things someone in the room already knew. Not all consultancies are like this, at Normally we did the opposite – we trusted our intuition and built product prototypes from the start. And validation comes late, testing the story rather than the product – what people say rather than what they do.
This is finally being replaced with the prototype-first approach. Most of the teams I lead work this way.
This approach is essentially two steps: build the thing, then iterate on it. The iteration is quick and fluid – involving testing, pivoting, learning, measuring and using the product.
I often say that a prototype is worth a thousand slides – it can show product vision, prove feasibility, let you feel the journey and evoke emotion all at once, where a deck manages only one before the narrative dilutes. It also forces you to bridge concept and reality from day one: you can put a "how might we" on a slide, but in a prototype it has to be answered.
Example: Concierge console prototype
An AI-powered concierge console for specialist assistants helping busy families clear their to-dos.
We prototyped end-to-end from the start, with a little simulator to fire in to-dos from different families. Building the fulfilment flow and quickly iterating on it taught us things a deck never would – we learned how the product strategy should change and how human resources could be up-skilled (augmented, not replaced). When we tested with real to-dos, average fulfilment time fell from three days to 28 seconds, and quality improved two to four-fold.
2. Behaviour is the new user interface
In 2026 the way we interact with products and services is fundamentally different to how things were even just 5 years ago.
First, our interactions now span devices and touchpoints: you might book a train ticket on your work computer, ask station staff something via their tablet, check the delay on your phone, and request a refund from your iPad at home – one journey, four surfaces, four behaviours to keep coherent.
Second, everyone – including my grandma – now has an agent. I built her one: an iPad app with a big blue button she presses to start and stop it, with full context of our (multilingual) family. Interestingly she treats the agent (her) as “a session my “friend”, by writing down her questions in advance.
UX = 90% Behaviour + 10% UI
In this world I'd argue 90% of the user experience is shaped by back-end behaviour and capability definitions, and only 10% by the front-end UI. The rules, the handoffs, the bottom of the iceberg matter far more than the visuals at the tip.
An agentic system is full of back-end design problems: prompts, tools, memory and context, guardrails, testing, routing, error recovery, grounding.
Conversational front-ends
On the front end there are really just five things that make an agent feel better: stream answers in, show its reasoning, surface and gate the destructive tool calls, use generative UI (maps, tables, charts), and give it some memory of the user.
Example: Simple agent experience design panel
The back end is now a design surface, not just plumbing. I often build both halves of a prototype so we can adjust the data and agent behaviour. On one such conversational agent I built a simple panel so the conversational designer could tweak each part of the system prompt and watch the personality change in real time – it let us experience the thing and doubled as a product spec.
3. PRs are taking over traditional handoffs
The old way: design in Figma, mark a page "ready for dev", hold a handoff session, then endure the back-and-forth of red comments and things lost in translation.
The new way: coding agents have got good enough that designers now produce front-end code and hand it over as PRs. Engineers still review it, but the translation loss is gone – both the designer and the engineer have already seen the exact expected behaviour (not just ui).
The importance of a great design system
In this world, a good design system matters more than ever here, and Brad Frost's old atomic design holds up beautifully: atoms (buttons) compose into molecules (cards) and into organisms (a data table that takes its rows as a prop). Give a coding agent that vocabulary and it composes large structures with precision instead of guessing your spacing.
In my teams we also give the agent a project-specific agent design skill – in our Nuxt/Vue.js projects it spells out how to use NuxtUI library, the spacing + typography rules and a few coding conventions we use. In short: a design system, the component code behind it, and a skill for the agent to wield both.
What isn't changing: aesthetic problem-solving
To me design is still aesthetic problem-solving – and by aesthetic I don't only mean visual; it can be tone of voice, motion or sound. It's still about choosing which problems are worth solving, how to solve them, and how the result should feel. It's still crafting and tuning until something feels clear, coherent and alive. The material now includes prompts, behaviours, memory and voice rather than just screens, but the work is the same.
Just because we can produce more and faster, doesn't mean we’re producing quality. “Your organisation rarely has good ideas.“ (Dax Raad, CEO OpenCode) and just bringing them to life is cheap code creating expensive chaos.
The focus has moved from the surface to the system, but the need for discernment hasn't gone anywhere. It's just got more interesting materials to work with. And more than ever there’s a need for someone with taste to tell great from “that’ll do.”
