There was a point in our careers when we didn't know what was possible. And I think that might have been one of our greatest advantages.
When we started, we didn't know all the standards. We didn't understand every technical constraint. We couldn't anticipate every accessibility concern, business requirement, edge case or implementation problem. Sometimes that meant we proposed things that were simply bad.
We reinvented solved problems. We underestimated complexity. We ignored constraints we didn't yet understand.
Ignorance isn't creativity, and I don't want that ignorance back. But there was something useful hidden inside it. We had ideas before we had reasons not to have them.
We looked at something and wondered:
What could this be?
Then we got better at our jobs.
And somewhere along the way, the question changed.
We learned where the boundaries are
Experience teaches us an enormous amount. We learn why certain patterns exist. We learn what works and what doesn't. We learn accessibility. We understand our users better. We understand technology, business requirements, timelines, budgets and the consequences of the decisions we make. In theory, knowing more should expand what we're capable of imagining and often it does.
An experienced designer can see possibilities a junior designer simply cannot because they understand the system around the problem. But experience teaches us something else too. It teaches us which ideas are unlikely to survive and eventually, we can look at an idea and see the problems before we've even made it.
"Engineering will never agree to that."
"That's going to be difficult to maintain."
"Our design system doesn't support it."
"That's too much effort for what we're trying to achieve."
And most of the time, we're probably right. That's part of becoming good at what we do. The problem is what we do with that knowledge, because knowing where the constraints are and allowing those constraints to define what we imagine are two very different things.
Experience should help us evaluate an idea.
I'm not sure it should always decide which ideas we're allowed to explore.
Then we learned to anticipate them
There's another thing experience teaches us: we get better at understanding the people around us. A designer learns enough about development to anticipate technical concerns, a developer learns enough about design to understand why certain decisions matter, product understands both well enough to know where compromises are likely to happen. Accessibility can recognise interactions that repeatedly create exclusion. The business understands where investment is difficult to justify.
We learn each other's language. That's a good thing and sometimes, it's exactly what the situation needs. There are deadlines and releases that cannot move. There are problems that need to be solved today rather than explored for the next two weeks.
In those situations, being able to anticipate the constraints, avoid unnecessary debate and quickly find something everyone can agree on is incredibly valuable.
That's experience doing its best job. But I wonder if we got so good at doing it that we forgot how to stop.
What begins as a response to a constraint can eventually become a habit. We learn to stop the debate before it has a chance to start and when the deadline disappears, the behaviour remains.
So we started compromising before anyone asked us to
We already know what engineering will say. We already know what product will question. We already know what the business will push back against. We already know which accessibility concerns are likely to appear.
So instead of bringing an ambitious idea to the table and allowing everyone to challenge it, we start designing the compromise before anyone has asked us to compromise.
The meeting is shorter, the implementation is more predictable. Everyone nods and because we're experienced, we can become exceptionally good at doing this. Perhaps that's part of the problem.
Senior people are often valued precisely because we can create predictability.
We know which battles aren't worth fighting, we know how to navigate the organisation, how to get alignment and how to ship, but perhaps the behaviours that make us reliable can also, occasionally, make us conservative.
Sometimes that's maturity, but when there is space to explore, have we found the best solution? Or have we simply become very efficient at avoiding the conversation that might have taken us somewhere else?
And some useful tension disappeared
I don't think the different perspectives within a product team are something we should try to eliminate. I think the tension between them is where some of our best work happens.
Design asks:
What could this be?
Engineering asks:
What can we actually build and maintain?
Product asks:
Is this solving something worth solving?
Accessibility asks:
Who might we be excluding?
The business asks:
Is the outcome worth the investment?
None of those perspectives should win completely and none of those disciplines exist only to constrain the others. Developers can propose ideas designers hadn't considered because they understand technology deeply enough to see possibilities we don't. Product can challenge the problem itself. Accessibility can reveal assumptions about an interaction that fundamentally change the solution. Design can push everyone towards something none of us would have considered from inside our own discipline.
The solution emerges from the tension between them.
Maybe maturity isn't learning how to eliminate friction between disciplines. Maybe it's learning which friction is worth preserving.
As juniors, we created some of that friction accidentally. We simply didn't know enough not to so we proposed the ridiculous thing, someone explained why it wouldn't work. We pushed back, they suggested something else and we changed it again.
They challenged it again and somewhere in that conversation, the ridiculous idea occasionally became something that could actually exist. Not because ignorance made the idea better, (It didn't.) but ignorance sometimes gave the idea permission to exist long enough to be challenged.
As we gain experience, we don't need someone else to tell us why the ridiculous idea won't work anymore. We already know and that's exactly why it becomes so easy to stop proposing it.
Eventually, the external constraints became internal habits
I've had contact with code for a long time. I can read it. I understand enough of what is happening to make adjustments to existing code. But I made a deliberate choice not to become a developer.
Part of the reason was precisely this: I didn't want my ability to implement an idea myself to become the boundary of what I was willing to imagine. I wanted to come up with the crazy idea first and worry about how we were going to build it afterwards. For a while, I thought that protected me from the constraint.
It didn't.
Spend enough time working alongside developers and you learn what is easy, what is difficult and what is going to trigger a very long conversation. You learn what will take an afternoon and what might consume an entire sprint, you learn which ideas could create problems six months from now and eventually, you don't need to know how to build something yourself to know that it's going to be difficult.
And without noticing it, you start designing around that knowledge. I deliberately avoided one way of allowing implementation to constrain my imagination.
Experience found another.
That's useful knowledge. A senior designer should have it, but perhaps experience isn't supposed to tell us what we're allowed to imagine. Maybe it's supposed to help us decide which parts of what we imagined deserve to survive and the more I've thought about this, the less I think we simply became less curious. Perhaps wonder became expensive.
Exploring an idea takes someone's time. A prototype competes with roadmap work. An unusual interaction needs engineering involvement. A cross-disciplinary idea requires expertise we might not have ourselves. Before anyone builds anything, someone often has to justify why the exploration deserves the investment.
So we learn to recognise which ideas probably aren't worth asking someone else to spend their time exploring.
That's sensible. Then we stop asking. Eventually, we stop exploring them ourselves. And finally, perhaps without even noticing it, we stop imagining them.
The external constraint becomes an internal habit.
That's not necessarily complacency. It can simply be adaptation.
We learned these behaviours because the environment rewarded them. But what happens when the environment changes and the behaviour remains?
But some of the walls have moved
This is one of the things I find most interesting about designing with AI. Not because AI is a better designer and not because AI is a better developer.
It isn't about replacing either discipline. What interests me is that it changes the cost of exploration. Previously, an idea might have followed something like this:
Idea → justify the exploration → find the time → involve the right people → prototype → evaluate
Increasingly, it can look more like:
Idea → prototype → evaluate → decide whether further investment is justified
That's a significant change. I can take one of those ideas that experience tells me is probably unreasonable and ask AI to build enough of it for me to see what happens. The implementation might be completely unsuitable for production. It might have accessibility problems, performance problems and edge cases I haven't even considered and that's fine because I'm not trying to ship it.
I'm trying to make the question tangible and this isn't only useful to designers.
A developer can explore an interaction or technical idea without immediately committing a team to it, product can make a proposition tangible before asking for significant design and engineering time, people can explore outside the boundaries of their own discipline without pretending that exploration makes them experts in someone else's.
AI hasn't removed the constraints. It hasn't made accessibility optional. It hasn't removed engineering complexity. It hasn't made maintenance disappear. It hasn't made every ridiculous idea worth pursuing.
It has simply reduced the cost of asking what happens if we try.
And we haven't always moved with them
That's the part I find most interesting. The constraint can disappear before the behaviour it created does.
We spent years learning which ideas weren't worth asking other people to spend time exploring. Now some of those ideas can be explored without asking anyone, but the instinct to reject them can remain.
"That's too difficult."
Maybe. Let's see.
"Engineering won't build that."
Maybe they shouldn't. Let's see what part of it is actually valuable first.
"That isn't how we normally do this."
Probably not. What happens if we do?
AI hasn't suddenly made those objections wrong, but it has made it considerably cheaper to test whether they're right. Maybe one of AI's more interesting contributions to creative work isn't that it gives us better ideas.
Maybe it simply makes curiosity affordable again.
And if the cost of curiosity has changed, perhaps some of the habits we developed when it was expensive deserve another look.
So we can start beyond reasonable and work backwards
Imagine I have an idea that pushes an interaction much further than anything currently in the product. If that idea exists only in my head, I have to explain it, then someone has to evaluate whether it's worth spending time exploring and because everyone involved already understands the constraints, the conversation naturally starts moving towards what is feasible before we've seen what the unreasonable version actually looks like.
But now I can build the unreasonable version first. Not production code and not something I expect engineering to maintain. Just enough to make the idea tangible, then I can put it in front of the people who understand the constraints better than the prototype does.
Maybe engineering says:
"There is absolutely no way we're building this."
Fair enough. But now we have something more useful to discuss.
How close can we get?
Maybe one part is technically ridiculous, maybe another creates a maintenance nightmare, maybe something doesn't meet accessibility requirements and maybe Product points out that half of what I've built isn't solving anything users actually need.
Good. Remove it. Change it. Challenge it.
There are two ways we can approach a boundary. We can start with what we know, take a step forward, check whether it's feasible, take another step and eventually stop somewhere safely inside the boundary.
Or we can imagine something far beyond it, make it tangible, then work backwards until we find the closest point reality will allow us to keep. We don't ship the impossible idea.
We use the impossible idea to discover how much further the possible one can go.
Not because the unreasonable idea needs to survive
This distinction matters. The value of the crazy prototype was never that we expected it to survive. Its job was to move the definition of reasonable.
Sometimes we'll push against a constraint only to discover exactly why it was there in the first place, sometimes the crazy prototype will simply be a bad idea and sometimes everyone else in the room will be right and that's perfectly fine.
It is a bad designer who defends an idea simply because it came from their own mind.
Our job isn't to prove that our ideas were right - It is to find the better solution and those are very different things. We should be willing to push an idea far beyond what seems reasonable, we should be equally willing to throw it away when the evidence tells us to.
There is a difference between being stubborn about an idea and being stubborn about asking the questions.
The idea can go.
The question shouldn't.
The existing solution is allowed to win
Finding the better solution doesn't mean finding a different one. That's important because sometimes the thing we already have really is better.
We might explore the crazy idea, push against every constraint, debate it with engineering, challenge our assumptions and eventually discover that the existing solution was right all along.
Good. That's not failed exploration. That's a stronger reason to keep what we have.
The existing solution should be allowed to win.
But it should win because it is the better option. Not because it was already there.
The objective isn't novelty. It's examination.
Patterns should be challenged, constraints should occasionally be questioned, our own ideas should absolutely be challenged and when something survives that challenge, we understand why we're keeping it. The better solution isn't the one that survives because nobody questioned it.
It's the one that survives the questioning.
It just shouldn't win by default
There is another possibility I've been thinking about and it's a less comfortable one.
Maybe sometimes this isn't about cost. Maybe we've simply become very good at navigating the systems around us.
We know the patterns that work, we know what engineering can build, we know what stakeholders are likely to approve and we know how to get from a problem to something feasible without creating too much friction along the way. That's professional fluency.
But I wonder if we occasionally mistake that fluency for correctness. Pushing beyond the familiar is uncomfortable takes more effort and creates disagreement. It means exploring ideas we might eventually throw away. It means deliberately introducing uncertainty into a process we've spent years becoming better at making predictable. There is no guarantee the outcome will be better and that's fine.
The existing solution may still win. The established pattern may still be the right one. The constraint may survive every attempt to challenge it. But at least then we know why.
It didn't win because questioning it was uncomfortable. It won because after questioning it, we still couldn't find anything better.
Experience should help us judge our ideas, not prevent us from having them
I don't want to forget what experience has taught me. I don't want to become a junior designer again. I don't want to ignore accessibility, technical reality, business requirements, established patterns or everything we've learned about our users.
Sometimes there isn't time for exploration. Sometimes we need the compromise. Sometimes we need consensus. Sometimes we just need to ship.
Experience helps us recognise those moments.
That's once again experience doing its best job.
But perhaps experience should also help us recognise the opposite moments, the ones when there is time to ask the stupid question, to build the unreasonable prototype, challenge the pattern and to discover that engineering was right or that we were.
Or, more interestingly, that neither of us was — and the conversation produced something better. We don't need the ignorance we had when we started but maybe we need something harder.
The willingness to imagine like we don't know the boundaries, combined with the experience to understand what should survive once we find them.
Maybe wonder is simply the willingness to keep asking
When we started, wonder came naturally because we didn't know enough to suppress it.
We asked:
What could this be?
Then experience taught us another question:
What can we reasonably build?
We need that question but perhaps we learned to ask it too early.
Experience isn't the enemy of wonder. It shouldn't be. Perhaps the real danger of experience isn't that it teaches us where the boundaries are. It's that eventually, we stop checking whether they're still there.
We don't need to stubbornly defend our answers. We need to stubbornly keep asking the questions.
What if?
Why not?
Does this constraint still exist?
Does it still exist for the same reason?
What happens if we push it?
How close can we get?
Is what we already have still the better solution?
Was I wrong?
Maybe that's all wonder ever really was. Not ignorance, not endless experimentation and not refusing to compromise. Just enough uncertainty to keep asking:
What could be possible?
So I'll leave this with one final question:
At what point does experience stop helping us see the constraints — and start preventing us from questioning them?