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.

We call this reading the organisation. And it takes four diagnostic questions before Figma is opened.

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 only find out 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 yet 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.

Naming the gap

We call this gap design execution without organisational reading.

The trouble is 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 that solution. 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.

It is also what sits underneath most design maturity gaps, where you have teams that are technically skilled but structurally misaligned with the organisations they are designing for.

What reading the organisation looks like in the first week

At Stampede, user-centred design sits at the core of what we do. Often we associate the word “user” with the end user, the people using the app or service. But there’s a more immediate user of our design work: the organisation itself. To be truly embracing user-centred design, 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 we pay attention to in the first week of any project. The signals are the same whether you are an external or an in-house designer who has been at the company for three years.

If anything, I’d argue that being an in-house designer is harder. Familiarity makes it harder. When you already know a team, it’s too easy to go in with the assumption that you know what they are ready for.

Where do we begin navigating? We begin by asking targeted, strategic questions.

Here is the organisational terrain I encourage my designers to canvas in the first week of their project. It’s four questions and they cover: whether design has ever changed a decision here, who actually holds the authority to act, whether this is a discovery or execution project and what “design” means to the people who will use the output.

Let’s take a look at what each of them means.

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.

Here, 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?

Within the Malaysian present context, 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.

So ask them directly: 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 grid

The grid maps two readings against each other.

• Design’s track record. This is the vertical axis. Has design influenced decisions here before, or is it still earning that standing? This tells you how much trust you are starting with, before you have produced a single thing.
• Design’s role. The horizontal axis. Has design been brought in upstream to shape the problem, or downstream to execute a direction already set? This tells you how much of the problem space is still open, and how much has already closed without you.

Together, they place you in one of four positions, each with a different opening move.

Top-left: upstream, design has changed decisions here
The rarest configuration. The team has a track record of acting on what design surfaces and you have been given genuine access to the problem. The risk here is not failure — it is wasting the position by playing it safe. Take the harder problem, not the safer brief.

Top-right: downstream, design has changed decisions here
The team trusts design but the direction was already set before you arrived. This is not a slight but simply where you are in this cycle. The mistake is spending energy trying to reopen a brief that was never meant to be reopened. Execute sharply and find the one decision still live to continue earning the trust.

Bottom-left: upstream, design has not changed decisions here
The most common configuration for designers entering a new organisation or team. The mandate looks open but the organisation has no muscle memory for acting on what design surfaces. Building up to a big reveal means your findings arrive after the decisions have already closed. The team will nod, note it for next time and move on. The antidote is to structure your work in batches. Share findings while decisions are still live and people can still act on them.

Bottom-right: downstream, design has not changed decisions here
You have a defined problem but no established credibility yet. The temptation is to overdeliver on the brief to prove worth. The more effective move is to make your reasoning visible alongside your output, how you got there, not just what you produced. That is what shifts the position over time.

What design means and who has the authority

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, moving too cautiously where the mandate is genuinely open would lead to the window closing 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.

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 start with the piece of work that earns 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.

The post Good designers read the brief—great ones read the organisation appeared first on Stampede: the strategic design & technology company.

This scenario plays out more often than you might think – products that work perfectly fine on paper, but somehow fail to truly resonate with users in practice.

Why teams skip live testing (and why that’s understandable)

Let’s be honest – when you’re managing a product team, live testing often feels like a luxury you can’t afford. You’re juggling feature requests, fixing bugs, meeting deadlines and keeping stakeholders happy. The product is live, metrics are “okay,” and testing seems like something that can wait.
We get it. We’ve worked with enough product teams to understand the reality:

• Your backlog is already overwhelming
• Resources are stretched thin
• Stakeholders want new features, not refinements
• Getting access to real users is challenging
• Testing could disrupt existing workflows

But what I’ve learned time and time again remains true: skipping proper testing now almost always costs more in the long run. When products evolve without deep user understanding, teams end up building features that don’t solve real problems, fixing symptoms instead of root causes, and missing opportunities for genuine improvement.

What live testing really reveals: three stories

Story 1: The Trust Deficit

A few years ago, while investigating an underused performance monitoring feature in an enterprise reporting application, we discovered something unexpected. Users had developed elaborate verification routines, double-checking every number in Excel. Why? A lack of trust in the data, stemming from inconsistent data input and unclear data lineage.

The solution wasn’t in the dashboard design – it was in fixing the upstream data collection process and making data sources transparent.

Impact: The improved data collection process and transparency transformed how teams used the system. Analysts stopped maintaining parallel Excel sheets and began trusting the platform for critical decisions. Team leads reported more confident decision-making in planning meetings and the platform became their single source of truth for performance discussions.

Story 2: The Presentation Paradox

We were brought in to find out why a reporting dashboard was failing to drive action in executive meetings, despite its sophisticated analytics capabilities. Live testing revealed the core issue: we were forcing a long-form analysis tool to serve as a presentation medium.

This led to a breakthrough solution – creating a separate presentation mode that prioritised narrative flow over deep analysis, allowing presenters to tell clear data stories while maintaining access to detailed insights.

Impact: The new presentation mode transformed how teams communicated data insights. What was once a source of confusion in executive meetings became a powerful storytelling tool. Leaders could now focus on strategic implications rather than questioning the numbers, leading to more decisive actions based on data insights.

Story 3: Hidden Opportunities

Late last year, I was part of the team at Stampede who were tasked to conduct a UX gap analysis for Malaysian government. We tested a startup ecosystem accelerator website with real users to identify the gap, but walked away with so much more. Not only did we identify immediate usability issues and recommended practical fixes, we also discovered unexpected ways users were finding value in the platform.

Impact: Beyond addressing the immediate usability issues, the insights led to the development of new services that better matched how startups were actually using the platform. The client was able to evolve their offering from a simple resource website to a more comprehensive support platform that better served their ecosystem’s needs.

The Stampede Approach: What’s the (whole) story?

While many testing approaches focus on isolated aspects like UI or functionality, our methodology is designed to give product teams a holistic, more complete picture. To us, real insight comes from understanding not just how users interact with your product, but how your product fits into their broader work life.

Our approach combines both quantitative and qualitative methods, because we’ve learned that neither tells the complete story alone. When we spot a pattern in the data, we investigate the “why” through careful observation. When we observe interesting behavior, we validate its significance through data. This dual-lens approach helps establish clear causation, not just correlation.

Making it work: our testing methodology

Live product testing isn’t just about watching users click through interfaces. It’s a carefully orchestrated process that begins long before we meet any users and continues well beyond the testing sessions themselves. The team has refined our methodology through years of testing products across different scales and industries, from startup platforms to enterprise systems.

Here’s what we do and why they are effective.

Setting the foundation well

We begin by understanding the product context deeply. Having focused conversations with stakeholders to understand business goals and constraints, reviewing analytics to spot patterns worth investigating and designing research that fits your specific situation are all necessary homework. We’re particularly careful about selecting participants who can provide relevant insights – people who use your product in meaningful ways as part of their daily work.

As UX designers, what we look for is striking the right balance between rigour and flexibility. While we have a structured approach, we stay adaptable to product team’s needs and constraints. This thoughtful preparation helps us maximise the value of every testing session while minimising disruption to their operations.

Testing approaches

1. Direct Live Testing

We observe users interacting with your actual live product in their natural work environment. This means watching real tasks being completed with real data and real stakes. It’s like shadowing a user through their workday, observing not just how they use your product, but how they integrate it into their broader workflow. While this approach requires careful planning to avoid disrupting production systems, it often reveals the most valuable insights about how your product is actually being used in the wild.

2. Staging Environment Testing

Think of this as a dress rehearsal with your product. We create a testing environment that mirrors your production system, complete with realistic data and workflows, but in a controlled space where we can safely observe user behaviour. This approach is particularly valuable for financial systems, healthcare platforms, or any product where testing in production isn’t feasible. The key is making the staging environment feel real enough that users interact with it naturally.

3. High-Fidelity Prototype Testing

Sometimes we need to recreate specific parts of your live product as an interactive prototype. This might be because we want to test a particular user journey in isolation or we need to simulate a specific state of your product that’s hard to replicate in the live environment. As we carefully rebuild these scenarios, we can focus user attention exactly where we need it and iterate quickly on potential solutions.

Multi-method integration

Sometimes the most powerful insights come from combining methods:

• Using analytics to identify patterns, then investigating through live testing
• Combining prototype testing with live system observation
• Validating qualitative insights with quantitative data
• Cross-referencing findings across different user groups and contexts

When to consider live testing

Every product team faces moments when they need deeper insights than analytics alone can provide. Perhaps your metrics look good but user feedback suggests otherwise. Or maybe you’re planning a major evolution of your product and need to ensure you’re moving in the right direction.

Live product testing delivers particular value when:

• User adoption isn’t meeting expectations despite good technical performance
• Users are creating workarounds to your carefully designed processes
• You’re seeing high task completion rates but low return usage
• Feature usage patterns don’t align with your product strategy
• You’re planning significant product evolution and need ground truth

Often, teams discover that live testing would have helped them avoid months of misdirected development effort. The insights gained typically go far beyond the initial scope of investigation, revealing opportunities for improvement that weren’t visible through other methods.

Ready to bridge the gap?

So what could look like a simple usability issue at first, could signals a deeper opportunity to make your product truly work for your users.

This is what fascinates me about live product testing: the way small, everyday user behaviours can point us toward significant opportunities. Time and again, I’ve seen how these insights help teams avoid months of building solutions for the wrong problems.

Your product likely has similar stories waiting to be uncovered. While you focus on keeping your product running and delivering new features, we can help you spot these patterns and understand what they’re telling you about your users’ real needs.

—

If you’re wondering about the hidden potential in your digital product, we’d love to hear your story. Reach out to studio@stampede-design.com

This post is part of our ongoing series about evidence-based product evolution. Follow us for more insights about building products that stand the test of time.

The post Live Product Testing: The gap between working and working well appeared first on Stampede: the strategic design & technology company.

When I first joined Toro, which is a product team in Stampede (torotimer.com), the team was in the midst of a sprint. For those who are not familiar with sprint, it is a set period of time during which specific work has to be completed and made ready for review, usually involving the product owner, the design and development teams. The outcome is usually a prototype or solution to a problem, alongside valuable insights about customer needs and preferences.

In my case, the sprint focused on a freelancer product, which we internally called as Toro Freelancer. My colleague Luqman and I set out to build a new prototype for Toro, as well as being responsible for the testing research plan and participant recruitment.

Lesson 1: It’s okay to take a step back to solve the problem

From the ideas we had, the product owner selected a few viable ones, but also realised that they were skewed towards a known solution space. There are many solutions out there to help freelancers get paid easier, and beating this dead horse won’t really help our users in a meaningful way.

What we missed were strong ideas for helping our freelancer improve their productivity in a way that is sustainable for them. Realising this, we took a step back to shift our focus on the right problem.

Lesson 2: Standing out from the competition

Initially, I thought it was merely a minor issue to miss the step of having solid ideas for the right problem. But after the testing later on I realised one more lesson, which is that in making a product, we need to differentiate ourselves from the competitors, not just create another similar tool in the market.

Focusing on user’s problem in being productive sustainably really tested our product market fit. If we did not take a step back to focus on that opportunity, we might just waste our time creating another common quotation/invoicing tool, getting further from our goal of making freelancers subscribing for Toro.

Lesson 3: Be selective about what we want to test

One lesson that I learned from prototyping is that we need to be selective in what we want to test. Not everything has to be interactive in a product test. Sometimes we may want to keep a non-interactive item like a button that cannot be clicked, so we can ask the user to guess where it might lead. Test time is limited and this will help us to be more efficient and focused on the actual hypothesis we are testing.

Lesson 4: Be intentional in design

Another lesson is to be intentional in prototype design, to the small details. I learned this from a situation where I only randomised the variation height of bars in the chart, without any deep thought. However, during the testing, the users interpreted the bar chart in a certain way, like the chart was designed intentionally to show something. At that moment, it exposed my bias that some users actually do think and care about the tiny details.

Being intentional with the details is also another reason why we need to design the prototype with a smooth continuity so that users are not confused, surprised or distracted. For example: add a confirmation modal first to smoothen the flow, remove an existing CTA which can distract the user from the tested path etc.

Lesson 5: Ask the right questions to screen the right users

As I was taking the lead for user recruitment, initially I was thinking of an easy path: Edit an existing screening survey, spread it anywhere, pick the users and schedule the slots.

I did not expect it would be hard and time-consuming to find the right users. It was a moment of clarity for me as to why a certain UX agency has dedicated researchers only for user recruitment.

The screening survey attracted many scammers because of the monetary incentives, plus it was posted not in the right channels. We mitigated this by verifying through their LinkedIn profile or portfolio link.

Asking the right questions also means only asking the essential questions. I learned the hard way that sensitive questions, such as gender and marital status can be intrusive, especially when they do not carry any weight in finding the right users. Essential questions could make the screening form shorter, which would mean less friction for the users while providing enough info for designers to filter them.

Lesson 6: Be pragmatic, not dogmatic

Finding the right channel to funnel quality users was also important. What worked in the past might not work this time. After getting so many wrong users in the list, I started to think “If I were an established freelancer, where would I be to connect with like-minded people?”. I eventually hit a jackpot when I found a few Slack channels that vet the users to ensure a sustained professional community.

The benefits of getting the right users would later be manifested in the quality of the testing. The users could really relate well with the prototype especially when it was able to solve their pain points. I was super relieved when the right users stress-tested the prototype. Seeing what worked or did not work for them gave us some ideas on how we were gonna tackle the next step of the product.

Lesson 7: Making mistakes is a part of growth

Understanding different accents, handling internet connectivity issues, users being very prescriptive or just providing short simple answers, and managing time limits can be challenging to the facilitator. Having diverse users tested my ability to manage these sessions. As it was my first time handling a testing, having a more experienced designer observing me and providing detailed feedback improved my facilitation skills after each session.

I made the mistake of asking too many questions early on about what the user understood from the prototype. This consumed a lot of time and did not provide insight into whether the feature was useful (and how) or not (and why not). The reason we had testing in the first place was to test the prototype by understanding users’ thoughts on how the prototype would or would not solve their problem.

After conducting the testing, I feel more confident to do user interviews/testing. At the same time, I want to keep training those muscle memories until my interviewing skill becomes natural.

Another lesson that I learned is we sort of established rapport with the users. They could be a great resource if we have questions related to our product research, such as the reason they are using separate tools for invoicing and time tracking. Some of the users were so willing to help us, and they were just an email away 🙂

Lesson 8: On deciding what to ship

As a product designer, I had a sense of ownership to carry the product to success. However, I had a lot of uncertainty about how to nudge the team in the right direction when prioritising features for the minimum payable product (MPP).

During the testing, we tested a lot of features based on our research. However, in reality, achieving the ideal state of a finished product requires going through multiple release cycles, which can take months or even years.

So how do we prioritise certain features to ensure we are on the right path for users to start paying for Toro? What if our MYP is similar to all the other tools in the market? Will users be willing to pay for it?

The testing showed that we have a Unique Selling Proposition (USP) module that can differentiate us in the market, as it solves major pain points for users. However, shipping that module requires a lot of effort and other foundational features to be shipped first.

Since we do not want to release a half-baked product, should we build all those features, including our USP module, before releasing the subscription plan?

All of these questions were on our minds. After further reading and asking a few designers in the industry, we initially thought that a prioritisation workshop would provide more clarity on the path forward due to the inputs from the team. However, in our case, Shaza as the product owner, is well-versed in the feasibility, viability, and desirability, and this part is the product owner’s call to make, not the team’s. We learned that we should have discussed with the product owner first the best way this should be done.

Lesson 9: Learn from history

Later, I learned that Figma did not have the collaboration feature when it was first launched. There are many examples of successful startups that launched their products without their best-known features yet. What is more important is to ship, measure, and learn, rather than dwell in the uncertainty of which features to ship first.

Nobody can predict the future, but we can try to make the best decision at the time with the info that we have. If we fail, we need to fail fast and iterate. If the minimum viable product does not go the way we wish, at least it saves us from wasting our time and effort on the queued features. At least we learn what is working and what is not.

Lesson 10: Size the development effort carefully

I also learned that a feature might carry more complexities than I initially thought. If we overlook certain details, it might surprise us in the development phase. For example, can the user edit the invoice that has been sent? What if we allow the invoice to be edited if the client hasn’t seen the invoice on Toro platform? How sure are we that the client hasn’t seen the invoice?

Thus, it is important to collaborate with the developer to understand what the considerations and technical constraints are to build the feature and to be specific (to a certain extent) so that developers won’t undermine the actual efforts needed.

That concludes our 10 lessons. If you have any tips or best practices for designing valuable products, please share them in the comment section 👇

The post 10 Lessons from Designing A Product appeared first on Stampede: the strategic design & technology company.