An Emerging Playbook for Design Teams
Rules you can break, experiments you can try, and why standing still is the biggest risk.
Last week I wrote about how the design process is failing designers, not because design has become less important, but because the processes we rely on no longer match how products are actually built.
This piece is a follow-up.
I want to be upfront: I don’t have all the answers. I’m figuring this out in real time, like most of us are. I work on AI-native teams where things are changing fast. I see it in my professional work, and I feel it in my own side projects too. I’m guessing you do as well.
This is written primarily experienced cross-functional teams working on AI-native or fast-moving products.
This feels like a unique moment. Many of the well-trodden paths we relied on are dissolving. Ambiguity is the default instead of being an edge case.
So rather than proposing a new “right way” of working, I want to offer something looser and, I think, more useful in these times:
Here are some rules you can break, and some experiments you can try with your team this week.
Pick one or two. Observe what shifts.
This is about giving teams permission to intentionally shape their own process rather than prescribing something new.
A quick note on scope, because this matters.
None of what follows is an argument for chaos, skipping craft, or abandoning user care. It’s also not a playbook for inexperienced teams to “move fast and hope.”
If a team is still developing its fundamentals, experimentation works best when it’s tightly framed and well-supported.
These ideas work best when there is strong judgment in the room, clear accountability, and a shared bar for quality. Without those, speed doesn’t create learning, you’ll just get noise.
1. You can build before you agree
The old rule: Align on the problem before anyone touches a solution.
Try this instead:
When the team is circling a problem, build two or three rough versions that represent different interpretations of what the problem might be. Put them in front of users early, discuss them together.
Right now, learning by building is often faster than learning by planning as long as the building is intentional and observable, not just execution for its own sake.
What to observe:
Do disagreements dissolve once something concrete exists?
Does clarity arrive through interaction rather than debate?
Does a completely new problem direction emerge?
If you’re looking for a concrete way to run structured experimentation without defaulting to long discovery phases, I’ve previously shared a practical format for running a 90-minute AI design sprint. It’s one example of how teams can move fast without abandoning judgment or craft.
2. You can ride the momentum
The old rule: Design process sets the pace.
Try this instead:
If a team clearly wants to build, to prototype, to “vibe code”, and to see the thing…let them. Go with the flow rather than damming it.
I’m seeing some of the most experienced teams disregard process altogether and lean into their collective intuition, skill, and taste. Something surprising is happening: they’re becoming more creative than ever.
Design doesn’t disappear here, instead it is amplified: it moves upstream and sideways at the same time. Designers become orchestrators: prompting, asking better questions, shaping direction, reading what’s emerging, and knowing when to intervene and when not to. It’s a far more strategic starting point.
The risk on this one is momentum without someone holding the system view.
This only works with experience. With newer teams, leadership needs to move closer to the work often by building alongside them.
What to observe:
Does influence increase when design stops blocking motion?
Does the conversation become more strategic (not less)?
How fast is the group learning and pivoting?
Are the functional roles blurring?
3. You can skip steps on purpose
The old rule: Every project follows the same path.
Try this instead:
At the start of a project, explicitly agree together which parts of the usual process you’re skipping and why. Think about what you’ll do instead and how you think it’ll play out. Then give it a go, but don’t panic if things start getting weird: this is good news, you’re leaning something new as a team.
Skipping unconsciously can create resentment and confusion. Skipping intentionally and agreeing to it creates agency.
The key test: can everyone still explain why a decision was made, even if fewer artefacts exist?
What to observe:
Does decision velocity increase?
Does quality actually drop, increase or does it change shape?
Did anything you didn’t love happen and why is that?
Who on the team thrived and who didn’t?
4. You can prototype problems, not just solutions
The old rule: Define the problem clearly, then design the solution.
Try this instead:
Treat problem statements as hypotheses. Build prototypes that test different framings of the problem itself.
When you’re dealing with a genuinely new capability, you often can’t know the “right” problem up front. Sometimes the only way to discover what a capability is good for is to make something and see how people respond, how you respond.
Starting with the solution isn’t reckless anymore, now it’s often the fastest way to learn about the problem. This only works when teams are close to users and feedback and loops are tight. When risk is high or reversibility is low, speed should slow down and not accelerate (as usual).
What to observe:
Which framing users gravitate toward without being told?
What problem reveals itself through use rather than articulation?
What hunches were spot on right away and which ones were not?
5. You can value learning over polish
The old rule: High-quality artefacts signal rigour.
Try this instead:
Measure success by how quickly the team moves from uncertainty to insight and not by how finished something looks, or how much of the traditional process it has travelled through.
Rough prototypes that teach you something quickly often outperform polished designs that arrive later. However learning speed never replaces the responsibility to raise the bar before scale.
What to observe:
Are decisions happening faster?
Is the team more willing to change direction without defensiveness?
Are you discovering new and interesting directions?
Is your team mindset shifting?
6. You don’t need permission to use intuition
The old rule: Only evidence counts.
Try this instead:
Invite designers to share gut reactions just not as conclusions, rather as signals worth testing and directions worth exploring.
Intuition isn’t “vibes”, it’s compressed expert experience. Intuition earns its place when teams are willing to test it. In a world where models can generate endless surface-level output, human judgment, taste, and pattern recognition matter more than ever.
I’m seeing teams deliberately boost creativity by revisiting non-digital references like typography, record covers, old design movements and recalibrating taste together. Great teams are often a little weird. That’s not accidental.
What to observe:
Do conversations shift from “can we justify this?” to “should we explore this?”
Does taste become more visible and more valued?
Are people excited to share things they’ve been thinking about?
7. You can move decision-making closer to the work
The old rule: Decisions travel up the chain for alignment.
Try this instead:
Push decision authority as close as possible to the people building, testing, and interacting with the thing.
AI-native work collapses the distance between idea → execution. If decision-making doesn’t collapse with it, speed evaporates and teams slip straight back into old bottlenecks.
The teams many of us admire already do this implicitly. They trust experienced people at the edge to make calls, adjust direction, and move without waiting for permission.
This doesn’t mean removing accountability. It means redefining it: leaders set the bar, the boundaries, and the intent but teams decide how to move within them.
What to observe:
Do cycles shorten when decisions stop travelling?
Are problems resolved earlier, when they’re still small?
Does ownership deepen when teams are trusted to decide?
Where does judgment improve when it’s exercised more often?
The cost of not experimenting
There’s also a risk in not experimenting right now.
Teams that wait for clarity, consensus, or a new standard process are often standing still while the ground shifts beneath them. In a moment like this experimentation and a willingness to re-write the rule book should be top of mind for all teams.
Standing still is a major risk in a fast-moving era.
A note on leadership
I’ll be honest: as a leader, I’m more unsure than I used to be but it is more fun. I don’t always know if things will work, or if the direction I’m nudging toward is the right one.
That’s changed how I lead.
I listen more. I observe longer, poking instead of steering. I try to create the conditions for good things to emerge rather than prescribing outcomes too early.
Leadership right now feels less about direction and more about orchestration: shaping the environment in which teams, tools, and models can do their best work together. It’s also about giving teams the confidence, space and support to experiment, try new tools and workflows. It’s about encouraging them forwards when they feel uncertain.
Let’s make this a conversation
I remember moving from engineering into design at the very beginning of what we were starting to call “UX.” It was messy, under-defined, and often misunderstood. But a community formed. Language emerged. Practices appeared. Over time, we articulated what great software design could be.
I never expected to find myself at the beginning of something even bigger.
This moment feels more fluid, more ambiguous, and far less structured. Nothing is locked in. Ways of working will form, dissolve, and reform. The mood has to change with that reality.
If you’re experimenting, struggling or trying things that half-work, share them. If something here resonated or rubbed you the wrong way, say so. The value right now is in collective sense-making and learning together.
We get to write this playbook as it unfolds.
Next week, I’ll explore why this moment makes design harder, why dabbling is becoming less viable, and why we’re heading into a craft-led era where judgment matters more than process.
Great read! thanks. This actually calms me down a bit, as I needed a playbook to handle this new world :)
My only concern is the speed and 'dark magic' which creates artifacts, it dazzles non-designers, and they see this speed as quality or decisiveness. This article puts it best: https://uxdesign.cc/when-design-stops-asking-why-and-starts-asking-can-ai-do-it-625c9a5d9c68
Tell me what you think!