Stampede Design
I can tell a lot about a designer from their first week of a project. Not from the quality of their early screens, but from what they do before they produce anything.
The designers I trust with the most complex briefs share one habit. They spend the opening days of a project reading the organisation before they read the brief. They work out what this team can absorb, what it can act on, what will land and what will sit in a folder regardless of quality.
They do this before ideation. Sometimes, before they ask a single design question.
The ones who skip this step are not worse designers. Often they are better at the craft and so that makes this harder to see.
Strong visual execution earns early praise. The feedback loop is immediate and feels like progress. Nothing in that signal tells you it is pointing in the wrong direction.
But approval in a design review and influence over what actually gets built are not the same thing. Most teams are too polite to say the work missed the moment. They praise it, note it for future reference and move on. The designer leaves the room thinking it went well. They find out otherwise much later, when the product ships, that their work gets partially used, quietly reduced or shelved for a future sprint that never comes.
It is usually not a design problem
When good work goes nowhere, our first instinct is to question the work. Should we refine the flows? Improve the fidelity? Perhaps present better?
The more I have watched this pattern, the more I am convinced the problem is almost never the quality of the design. It is the sequencing.
Sequencing, in design work, means understanding what the organisation is ready to receive and act on before deciding what to produce. The best method applied at the wrong moment is not rigorous—it is wasted.
We often look at constraints through the lens of budget, timeline and trade-offs. Those are real. But they are not what determines whether work lands.
The more consequential constraint I’ve seen is organisational readiness: what decisions are still live, who has the authority to act on findings, whether design has ever changed anything here before. That is what the order of design operations has to be built around, not the project plan.
This is what it looks like in practice
Part of working closely with in-house teams is that we get to observe how designers navigate the gap between what they are given and what they are set up to succeed with.
We worked with an in-house designer who was doing everything right. She received the requirements, hit the timeline and thought through the trade-offs. The solution was considered and beautifully executed. It was current, polished and genuinely impressive. The review was glowing.
And none of it made it into the final product.
The brief had given her enough room that she took it as a mandate to rethink the problem. So she did. What she did not know was that product and engineering had already aligned on a direction before the requirements reached her.
When her solution landed in the room, it was too ambitious for where the team was. They praised it, parked it for a future redesign that may or may not come, and shipped what the developers had already built. It was faster. It was good enough and it was already done.
Her frustration was legitimate. She had done the work. What she had not been given, and likely did not yet know to ask for, was the context of whether the team was ready for ambition or needed execution.
This sounds familiar because a brief only tells you what to design. It almost never tells you what the organisation is ready to do with it.
Naming the gap
This is design execution without organisational reading.
Design education teaches craft and method. It teaches designers to solve the problem in front of them. What it almost never teaches is how to read whether the organisation is ready to receive what that craft will surface. Whether the problem is still live, whether anyone has the authority to act on the answer, whether the conditions exist for the work to land at all.
That is a different skill entirely. Without it, the craft goes to waste.
What we now watch for in the first week
At Stampede, we talk a lot about being user-centred. In our minds, the user of design is the end user, the people using the app or service. But we often forgot the more immediate user of our design work: the organisation itself. To be user-centred, we must serve this group first.
As such, meeting people in the organisation where they are, not where we think they should be, is not a compromise. It is the work.
That shift in thinking changes what I pay attention to in the first week of any project. The signals are the same whether you are an external consultant or an in-house designer who has been at the company for three years.
If anything, familiarity makes it harder. When you already know a team, you start to assume you know what they are ready for.
Here is the organisational terrain I encourage my designers to canvas in the first week of a project.
1. Has design ever changed a decision here?
Not whether they have a design system. We’re asking whether past design thinking has visibly changed what the product became.
A team that says “we tried a different pattern for that flow and it didn’t perform” uses design as evidence. A team that says “we did a big redesign two years ago” and moves on is using it as a credential. Those are not the same thing.
2. Who actually has the authority to move this work forward?
Not who is in the kickoff room. In many Malaysian organisations, hierarchy shapes how decisions are communicated as much as how they are made. Disagreement with a senior leader rarely surfaces directly in a meeting but rather moves through other channels, later and quietly.
In many Malaysian organisations, the most senior person in the room will nod, stay quiet or say the work looks good. That doesn’t necessarily mean a decision has been made. The actual decision-maker is often a layer up and they may be absent from the brief and reviews and only visible when a direction gets quietly reversed after a presentation they were not in.
The answer to who has the authority is not always obvious and has to be inferred from who the room defers to when a direction is questioned, from whose silence carries more weight than anyone else’s words.
3. Is this a discovery project or an execution project?
Design can enter a project at very different points.
Sometimes it is upstream, where design is involved before the solution exists, helping shape what gets built and why.
Sometimes it is downstream and designers are brought in after the direction has been set, to design it well and make it real. Both are legitimate but not interchangeable.
Engineering-led teams, common in our market, often scope and estimate the solution before design is involved. By the time the brief reaches the designer, the upstream decisions have already been made, and often in conversations that happened weeks earlier. What remains is now a downstream ask: take this direction and make it work.
That is not a lesser role. But treating it as an open mandate when it is not will most likely backfire on good intentions and erode the team’s trust in design as a function.
4. What does “design” mean to the people who will act on it?
In many Malaysian organisations, when a team says they need a designer, they mean someone to produce screens that are clean, polished and on brand. That is a legitimate ask but it is not the only thing design can be.
The gap opens when a designer assumes they have been brought in to shape the problem. To run discovery, frame the brief, challenge the direction, while the team assumed they were getting someone to make the solution look good. Neither party states their assumption. In a high-context culture like ours, neither party will.
In a high-context culture like ours, this gap rarely surfaces directly so we have to be intentional with asking them: when they say “design”, do they mean making it look good, making it work better or making the right thing in the first place?
Where does asking these questions lead us?
Together, these four questions give you a clear, precise picture of what this organisation is actually ready for and where design sits within it.
Design’s track record tells you whether design has influencing power here. Whether it has ever been the reason a direction changed, or whether it has only ever been the thing that made a decision look better after it was already made.
Whether the role is upstream or downstream tells you something about access. It is how close to the problem design is allowed to get before the solution starts forming without it. In most Malaysian organisations, this is not stated in the brief. By the time it reaches you, the direction has often already been set, very likely in conversations you were not part of. What looks like an open mandate may already have walls around it.
Those two questions provide you with a reading and an opening move to consider.
The other two questions, what “design” means to the people acting on it, and who actually has the authority to move the work forward serve as your operating conditions. They don’t change your position on the grid but they determine how much friction stands between you and the opening move your position calls for.
For example, a designer in the right quadrant who cannot get the real decision-maker in the room, or whose definition of design doesn’t match the team’s, is working against resistance that the grid alone won’t show.
The grid tells you how to start, not how to stay. Position shifts as credibility builds and as the team’s appetite for design’s involvement grows. Misreading it in either direction is costly, so it helps to be honest about where you actually are rather than where you would like to be.
You may move with too much ambition where trust hasn’t been established, risk getting the work admired but ultimately shelved. On the other hand, move too cautiously where the mandate is genuinely open and the window closes before you’ve used it.
Like in chess, the question is not what the ideal move looks like. It is what move is available from where you are standing right now.
Know your position. Know your conditions. Then decide how to move.
The opening move is a design decision
For designers trained to do thorough work, the best move may be counterintuitive to what you really want to do and the impact you want to make. Choosing a lighter scope often feels like settling.
The truth is, arguing for a bigger move before you have earned the standing is the most common mistake. It is also the most avoidable one.
The designers who moved the furthest in the organisations I have watched did not start with the most ambitious brief. They would start with the piece of work that would earn them enough trust. This then creates a shared language and wins to make the next move possible. They chose the move deliberately, not out of safety but because it was right for where the organisation was.
The right opening move is not the most thorough piece of work you could produce. It is the piece that shifts the organisation’s position. One that shows a sceptical PM what research actually surfaces, or gives engineers and designers a shared reference point for the first time.
Small work that shifts a position is worth more than ambitious work that lands nowhere.
The grid is not to limit what you do. Rather, it tells you what to do first.
What this means for how we develop designers
This habit of reading the organisation first is learned. Nobody arrives with it.
How quickly it develops depends on the environment around the designer. The leadership models, what managers enable and what product teams make visible. It is a shared responsibility and it looks different depending on where you sit.
If you are a designer The fastest way to develop this is to be in the room before you are asked to produce anything. The kickoff. The stakeholder introduction. The early conversations where nothing has been designed yet. That exposure starts as observation but must become active: forming your own read of the room, testing it against what emerges, adjusting before the brief hardens.
If you are a design leader The designers who develop this fastest are the ones you bring into those rooms deliberately. Not to present. To observe and to learn. This is the education many senior designers still need and rarely get. Without it, the only way to learn is from having work go nowhere enough times that you start asking different questions. That is a slower and more demoralising path than it needs to be. You can shorten it significantly.
If you are a product manager The designers who will serve you best are the ones who understand what your team is ready to act on before they design anything. You can accelerate this by being transparent early. Share with them what is already decided, who needs to be in the room and what success looks like to the people above you. That context is not a constraint on the design. It is what makes the design useful.
A designer who reads the room well and starts simply will outperform a designer who starts ambitiously in the wrong direction. Every time.
—
If this resonates and you are trying to work out what your design practice is ready for next, I would be glad to think it through with you. You can find me on LinkedIn or reach out to our team.
