I used to use my gut feeling and intuition to tell what’s good and what’s not, even for critiquing my own designs and work.

Not because I was careless. I genuinely believed I had been thorough. I had spent hours on it. I believed I had looked at it from every angle. It felt right and that ‘feeling’ was the problem.

Being close to your work is not the same as understanding it. And for a long time, I confused the two.

Skipping self-critique has real consequences. They just tend to show up at the worst possible moment. Work gets submitted with decisions that were never challenged. When a reviewer asks why something was done a certain way, the designer either can’t answer or scrambles to reconstruct a rationale they’ve already forgotten, or hasn’t ever considered.

Inconsistencies slip through. A spacing rule applied on one screen but ignored on the next. A hierarchy that made sense in isolation but breaks down across the flow. Trust erodes quietly. Not because the designer lacks skill, but because the work still carries the fingerprints of someone who was too close to it when they called it done.

Over time, the absence of self-critique doesn’t just affect the output. It limits how fast you grow. Without the habit of interrogating your own decisions, you stop building the vocabulary to explain your craft to yourself, your team, and the people you are designing for.

The real design self-critique failure mode isn’t laziness

Usually, designers do look at their work before submitting. That’s not where the gap is.

The gap is that they critique against nothing.

No ground. No principles. No framing. The review becomes: does this look right? Does this feel good? And because you made it, it almost always does. Your eye is already calibrated to what you built, not to what was actually needed.

This is especially common for middleweight designers. Not because we are less capable, but because nobody explicitly teaches this in our culture, especially if you’re self thaught. You learn to execute. You learn to iterate. But the practice of interrogating your own decisions before anyone else does is rarely discussed, rarely modelled, and in many design teams here in Malaysia, rarely even practised.

The word ‘critique’, already carries weight in Malaysian context. It sounds like conflict. It sounds like something that happens to your work, not something you do for it. That mindset has to change.

Design self-critique needs a ground

Here is what I have learned: self-critique is not a final step. It is only possible if you have set the foundation upfront.

Before you open Figma, before you write the first word, before you decide on a layout, ask yourself: what user outcome am I solving for? What principles am I carrying through this work? What does good actually look like here?

That is your ground. Everything you build gets measured against it, not against whether it looks polished.

When I started doing this, the critique became less subjective and more structured. I could ask real questions. Why did I use rows of three in this card list? Why this colour here? Why this hierarchy? If I had a reason and a grounded reason tied to the framing, the decision holds. If I could not answer, that was the critique finding me first.

Not intuitive. Intentional.

Write your rationale down as you go

The second shift was documentation, not for handoff, not for the client, but for myself.

Every design is a sequence of decisions. And most designers make those decisions well in the moment, then let them disappear. The rationale lives in their head, and by the time a reviewer asks why, they have either forgotten or can only reconstruct it verbally on the spot.

Writing decisions down as you go changes this completely. Not everything. Just the ones that matter. Why you chose this approach over the alternative. What you were optimising for. What you deliberately left out.

When you include your thinking alongside the work and not just the visual, but the reasoning behind it, two things happen. First, you are forced to articulate what you actually believe, which sharpens the thinking. Second, when you come back to critique, you have something real to interrogate. Not just a screenshot, but a position, grounded against your foundational framing.

A reviewer asking why you made a decision should never catch you off guard. If it does, that is a signal that the critique was incomplete.”

And now with AI where you can augment the design assembly process, it is more and more critical to be conscious about the goal, principles and how to execute at every step along the way. This is what design work look like at Stampede, less executing and assembly, more strategic thinking and tactical planning.

Create distance before you do self-critique

The third thing, and the one most junior designers skip entirely: walking away before you review.

After a session of deep work, you are still the author. Your eye will fill in the gaps, smooth over the rough edges, and read what you intended, not what is actually there. You are too close to see clearly.

The fix is temporal distance. Close the laptop. Do something else. Come back in half an hour, or better, the next morning.

I have finished work in the evening and told myself I would do the self-critique first thing the following day and come back to find things I simply could not have seen the evening before. Not because I was tired. Because I had forgotten what I was trying to do, and that forgetting is exactly the point. Fresh eyes read the work the way a user would, not the way its creator would.

Seasoned designers can do this in real-time. They have developed the ability to zoom out mid-flow, switch modes, and critique in live. That is the goal. But for most of us especially Malaysian middleweights, the shortcut is physical and temporal separation. And it works.

The other thing worth naming: do not be married to what you built. Don’t be afraid to murder your darlings. This sounds obvious, but it is harder than it sounds. When you have spent hours on something, it’s only natural to defend it. You will subconsciously frame your review to protect the decisions you have already made. The only way past this is to approach the review with genuine openness. Treating your own work the way you would treat someone else’s.

Sharpen the eye by dissecting other people’s work

Self-critique gets easier the more you study good work.

Not to copy it. To understand it.

When you open an app, a website, a data visualisation, pause and ask why things are the way they are. What is the grid? Why this spacing? Why does this interaction feel smooth when a similar one elsewhere feels clunky? What is the overarching principles and the intent of the design? What is it trying to solve ultimately?

Most of us consume design passively. We notice when something looks nice. Few of us stop to deconstruct why it works and fewer still ask why it doesn’t, even when it looks fine on the surface.

The more you practise this on other people’s work, the more naturally you do it on your own. You start to notice the questions before a reviewer does. You start to ask, before anyone else: if someone looked at this with fresh eyes, what would they challenge?

That shift from creator to first critic, is what the practice is building toward. It’s building that muscle so it comes natural to you the more you mature as a designer.

Where this ends up

Eventually, none of this should feel like extra work. The framing, the documentation, the distance, the dissection. These should become so embedded in how you work that finishing and critiquing are the same act.

For designers who have been self-critiquing for over twenty years, that is already true. The critique is happening constantly, live, almost invisibly. It is in the DNA.

For the rest of us, we build toward it. We make the scaffold visible until it becomes instinct.

The measure, for now, is simple: before you ship, can you answer for every decision? Not defend it. Just answer for it.

If you can’t, you are not there yet.

The post Building the Eye: A Guide to Designer Self-Critique appeared first on Stampede: the strategic design & technology company.

Every stage before UI execution has a clear handoff. Research, define, ideate, validate. AI has accelerated all of them. Landscape analysis in hours. Prototypes in less than a day. And then we hit UI execution, and everything slows down.

This is where designers go quiet. Where iterations happen alone. Where the wireframes get translated into screens by hand, component by component, in silence. And then the hours pile up. On top of that, the mental load builds. The rest of the team moves on while you are still assembling.

UI execution is different from the stages before it. It is not one handoff. It is hundreds. Every screen, every component, every state, every variation is counted. You are holding the user research, the product constraints, the design system, the technical constraints, and the business goal all at once, and translating them into pixels one decision at a time.

The rest of the process speeds up because AI is good at synthesising from context. UI execution stayed slow because it is about assembling, with hands, and we never separated the assembly from the parts around it.

Until I ran an experiment to see if that could change. If agentic UI execution could work. I got it!

How agentic UI execution works

Three pieces work together. Claude holds the context. Everything I know about the user, the product, and the business is stored in a Claude Project. Figma Console MCP is the bridge between Claude and where your design happens, or I would say, your canvas. And Figma is where the work happens. The screens get built in the source file, using my actual design library that I built.

Think of Figma Console MCP as a connector, not a plugin. It brings Claude directly inside my Figma environment, reading what is there and executing changes on my actual files, with my components, my tokens, and my structure.

Claude is not working from a description of my design system anymore. It is working from the source.

I chose Claude specifically because my project context already lives there. Everything Claude knows about the project travels with it into Figma. That continuity is the whole point.

I am a product designer, and I am proud of three things in my work

The taste

Knowing what good looks like. Judging which component fits the context, what hierarchy feels right, where to break a pattern and where to hold it.

The craft

The foundational design knowledge. Principles, typography, spacing, accessibility, interaction patterns. The stuff that took years to build.

The assembly

The act of putting it all together. Taking the user flow, pulling from the design library, constructing the screens. Making something usable and buildable.

We usually talk about these as one job. They are not. They are three.

The assembly part is what’s actually draining us

The taste stays fun. The craft stays meaningful. The assembly is what drains us. It is manual. It is costly. It is tedious. It is the part that takes hours and leaves you with nothing to show for your skill, because the skill was spent on repetition, not judgment. If assembly stops eating our time, here is what we get back.

🕒 Time
Hours that used to go into building screen variations can go into the work only a designer can do.

🔥 Cost
Less designer time on mechanical work means projects move faster, and design becomes cheaper to scale without losing quality.

🧠 The mental load
No more holding every decision in your head. No more losing context every time you switch tools. No more translating feedback and ideas back and forth between Figma and everywhere else.

That last one is the part that keeps me up at night more than the others.

What success looks like

Before I introduce the tool, let me say what I was trying to achieve.

AI as the context keeper.
The information about the user, the product, and the business should travel with me into Figma, not get re-explained every session.

AI as the assembly assistant.
The mechanical work of putting screens together should be something I review, not something I build from scratch.

Taste and craft stay human.
These are the parts I want to protect, because these are the parts that make the design good.

Unlocking the capability

To get there, three things need to work together: Claude and Figma connected, your design library machine-ready, and your context is set up properly.

What you’ll need before you start

• Figma desktop app (MCP does not work in the browser version)
• Claude Pro or higher (for Claude Projects)
• A design library that meets the criteria below

Okay now let’s get to it!

1. Set the stage: get Claude and Figma talking to each other

Two things need to shake hands first. A bridge and a token.

1.1 Install Figma Console MCP
Follow Figma’s official MCP setup guide in the desktop app’s plugin settings. The browser version will not work here.

1.2 Set up the token
The token is a personal access key from your Figma account settings. It is how Claude gets read and write access to your files. Go to Figma > Account Settings > Personal Access Tokens to generate one.

1.3 Verify the connection
Once the bridge is running and the token is in place, test it. Direct Claude to draw a pink circle in Figma. If it appears on your canvas, that is the handshake. You got it right. But if it does not, restart the bridge, check the token scope, and try again.

1.4 Give Claude your project context
Claude needs to know about the project before it can help. I use Claude Projects to keep everything in one place: user research, product requirements, business goals, design principles, brand guidelines. All uploaded as files so Claude can pull from them in any chat I open.

This is the part that makes Claude a context keeper. Without it, every session starts from zero.

Once the connection is working, the next constraint is your design library. This is where most of the real preparation happens.

2. Get your design library machine-ready

The setup is the easy part. The real work is making sure your design library is something an AI agent can actually read and use. This is foundational work the whole team benefits from. It is not a designer’s side project, and it is exactly the kind of investment designers are positioned to make.

Four things matter.

2.1 Complete variant states
Every component covers all its states: default, hover, focused, disabled, error, loading. Gaps force the agent to improvise. And improvisation is where drift starts. The agent fills the gap with something that looks plausible, and your library slowly stops being the source of truth.

2.2 Annotated component descriptions
Each component carries a usage note. When to use it, when not to, what it signals to the user. Without this, the agent picks by shape, not by intent. A button that looks secondary gets used as a secondary button, even if it was designed for a destructive action. The description is what tells the agent why the component exists.

2.3 Token-linked styles
Colour, typography, spacing, all tied to tokens, not hardcoded values. The agent applies decisions through the token system. Hardcoded values break propagation, and propagation is how a design library stays consistent at scale.

2.4 Auto layout throughout
Components built with auto layout so the agent can resize and reflow without breaking structure. Fixed frames produce fixed output. If the agent cannot resize a component to fit the context, it either breaks the component or skips it.

The principle underneath all four is the same. The agent is not looking at your library. It is reading it. Everything that communicates visually to a human needs to communicate structurally to a machine. And if you are not sure where your library stands, Figma Console MCP can also help you audit it. Get it to flag what is not readable before you start building.

Once the setup is done and the library is ready, it is time to see it work.

3. Run your first wireframe-to-UI test

3.1 What context to give Claude
The context I give Claude before any screen gets built is more important than the prompt itself. Claude needs to understand the intent and the goal of the screens before it can build them. Here is what I put in the context:

👤 The user, and what they are trying to do.

📦 The product, and what problem it solves.

💼 The business goal behind this particular screen.

🎨 The design principles I want Claude to respect.

And then: the wireframe I want Claude to turn into a UI.

3.2 The context engineering that worked

3.3 What came back and what needed refinement

And… that was it! That was the test. But let’s look at where this actually changes the workflow.

The part where it improves our workflow

The real value is in the work where we actually spend the most hours, pushing pixels when it should be more efficient.

Derivative design.
Take one approved master screen and generate the rest of the flow. The settings page, the profile page, the confirmation page. What used to be hours of building from scratch is now a review pass. The time went somewhere better.

Different states.
Take one approved component and generate every state. Default, hover, error, loading, empty. What used to be tedious multiplication is now a review pass.

This is where the shift in where your time goes becomes obvious. You are not assembling the variations. You are reviewing them. And the review is the part that needs your judgment, so your time is finally going to the work only you can do.

Agentic UI design execution in your workflow

With the setup in place and the library ready, MCP becomes part of how you work. Here is the honest perspective.

Where it helps.
File hygiene becomes automatic. Layer naming and component organisation happen in seconds. Global variables sync across libraries without manual propagation. Design tokens match code before handoff, which makes developer handoff meaningfully cleaner. Accessibility issues and broken components surface through automated audits. Project context persists, so the agent is not working from scratch every session.

Where it breaks.
The setup is a barrier. A local bridge, a plugin, and real configuration work. Vague prompts have destructive potential. The agent can make edits that are accidental or hard to reverse. Large files consume significant API and token resources. Complex auto-layout and responsive logic still need manual refinement. The agent lacks intuition. It needs human oversight for deep UX and brand alignment.

None of these are reasons not to do this work. They are reasons to do it with eyes open, with a designer who knows their craft, and with realistic expectations about where the tool helps and where it does not.

The real gains

The shift is not about doing more. It is about where the time goes.

The taste got more of my time. I spend more of my day deciding what good looks like and less of it producing it. The craft got more of my time. I think more about principles, patterns, and accessibility, because I am no longer running out of energy building the screens.

The assembly got less of my time, and that is exactly what I wished for. The mechanical work is done by the agent. The review is done by me.

So, what’s next?

I am still tinkering. The prompts can get sharper. I am still figuring out what context matters most and what I can leave out. The library is never fully ready. Every new pattern needs to be made machine-readable before the agent can use it, and that is an ongoing piece of work.

Some things still need to be done manually. Complex responsive logic. Brand-critical screens. I do not use the agent for everything, and I do not think that is necessary. It still needs real designers.

The true value of AI is when it enhances human capability. Thinking and executing strategically. Taste stays human. Craft stays human. Assembly becomes agentic.

That is what this experiment showed me, and it is why I am going to keep going.

If you want to try this with your team, let’s talk. Reach out to me or anyone at Stampede on LinkedIn.

The post How I used AI to close the gap in UI design workflow appeared first on Stampede: the strategic design & technology company.

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.

Recruitment is the necessary evil mountains of Mordor that we as researchers must pass through in order to gain access to our users. But what if it doesn’t have to be like that?

Recruitment: Back-and-forth, error-prone hell

I love our users, but abhor the recruitment process with a passion. Accidentally misspelling a user’s name or giving them the wrong date and time is the kind of mortifying mistake that keeps me up at night.

Before the new process I’m about to share, we used to

• Manually contact all our users and maintain multiple back-and-forth conversations — explaining the research, how it works, proposing time slots and finding the Goldilocks slot that works for everyone
• When recruitment periods were tight, I’d find myself checking my phone outside work or on-the-go to coordinate users, all the time hoping I don’t make errors while doing this on mobile
• And even after a slot is confirmed, there’s having to remind yourself to make sure the user gets a Calendar invite, and then remembering to remind them so they remember to show up

The writing was on the wall:

A purely human-driven recruitment process was too manual, error-prone and delay-heavy.

If any of this resonates with your soul, welcome fellow recruitment-weary researcher. May you find rest here.

What success looks like

As designers we must not just articulate the problem, we must define what good looks like. For me, that was:

• Efficiently and correctly scheduled research slots
• Users are well-prepared with the details and what to expect (and show up!)
• A process with flexibility to accommodate edge cases and the variability that come with every new round of recruitment

I also wanted this solution to try and keep within the tools we already used at Stampede. This not only avoided unnecessary additional tool subscriptions, it minimised the learning curve for other Stampeders looking to replicate the process.

At a glance, here’s how it works:

This new process uses existing tools Stampede already uses:

• Notion: The database keeper
• Google Calendar: The scheduler
• Claude AI: The personal secretary

Now, let’s break it down:

1. Set the stage with Claude, Notion and Google Calendar

1.1 Connect Claude to Notion and Google Calendar

1.2 Notion database and message templates

• Set up your database of users in Notion.
• While you’re at it, include message templates in the same page that Claude can use to generate personalised messages for your users, such as:
  • Initial outreach messages
  • Messages with booking links
  • Pre-session reminders

1.3 Google Calendar Booking Link

Google Calendar’s Scheduling Appointment tool is great for pre-setting research slots and letting users pick the slot that works for them. This takes a huge amount of manual work out of the back-and-forth ‘Does this date work for you?’ dance.

1.4 Give your Claude Project recruitment instructions

If you’re not already using it, use Claude Projects to keep context about your project all in one place via ‘Files’. We’ll give it some recruitment instructions here so Claude will apply them to any chat you open up.

Here’s the sample prompts I used:

Notion page for recruitment:
<INSERT LINK HERE>

Contains recruitment list and message templates.

==========
Rules to follow when updating the user recruitment spreadsheet:

1. For any change you make, confirm it back to me in the chat on the exact change you made. 

For example, if my prompt was:
"Change John's slot to 2 Mar, 9am-10am", you make the change and then confirm it back showing the before and after in table form.
* 1st column header: "Field", data: Date
* 2nd column header: "Before", data: John's original slot date and time
* 3rd column header: "After", data: John's new slot date and time

2. If a change I made might have missing details, also clarify with me if I want to add the missing details.

For example, if my prompt was:
"Add in Mary Sue, new user"

Make the change, confirm back to me the change you made (as per Rule #1), then list the other details that are missing (like email address, Whatsapp number) and ask if I want to update that too.

3. When I prompt for it, do a Daily Verification Check between the Notion and Google Calendar.

* Flag any mismatches in a table, comparing what's in Google Calendar and what's in Notion. Don't make changes without my consent. 
* When verifying, the calendar event title does not have to be identical, what matters is the correct user, date and time, location (virtual/physical).

How to match the participant:
* In most cases, the email listed in the Notion for the user should be the same as the email of their Google Cal invite.
* If this is not the case, look for the closest match - e.g. the user's first or last name in the event title, initials in the email address.
* Where there is ambiguity, flag that unknown to me so I can specify which users match between the Notion and Google Cal. 

Situations you might flag:
* A user's Notion status is '5. Slot booked' but their date/time in Notion doesn't match that same user's slot in Google Calendar -> Flag the difference to me so I can reconcile
* A user's Notion status is '5. Slot booked' but has no Google Cal invite set -> Remind me they are missing a calendar invite
* A user's Notion status is '5. Slot booked' and they have a Google Cal invite, but the location or video conferencing has not been updated.
* A user's Notion status is '2. Pending reply' -> Prompt me to check in on this user for any new replies
* A user's Notion status is '3. Replied; to send booking link' but they don't have a corresponding Google Cal invite -> Remind me they haven't received the booking link yet
* A user's Notion status is '4. Booking link sent' but they don't have a corresponding Google Cal invite -> Remind me they haven't booked a slot yet
* A user who has a Google cal invite set but in Notion, their status was not updated to '5. Slot booked' and/or the date/time is not shown in Notion
* A user's status is '6. To reschedule', and there is a mismatch between the Google Cal date/time and the Notion date/time -> Prompt me to reconcile this
* A user's Google Cal session has already passed AND/OR the Notion shows their status as '7. Session Complete', but their Notion 'Incentive' status is empty or still at '1. To send incentive' -> Remind me they still need to receive their incentive

4. If I prompt you to make a change that would create a scheduling conflict (e.g. two participants at the same time), flag it to me before making the change.

5. If there is any ambiguity or edge cases not covered, clarify before making changes. 

For example, 
* If my prompt was "John's rescheduled to Mon, 2 Mar" but there are two Johns, you ask me which John I mean. 
* If my prompt was "Billy rescheduled to Monday" you confirm which Monday date it is and what time.
* If my prompt included a name that is slightly different from the Notion but still has high-confidence match, e.g. I mispell "Samuel" as "Sameul" but the Notion says "Samuel Lee" (and there is only one feasible match), make a best-guess match, apply the change, then let me know in your response the guess you made to ensure you got the right person.

Instructions for Claude for generating messages for users:

1. Follow the displayed formatting (bullet points, spaces, bolds/italics) you see in the message template provided in Notion, but your output for me should be in code block form, formatted according to the platform conventions I will send it on, so that it will display the formatting as intended.

For example, if I will send it as a Whatsapp and there is a bolded bit of text, use asterisks because when pasted into Whatsapp, it will display as bold. For example, the block of text for me to copy from you would look like this:

"Hi Jane,

My name is Stephanie. I'm a researcher with Stampede Design.

Would you be available for an interview on *24 Mar, 9am-10am*?"


2. If you do not know which platform I plan to send on, verify with me first.

3. If you are not sure what the user's first name is, check with me first. Usually, in Malaysia, first names follow this convention:
* Cindy Tan (First name: Cindy, Last name: Tan)
* Tan Chee Wern (First name: Chee Wern, Last Name: Tan)
* Muhammad Abdullah (First name: Abdullah, Last name: Muhammad)
* Jacob A/L Mathew (First name: Jacob, Last name: A/L Mathew)

2. It’s go time — let’s reach out to users

Unless you need to recruit more users than you can practically contact manually, I prefer maintaining the human touch here. The first outreach is critical for building rapport and getting valuable information about your users before you’ve even met them in person – how they speak, their concerns or hesitations, adaptations they need for a successful session. Besides, if users detect an AI is talking to them, the ick-factor can throw them off before you’ve even begun.

But here’s where you can take some of the manual work out – prompt Claude to generate all the initial outreach messages for your users off your template, customised to their names and details:

3. Once the user has agreed (yay!), send the booking link

This is where Google does the heavy-lifting – users select a booking slot, then receive the calendar invite and email confirmation. Google even sends pre-session reminders based on your settings.

4. From here on, keep track of recruitment with Claude

Users, I’m afraid, have an unfortunate habit of not collectively getting together and agreeing on all their slots at once. Chances are in the past you’ve had to constantly keep track of who’s responded, who hasn’t and everything in between.

And the more users you have, the higher the risk of error.

Enter Claude:

Remember those prompts we setup back in Step 1? Now they work for you.

Prompt Claude to do a Daily Verification Check at any time and it’ll compare your Google Calendar with your Notion database to look for all possible instances of error, like:

• Users we haven’t contacted yet
• Users who haven’t picked a booking slot yet
• Users who haven’t received their incentive yet

Gone will be the days of needing to keep a running list of all your users in your brain – let Claude handle that for you.

That’s it!

With any luck, if you follow these steps or adapt them to your work, you can focus more of your energy on actually talking to your users where the human touch still matters.

So what have we gained?

Time-consuming, error-prone work was the biggest pain point in our old process, and now what used to take me 1-2 hours of cumulative back-and-forth a day I can do in 15 minutes at the start of my day. That and just the sheer weight off my mental load of having to keep track of each user.

In other words, my brain will now leave me alone at night to rest peacefully.

What’s next?

We’re still tinkering. Some parts are still manual and error-prone, one of the biggest being the non-sync between Google Calendar and Notion, requiring Claude as the ‘workaround checker’. Who knows, the next step might be recruitment driven solely by Agents (stay tuned for Part 2?).

Move fast, do better, but stay human

At the end of the day, recruitment still involves communicating with real people — and that’s a process worth designing with intention and empathy. Automate the tracking, the scheduling, the error-checking. But keep yourself in the moments that shape your research: that first conversation where you hear hesitation in someone’s voice, the small talk that tells you more about a participant than any screener could. Being intentional about where the human stays in the loop is what ensures our research always keeps the people we’re designing for at the centre.

Thanks for reading! If you’d like to continue the conversation, let’s connect on LinkedIn.

The post How I turned hours of user recruitment chaos into a 15-minute morning routine appeared first on Stampede: the strategic design & technology company.

Back in 2008, I was a Malaysian designer working across cultures and continents, riding the Web 2.0 wave, trying to figure out technology and nurture this seed of a studio called Stampede.

Discovering Naz, a fellow Malaysian designer navigating Silicon Valley, made me feel seen. Someone who understood that craft is its own reward. That seeking meaning in our work isn’t unusual.

Someone from here, who looked like me and was obsessed over things that seemed small to others but mattered deeply to us.

I later learned this was the power of representation. Being in similar places now, it’s a responsibility I don’t take lightly.

What started as dinner…

Like the best of things, none of this was planned. Two weeks before his visit, Naz got in touch so we could meet in KL. What started as dinner plans turned into a homecoming, a return to Malaysia and also to a community of practitioners who share his curiosity about craft and meaning.

“Back in 2000, there were maybe a handful of web designers in the world,” Naz reflected, talking about the early days when people built the internet because they were curious, not because there was money in it. “And then more recently, at Config, I saw thousands of designers at Moscone Centre and thought, wow, look how far our profession has come.”

Our Makers Circle format is borrowed from those old Parisian salons where intellectuals gathered and talked to each other late into the evening. There, there was intentionality, a choice for quiet conversation and a space created for thinking together.

UOB’s beautiful hall was perfect for this kind of discourse. It was spacious for deep conversations and elegant to honour the discourse. Our thanks to them for hosting us again.

Starting with intention

But the evening started with something you’d never see at a tech conference: silence.

Naz guided seventy practitioners through a brief meditation, asking us to let go of whatever had been eating at us all day. The whole hall was quiet, lights dimmed, eyes closed. We let go of the day’s scattered energy and entered the Circle with open hearts and minds.

I loved the renewed evening energy.

Naz’s Perspectives: philosophy, meets practice

Now whenever Naz and I talk, it somehow always comes back to craft. He’s the kind of friend you can pick up conversations with months later, exactly where you left off.

In fact, I learned the word “shokunin” from Naz. It’s this Japanese idea of master craftspeople who spend their entire lives perfecting one thing. Not just skill, but people who dedicate themselves completely to their craft, finding deep purpose in perfecting the smallest details.

Watching Naz share his Silicon Valley experience made it feel like thoughts and ideas were clicking into place. He talked about experiencing multiple booms and busts, his work at True Ventures and designing for inclusion. He shared how his team’s redesign of Adobe.com failed with Japanese audiences because it lacked that consideration for cultural diversity and understanding the culture and environment in which the design lives and breathes.

In the midst of figuring out what it actually means to make things when machines are getting better at making them too, these are the stories that stick with you. There’s tendency to gravitate towards success stories but mind the survivorship bias. Most times, it’s real failures that teach you something.

AI and the future of craft

We also touched on AI replacing designers. Naz shared a beautiful story about Bruce Swedien, the legendary sound engineer who worked with Michael Jackson.

Bruce was never afraid to share his knowledge. He taught workshops, wrote books and discussed his experiences openly. He’d share how he and MJ would tinker with mixes for hours, making over 90 different versions of “Billie Jean” alone.

When people asked if he was concerned others would copy the techniques he so generously shared, Bruce’s response was profound: nobody could replicate his creative future, just his past techniques.

Post-Circle, that was the bit that got me thinking. I was curious, so I Googled bruce up. Which led me to something he said that really resonates with designers navigating automation today.

Back in 2006, when digital sales were overtaking CDs, inexpensive hardware and software meant musicians could craft professional-level recordings from their bedrooms. Bruce saw this shift but far from being defensive, he was jubilant.

“What I find most promising now is that musicians have easy access to recording technology that is far better than at any time in the past. The music recording is going to be put back in the hands of people who truly love music for music’s sake.”

Replace “recording technology” with “AI tools” and his vision becomes rather prescient.

The shift to meaning

“There’s this rejection happening,” Naz said of senior designers globally who are walking away from big corporate jobs to do work that actually matters. “After Jason Santa Maria left Shopify and Ethan Marcotte left 18F, everyone’s doing their own thing again. We all want to do things that matter and practice our craft.”

The value hierarchy is shifting.

These are experienced practitioners who’ve seen how corporate pressures can dilute good work. They’re not rejecting profit. They’re rejecting the specific trade-offs that come with a scale-at-all-costs culture.

It reminds me of how my friend Ben Bowes at GovTech Singapore puts it perfectly: “Earlier in my career, I spent a lot of time in what I call the ‘more industry.’ Helping companies get people to buy more, watch more, consume more. After a while, it wore me down. I wanted my work to mean more than an uptick in shareholder value.”

This wasn’t some abstract philosophy. It lives in the choices we make.

The Salon Experiment: flipping the script

Naz and I then experimented with something we don’t often see at a tech event: a proper salon. Borrowing from those 18th-century Parisian gatherings where intellectuals debated ideas long into the evening, we turned the audience from passive listeners into the real stars of the show.

Naz moved around the audience, no longer the visiting expert but genuinely curious about what we’re building here. The role reversal was beautiful. He asked the questions and people responded with shared insights about Malaysian design that Silicon Valley rarely gets to hear.

“How many of you know each other here?” Quite a few hands went up—many had attended our larger Makers gatherings. But among them I spotted a good few newcomers too, joining our tight-knit community for the first time.

“What’s the actual state of things here? The real practitioner version?”

What happened next felt like watching trust build in real time. People opened up.

They shared design journeys, accomplishments, frustrations and the emergence of distinctly Malaysian design language thanks to #sapotlokal campaigns post-COVID.

We talked about layoffs and uncertainty, navigating pivots to entrepreneurship, ideas worth building and who to build them with.

So what did we figure out about being Malaysian

One trait many Malaysians share is humble underdoggedness. Humility is a virtue here, but it also creates a massive blind spot. We couldn’t see far into what makes us great and so it was doubly beautiful watching the non-Malaysians in the room remind us of our strengths.

“As an outsider working with Malaysians, I value your cultural insight,” someone said. “Malaysians are fantastic multicultural bridges. What you do so naturally—navigating between cultures with fluency and warmth—is truly a superpower.”

“Malaysians can code-switch effortlessly,” someone else said. “Put us anywhere, and we figure our way out.”

Naz, coming from his Silicon Valley perspective, backed this up: “Living between worlds develops empathy across cultures. That naturally leads to more inclusive design.”

The consensus is we’re not trying to be Western designers who happen to be Malaysian. We’re Malaysian designers whose cultural fluency creates value that others can’t replicate. We don’t have to choose between local and global. Our between-worlds position makes us perfect for this role.

Vulnerability and courage

Did our experiment work? Many times over. The salon format gave people permission to be vulnerable alongside being knowledgeable. Senior practitioners admitted knowledge gaps. Founders talked about fear. Designers share the dilemma of using AI to deepen their craft while risking being made obsolete by it.

“I think I’m missing foundational design knowledge and I want to do something about it,” one designer admitted, with the rest of the room nodding along.

I found this moment particularly moving because it takes courage to admit gaps when everyone expects you to have it all figured out. This was the great collective figuring-out. I enjoyed every bit of it.

How we think about technology and taste

One exchange that stays with me is how we talked about technology and taste. It felt refreshingly grounded instead of panicked or blindly optimistic. There’s a real desire for thoughtful integration here.

The unfortunate reality is that commercialism rewards speed above all else. Designers get praised for assembling interfaces quickly, for churning out converting designs fast. But this creates a trap. When automation arrives, the assemblers are the first to go. Along the way, taste gets lost.

If we look around us, the pattern is glaringly obvious. Websites look the same. Platforms sound the same. Design has become homogenous. Faster, yes. Better? Not always.

We’ve become dependent on pre-built components, reinforcing our role as assemblers rather than creators. We’ve optimised for efficiency at the cost of the very thing that makes our work human—distinctiveness and meaning.

Backstage, Naz talked about inspiration. Not those from Dribbble or Mobbin, where we recycle the same patterns endlessly. But from architecture, from nature, from other mediums and cultural traditions. Originality lives in the spaces between disciplines, where we still get to lean on our curiosity and algorithms haven’t yet flattened everything into sameness.

The irony is that designers who create from first principles often deliver better results faster. Not because they work slowly but because they tap into what makes people feel cared for. When something resonates deeply with users, it succeeds more quickly in the market.

This reminds me of how Sir Jony Ive put it beautifully in his Stripe talk:

“I really do believe that we have this ability to sense care. It’s easy in a service because you confront care, because you confront the person. When it’s vicarious, when it’s via an object, when it’s via a piece of software, it’s more complex. But I think you can sense carelessness. You know carelessness. And so, I think it’s reasonable to believe that you also know care, and you sense care.”

This explains why homogenous design feels hollow. It lacks human intention. When everything looks the same, it’s often because it was optimised for production speed rather than crafted with the person in mind. The result is faster assembly but lower differentiation and substance.

Speed of assembly isn’t the same as speed of success.

The family dimension

Perhaps the most moving moment came when Naz’s 75-year-old mother joined us. Like many Asian parents, she’s never quite understood what her son does with “these Internet things.” Neither does mine!

In Asian families, elders are woven into the fabric of our achievements. But in technology, our accomplishments often exist in languages our elders don’t speak. Watching Naz’s mother see her son command respectful attention from a room full of professionals transformed the evening from a professional gathering into a cultural homecoming.

Between Worlds: where we go from here

Like those early web designers Naz remembers, we’re approaching technology with curiosity rather than fear. We’re building for global markets but celebrating local culture.

Innovation’s future won’t be determined solely in Silicon Valley. It’s being shaped by practitioners who understand that meaningful progress happens between worlds—where Eastern wisdom guides Western technology, where community discourse creates competitive advantage.

This is our distinctive contribution: not choosing between tradition and innovation, but finding harmony between both.

For me, hosting is always a treat in itself. You plan the structure and then let the gathering take its own flow.

By evening’s end, something had shifted. We ran over by 30 minutes, yet nobody looked at their phone except for photos. This felt different.

As I watched Naz’s mother beam with pride, I dare say we’d created something unprecedented: a gathering that honours both individual craft excellence and collective cultural wisdom.

My team and I at Stampede feel deeply grateful we get to create this space for discourse. One Makers at a time, we’re building community that chooses craft over convenience, meaning over metrics, depth over noise.

The future belongs to those who remember that design is both craft and responsibility. We’re just getting started.

—

Next up: The conversation about craft and taste in the age of AI continues at Makers 12 on 27th September. Registration opens soon.

Special thanks to Naz Hamid, UOB Malaysia, my wonderful team at Stampede and every practitioner who made this gathering possible. – Shaza

The post Design, identity and the Malaysian way of seeing with Naz Hamid at Makers Circle appeared first on Stampede: the strategic design & technology company.

A good proposal is like a book. It tells a story. It needs a clear beginning that sets the stage with the company background and introduction, followed by the problem statement and the client’s challenges. The climax comes with the investment that’s required, leading into the resolution where we outline our methodologies and case studies. Finally, it closes with a strong conclusion.

The hardest part, however, isn’t putting words on a page, but rather it’s deciding what story we are telling together.

Hi, I’m Adlin. I’m the Business and OPS Executive here at Stampede and this is my debut article. At Stampede, “Business and Ops” is really about making things work. I connect the dots between people, processes and projects. Some days that means handling timelines and documents, other days it’s about helping shape how we tell our story to clients. I’ve spent the past three years helping our team craft proposals for design and development projects.

What’s unique about our approach is that we don’t separate business development from delivery. When we respond to an RFP, the people writing the proposal are the same ones who will eventually build it. Designers, Developers and Ops come together to figure out what makes the most sense for the client. It’s a collaborative process that feels less like pitching and more like building, just on paper first.

What I’ve noticed is this: the stage that eats up the most time is not the writing itself, but the planning. Just like authors spend more time outlining, seeking inspirations, scheduling their time to write, we spend most of our effort aligning on ideas before we begin writing the proposal. And when you have several “authors” writing with different perspectives, it takes work to pull the story together. What separates a confusing and a clear proposal is how we communicate. Strong internal conversations between ops, design, and dev become the backbone of a strong solution proposal.

Internal alignment create external clarity

The first thing we do when a new RFP comes in is scan the scope of work. What’s needed? What’s the timeline? Who are the best resources we can send? We form assumptions here, but we don’t react yet. Instead, we gather every question we have, list them down, and send them to the client. It’s important to clarify these early because the cost of fixing a mistake later is far higher than the cost of validation.

Once the client replies, the real groundwork begins. My role in Ops is a bit like being the PM of a project. I’ve experimented with many PM tools for tracking proposal tasks, but for me, Notion is home base. It’s where we collect every piece of information so everyone has access to the same page.

This first step is crucial. If the team is misaligned internally, the proposal will read as vague, inconsistent, or overly technical. We don’t want that. A clear, aligned RFP tells the client we get you, we’re organised, and we can deliver.

The RFP is a reflection of a team dynamic

An RFP is often a client’s first impression of what it feels like to work with us. I don’t come from a design or dev background, so I look at our proposals differently, in the big-picture sense. Einstein once said,

If you can’t explain it to a six year old, you don’t understand it yourself.

Well, at Stampede, I am that six year old (Theoretically, of course. Don’t report me for child labour).

Because I don’t speak the same technical language, I make a good proof reader. If the flow makes sense to me, it’ll make sense to client’s procurement team. For me, that flow comes down to three simple questions:

1. What is the goal of this project?
2. Why us?
3. How can we help?

In fact, these are the first questions we ask each other during our kickoff call. Our internal conversations help surface the right differentiators, which case studies to showcase, what methodologies that are the right fit, the investment, and the timeline. When the story flows, clients don’t just see capability, they feel our confidence. A well-structured proposal signals discipline and care, which is why strong team dynamics matter.

Communication reduces last-minute stress

At Stampede, deadlines are everything. In projects, we set our own deadlines and take full accountability. But proposals work differently. The deadlines are strict, often dictated by the client’s internal portal. Sometimes even a minute past the cutoff means rejection.

That’s why we work backwards. If the submission is due on the 27th, we mark it as D-Day and then map out what needs to be completed on the 26th, 25th, and so on. From there, we assign specific tasks and resources. Designers handle design scope and methodologies, devs lead the dev scope, and ops take care of business documents while making sure everything matches the client’s requirements.

One trick we’ve adopted is setting an internal deadline before the actual one. That buffer gives us space to proofread and polish without panic. Early communication and clear delegation go a long way in avoiding last-minute stress.

When everything finally comes together, a good proposal becomes more than just a submission. It becomes a reflection of care. For the client, it brings clarity and a sense of confidence that they are in capable hands. For the procurement team, it makes their job easier by showing that we’ve understood not only the brief but the intent behind it.

Every proposal forces us to slow down and make sure we’re solving the right problem before we ever start building. It sharpens how we collaborate, how we communicate and how we grow as a team. So if you’ve ever received a proposal from Stampede, now you know where the quality and consideration came from. They came from a lot of conversations and probably a few very strong coffees.

A good proposal is like a book

As someone who loves a good storybook, I know the mixed feelings that come at the end of one. Relief, nostalgia, sometimes sadness and (mostly) joy especially when the questions you had at the beginning have been answered. You leave the book with more clarity than when you started.

Proposals work the same way. At the end of reading one, clients should walk away with confident answers, and the feeling that someone cared about their problem, not more questions. That’s the goal. And the best way to get there is through strong team communication.

Every proposal tells a story. This was ours and I’d love to hear yours!

Let’s connect on Linkedin?

The post Proposals and the conversations in the margins appeared first on Stampede: the strategic design & technology company.

That’s where engagement analysis really matters. Not just tracking behaviour—but understanding it.

You’ve probably seen it too. The traffic looks decent. Users are clicking around. Session durations seem healthy. The data piles up… but something still doesn’t feel right.

And if you look closely, maybe conversions are stuck. Maybe people are dropping off before they complete anything meaningful. Your data’s saying something—but it’s not the full story.

At Stampede, we see teams face this all the time. Businesses reacting to numbers without stepping back to look at the bigger picture. That’s why our approach goes beyond dashboards—we turn signals into steps that help the product move forward.

This isn’t a checklist. It’s a set of ideas to help teams read their engagement data more meaningfully—and act on it.

Common engagement pitfalls

Even the best digital products hit rough patches. Maybe people drop off just before converting. Maybe onboarding doesn’t quite land. Or maybe users bounce before doing anything meaningful.

Sometimes the issue is technical: slow load times, poor mobile responsiveness, clunky forms. Other times, it’s more subtle—confusing copy, unclear next steps, or a mismatch between what users expect and what they actually get.

Without a plan to re-engage users, we find that these friction points build up and is slowly impacting product growth.

That’s where engagement analysis helps: it helps us see where things aren’t working, so you’re not just guessing—you’re acting on something real.

What engagement analysis data can—and can’t—tell you

Metrics gives us signals. But they don’t tell the whole story.

Let’s look at a few:

Drop-off Rates

People are leaving mid-flow. That’s often a sign of friction—unclear next steps, or a process that feels too complicated. It’s also maybe a sign that user actually get what they wanted, qualitative study might reveal something here.

Time on page / Session duration

Are they staying because they’re engaged—or because they’re confused? Numbers can’t always tell. Heatmaps and user recording can reveal scrolling patterns, clicking behaviours or hovers on several key elements. These further observation might be able to help triangulate the root cause.

Return visitors / Retention

If users don’t come back, there’s likely a missing hook. Something didn’t stick. Return users means the product is useful or providing a value that’s worth returning for.

Click-through rates (CTRs)

Weak CTAs, confusing layouts, or messaging that doesn’t connect can all drag these down. From my experience, A/B testing can help you make a quick tweak and see subliminal user preferences.

Conversion rates

If the value isn’t clear—or the process feels like work—people will leave before committing. Improving value proposition, flow continuity and actionable CTAs may help you improve. Learning from qualitative data will help you the most here.

Synthesising data can be tricky, we have existing biases, pre-conceived notions and assumptions. For example, sometimes long sessions are a good sign. Other times, they’re a red flag.

We’ve encountered long session durations that’s actually good for the user, for example on a long content page where users might be reading, or during highly interactive screens. Long sessions might be bad for tasks that are supposed to be simple like onboarding, sign ups or submitting an application.

That’s why context matters. Pairing data with qualitative insights—like user interviews or usability tests—helps explain why something’s happening, not just what.

And here’s the key: not everything that looks broken actually is—and not everything that’s working needs to stay exactly the same.

Making quantitative data actionable

Once the patterns has been discovered, here’s how to move from insight to real change:

• Pair data with research. Do usability sessions, product trials—get a feel for what users are actually experiencing. Read more on our approach on product testing.
• Prioritise on what matters. You don’t need to fix everything. Focus on what aligns with your goals.
• Test and iterate. Small changes can go a long way. Improve, validate, tweak—then do it again.

Small UX changes, big impact

One small but powerful fix: we once saw users drop off after using a key feature—because the next step wasn’t obvious. Adding clearer CTAs on the results page reduced drop-offs and improved retention.

A few other low-effort, high-impact ideas:

✅ Clearer calls to action

✅ Shorter, simpler forms

✅ Personalised content or suggestions

✅ Progress indicators in long flows

Sometimes it really is the small stuff that ends up making a big impact.

How engagement analysis evolves with your product

This isn’t a one-time thing. Engagement analysis evolves as the product grows.

• Early-stage – Spot friction early, refine before scaling.
• Growth phase – Optimise based on real behaviour, not gut feeling.
• Mature products – Catch churn risks early and keep up with changing user needs.

From my experience, engagement analysis was often used to continuously refine user flows based on evolving user behaviours. For many teams, this approach has directly improved onboarding and significantly reduced drop-off rates, leading to higher adoption and retention.

Done right, engagement analysis becomes part of product growth. It feeds into larger gap analyses and connects to our broader research and product strategy. Our work analysing engagement for a team as a part of a gap analysis of a government platform, alongside user research, product testing and comparative benchmarking yielded highly actionable recommendations for platform improvements. Read the case study about our gap analysis approach.

Overall, it helps with:

• Investing time and effort where it matters most.
• Aligning teams across design, product, and marketing.
• Removing friction and boosting satisfaction.
• Building longer-term user relationships.

Engagement analysis, the Stampede way

At Stampede, we don’t stop at numbers. We connect the dots.

Instead of handing over spreadsheets, we tailor insights to different teams—from product managers to marketers to leadership. Everyone gets what’s most relevant to them.

We focus on storytelling—turning data into something meaningful. Something that drives decisions.

And because our teams work closely across design and development, we look at the full picture—user patterns, tech limitations, performance quirks—all of it. That cross-disciplinary lens helps us see things others might miss.

So if your platform’s seeing drop-offs, low conversions, or inconsistent engagement, maybe it’s time to dig deeper.

We’re here to think with you, to dig deep, ask better questions, and uncover insights that actually help your product grow. And when your product grows, it builds better experiences, better worlds. If that’s what you’re aiming for, drop us a line.

The post From quantitative data to action: How engagement analysis unlocks digital growth appeared first on Stampede: the strategic design & technology company.

The handoff paradigm is failing us

At Stampede Makers X last month, we discovered something unsurprising yet just as disheartening: 51% of teams still operate in what we call the “Handoff stage”—where design creates specifications, transfers them to development and hopes (mostly prays) what emerges weeks or months later, still resembles their vision.

Stampede Makers isn’t your typical event. We created it to address the industry’s elephants in the room—persistent problems everyone experiences but few discuss openly.

For our tenth edition (the “X”), we tackled the design-development divide. Like past Makers events, we put a challenging question out into the world to see if others were just as bothered by it. They were—and they came in droves.

For the first time, we brought together equal numbers of designers and developers, all searching for better collaborative approaches. What emerged was a genuine conversation about breaking down the handoff model that has kept these disciplines working apart while supposedly working together.

The handoff model persists not because it works well, but because it’s the path of least resistance. When we observe teams operating this way, three patterns consistently emerge:

• Products require extensive rework when technical constraints surface too late
• Market opportunities slip away as competitors with more integrated teams move faster
• Users receive experiences that feel “almost right” – visually polished interfaces that don’t quite work or functional systems wrapped in confusing interactions

There is clearly inefficiency, and we’ve become good at normalising it.

But what if the handoff model is not only poorly practised? What if it’s fundamentally misaligned with how digital products should be created?

Why do we keep running this ineffective relay?

Now, if the handoff model creates so many problems, why does it persist?

The easy answer is inertia. We continue using it because we always have. Looking deeper, I realised something more interesting could be at the centre of this: the handoff model aligns with how specialists prefer to work and how organisations prefer to structure themselves.

This made sense in an earlier era. When digital experiences were simpler and user expectations lower, the gap between design intent and technical implementation didn’t matter as much.

That world no longer exists. Users now expect seamless experiences across multiple touchpoints. Technology has grown exponentially more complex. Speed to market increasingly determines winners.

We’re using a 2005 workflow model in 2025. This misalignment becomes more costly every year.

A developer’s perspective shift that changes everything

During Makers X, Stampede’s full-stack developer Syazwan Zubir described his first usability testing experience. He watched real users struggle with a government website that, from his developer’s perspective, was logically structured. Some users simply gave up in frustration.

“It was a wake-up call,” he admitted.

This observation reveals something profound. When developers directly witness users struggling with their creation, something fundamental shifts. The gap between building and using becomes visceral. The handoff model suddenly feels not just inefficient but absurd.

What’s fascinating is this shift doesn’t require developers to become designers. It simply requires them to expand their perspective to include the people using what they build.

Far from diluting technical excellence, we’re contextualising our solutions within human needs. Syazwan calls this “user-centred engineering“, a concept put forth by Addy Osmani, Google Chrome’s senior engineer.

Addy said, “A user’s experience is the ultimate measure of engineering success. Great engineers care deeply about the user and their needs – this includes sweating the details and making sure their experience is a valuable one.“

It does not mean abdicating your development responsibilities. It means maintaining your technical rigour while embracing empathy for the users.

Moving beyond the relay race

Our panel of cross-disciplinary experts revealed several patterns that transform the traditional handoff model:

Embrace your productive friction

Rather than avoiding tension between disciplines, Ikhwan reframed friction as creative energy – like hands creating warmth through friction. “Every meaningful problem needs this kind of productive tension,” he explained. “It’s where innovation happens.”

This perspective shift changes everything. What if friction between design and development isn’t something to eliminate but to harness? Alexis shared how her team’s most innovative solutions emerged precisely from challenging cross-team discussions that initially felt uncomfortable.

The practical application is surprisingly counterintuitive. Instead of smoothing over differences, successful teams create structured spaces for productive disagreement. Ikhwan’s Tower Defense Retrospectives from Tasty Cupcakes does exactly this—it gives teams a framework to visualise both their strengths and challenges without the conversation becoming personal.

Atif added that when development teams are confident enough to push back on design decisions with technical context and design teams are open enough to explain the reasoning behind their choices, the result is almost always a better solution than either discipline would have created alone.

Learning is best done through direct experience

The most powerful catalyst for change wasn’t process frameworks or tools but direct exposure to each other’s worlds. Designers who understand technical constraints create more implementable solutions. Developers who understand the “why” behind design decisions implement them more thoughtfully.

Syazwan’s journey exemplified this perfectly. His approach to building applications changed after watching real users struggle with an interface. In his own words, “I realised that logical code doesn’t matter if users can’t figure out how to use it.”

What’s striking is how this cross-disciplinary understanding develops. It doesn’t come from documentation or presentations. It emerges from shared experiences and direct observation. Alexis described how IKEA’s most effective teams regularly include developers in user research sessions and designers in technical architecture discussions – not to turn everyone into generalists but to build shared context.

Create artefacts that serve both worlds

All panellists emphasised the importance of shared artefacts that bridge disciplines. These aren’t just deliverables to be handed off but tools for ongoing collaboration.

Alexis shared how her team tackled this at an enterprise scale. When designers would look at implementation and say, “This isn’t what I designed,” the root cause wasn’t usually developer indifference. It was that collaboration had started too late. Her solution was a shared artefact—dependency maps between backend and frontend teams—that made complex systems visible to everyone, regardless of their technical background.

What makes these artefacts effective? They’re co-created rather than handed off. They make complex systems visible to everyone. And they focus on neutral territory rather than individual ownership.

Ikhwan expanded on this last point, recommending moving critique sessions away from individuals to the artefacts themselves – discussing “this user flow has friction points” instead of “your design doesn’t work.”

Several artefacts you could consider that worked particularly well as bridges:

• Component libraries with both design tokens and code implementation
• Journey maps annotated with both user needs and technical constraints
• Service blueprints that visualize both frontend and backend interactions
• Design systems built collaboratively by both disciplines

Communicate across boundaries

The classic question—”But I already told them that!”—resonated across all panelists’ experiences. Ikhwan’s practical “five channels five times” method addresses this reality. Important messages need to be communicated multiple times through different channels to penetrate domain boundaries.

Alexis noted that at IKEA’s scale, they discovered that documentation works best when it’s co-created, not handed off. “The process of creating it together is often more valuable than the document itself,” she explained. The document becomes a record of shared understanding rather than instructions from one team to another.

Atif also shared a simple but effective practice from his experience: regular “design+dev pairing” sessions where designers and developers sit together to work through implementation challenges in real time. These sessions build communication muscles and shared vocabulary that makes all other interactions more effective.

The Partnership Evolution

These insights helped us map a progression that teams typically follow:

Handoff: Sequential work with periodic transfers of ownership. This is where most teams begin and many remain.

Coordination: Working side-by-side with regular check-ins. Issues surface earlier, but disciplines maintain separate processes.

Integration: Shared ownership and combined practices. Team members develop cross-functional literacy and focus on collective impact.

Partnership: A unified culture with resilient practices that scale. Design and development flow together toward shared objectives.

What’s fascinating is how each stage delivers tangible improvements – faster delivery, better quality, less rework. But the most significant gains emerge at the partnership stage, where teams operate with an entirely different rhythm.

What if the endpoint isn’t better handoffs but their elimination?

Small changes, outsized impact

If your team operates in the handoff model, transformation won’t happen overnight. Evolution occurs in stages, each requiring different skills and mindsets.

Here are a few approaches to consider that would consistently produce results:

Put developers in front of users. Not through reports or recordings – have them directly observe usability testing. There’s no substitute for witnessing real people struggle with something you built.

Build an understanding of adjacent disciplines. Designers don’t need to become developers, and developers don’t need to become designers. But they do need enough fluency for meaningful conversations. Basic literacy in both domains transforms collaboration.

Create artefacts together. Journey maps, service blueprints, component libraries – these become powerful when both disciplines contribute to and use them regularly. They’re not just deliverables; they’re collaboration tools.

Share meaningful metrics. When design and development align around shared success metrics, they naturally coordinate their efforts. The metrics themselves become a common language.

None of this requires reorganizing your company or hiring rare multidisciplinary unicorns. It simply requires recognizing that these perspectives are complementary, not sequential.

Learning from our own experience

At Stampede, we’ve been fortunate to learn from 19 years of cross-disciplinary collaboration. Our founding team included both design and development perspectives – not from foresight about these challenges, but from necessity. This accidental advantage gave us insight into what works when these disciplines work closely together.

What’s striking is how consistently the same patterns emerge across organizations. The relay race creates identical friction points whether you’re a startup or an enterprise. And the solutions are surprisingly universal.

When we collaborate with clients, we don’t arrive with predetermined solutions. We start by understanding how their teams currently work. Sometimes we integrate design-aware developers into their team. Other times we add developers to design teams to validate ideas earlier. We’re not replacing workflows – we’re connecting disciplines within them.

Over time, clients experiencing this approach ask how to build this capability internally. This led us to develop workshops sharing practical techniques. We don’t have all the answers, but we’ve learned what tends to work, and we’re happy to share with teams ready for something different.

Evolving deliberately, not dramatically

If your team still operates in the handoff model, start with small steps:

• Invite a developer to your next user research session
• Schedule regular collaborative working sessions
• Create one shared metric that both teams contribute to

The changes don’t need to be dramatic to be effective. They need to be deliberate.

In the past, we could get away with handoffs. Today, they’re becoming a competitive disadvantage. The organisations that thrive going forward will be those that see design and development not as separate functions but as complementary perspectives on the same challenge: building things people actually want to use.

What if we stopped thinking about improving handoffs and started questioning whether we need them at all?

The community that makes it possible

What I found to be the most striking aspect of Makers X was the community itself.

UOB provided their thoughtfully designed space—creating an environment where candid conversations flourished naturally. The coffee that flowed throughout the day (courtesy of our dedicated barista) catalysed cross-disciplinary discussions that rarely happen in typical work contexts.

Behind the scenes, our organizing team—a mix of designers and developers—delivered the entire event without experiencing the handoff problems we discussed. There’s something particularly satisfying about embodying the principles you’re exploring.

A huge shoutout to our amazing volunteers—Faiq Uzair, Amir Ali, Sandra Yeoh, and Ahmad Alfhajri! Coming from diverse backgrounds as developers, designers and product managers, their dedication and collaboration were key in making this event successful. They truly embodied the spirit of cross-disciplinary teamwork!

Perhaps the most revealing observation is that over a hundred people dedicated a Saturday to examining how we might work differently. This suggests something important about our community—a shared recognition that our current approaches have limitations and a collective curiosity about alternatives.

Thoughtful questions, honest stories and willingness to reconsider established practices aren’t just personally valuable—they’re gradually shifting how our industry approaches these challenges.

See you at the next Makers 11, where we’ll continue exploring uncomfortable questions, sharing experiences, and yes, enjoying good coffee together!

Need better design-development collaboration? We help in two ways: through integrated project teams that deliver results while modeling better practices, or through practical training that builds this capability within your organisation. Both draw from real experience. Drop us a line to explore what makes sense for your team.

The post Rethinking the design and development relay race at Makers X appeared first on Stampede: the strategic design & technology company.

Now think about your favourite digital services: the ones that just feel effortless to use. Every interaction flows naturally, and it all feels part of the same trusted experience. That’s not by accident. It’s the result of a well-structured design library, working behind the scenes to create consistency, scalability and trust.

As both a designer and a user, I’ve had my fair share of frustrations with clunky interfaces and mismatched branding in UI. And because of that, whenever I kick off a new project, I’m determined to avoid those pitfalls by building a solid foundation: the design library.

So in this article, I hope to share why building a robust design library is the key to tackling these pain points and creating seamless user experiences at scale. It’s also why I’m driven to write this: I’ve seen firsthand how a well-crafted design library can transform not just a single app, but an entire organisation’s digital ecosystem, something I’ll share further as we go along.

Design library vs design system

I will focus specifically on design libraries in this article rather than the broader concept of design systems. In simplest terms, a design library is a curated set of style guides and reusable interface elements like typography, color palettes, and buttons, that help teams maintain a consistent look and feel. A design system, on the other hand, goes a step further by having code-ready components, more extensive documentation, and processes that unify the way teams update and govern the design system.

While design systems offer a more comprehensive framework involving deeper collaboration with developers and product teams, most organisations might not need to start there. Instead, a solid design library lays the groundwork, setting the stage for a more scalable design system as the product and organisation evolve. Think of it as an early-stage design system, delivering immediate benefits in consistency and efficiency without overcomplicating things.

What makes a design library great

In the years designing products across startups and enterprises, I’ve learned one crucial lesson: the bigger or more complex the organisation, the more important this foundation becomes. Let me explain why.

First, design library is your brand’s digital DNA

When most people think about design libraries, they picture a collection of UI components from popular design systems like shadcn/ui, Bootstrap, or the default iOS and Android UI kits. Just grab a UI kit, change some colours, and call it a day. While this might work for simple products, we’ve learned the hard way that it comes with significant costs, especially for complex products and enterprise projects.

When a design library doesn’t carry the brand’s DNA, it leads to a generic-looking product, making it hard for customers to distinguish your brand from competitors. Look at Netflix, Duolingo, or Instagram, you can recognize them instantly, even without seeing their logos. That’s because the most successful businesses invest in design libraries that truly reflect their identity, extending beyond colors and fonts to shape the entire user experience.

I saw this firsthand while we designed a mobile app for manufacturing plant performance monitoring. Rather than defaulting to a generic enterprise style, we worked closely with stakeholders to channel their brand DNA of efficiency and innovation into the design. We introduced a sleek dark mode interface that highlight key metrics without overwhelming the user, while giving the product a modern, cutting-edge feel. These choices not only supported advanced data visualization but also aligned seamlessly with the company’s future-focused vision.

Similarly, our work on the HMI Group hospital website was centered around building trust, an essential factor in healthcare decisions. The brand DNA was translated into the digital experience by focusing on clarity, warmth, and professionalism. We used clean, structured layout to make medical information easily accessible, a reassuring color palette that conveys safety and expertise, and real imagery of doctors and patients to create a sense of reliability and human connection. These design choices helped establish a confident user experience, ensuring patients felt informed and supported at every touchpoint.

Handles the real-world complexity when basic UI kits fall short

One real story stands out. A Global Fortune 500 energy company approached us to revive a project that had failed three times and cost millions. When we looked deeper, we realised the core underlying issue. The previous teams had built solutions without validating their assumptions with actual users. Without a structured design library to support rapid prototyping and testing, each iteration became expensive and time-consuming, making real user validation impractical.

The impact then was clear: users struggled with complex workflows and data visualizations that didn’t match their mental models or daily needs. What could have been caught early through proper user testing had instead led to costly rebuilds.

We knew we had to take a different approach. So we started by asking questions like:

• How can we use a design library to accelerate our user validation process and reduce the cost of iterations?
• What patterns do users actually need for interpreting complex operational data effectively?
• How do we ensure our design system supports continuous user feedback and evolution?

From there, we built a design library that made complex industrial data analysis and reporting more accessible and intuitive. We implemented:

• Legible typography with a clear hierarchy, ensuring key figures stood out for instant recognition.
• Strategic spacing and balanced UI density prevented data overload by grouping related metrics, making dashboards structured yet easy to scan.
• Color coding provided quick visual insights such as greens for positive trends and reds for warning, to help users identify key data points at a glance.
• Visual cues like progress status and last-update indicators enhanced clarity, ensuring users could quickly interpret real-time data without unnecessary friction.

What truly excited us over the years was seeing the design library evolve into a scalable enterprise solution that served diverse user needs, from engineers tracking real-time equipment data to executives analyzing company performance metrics. Despite their distinct needs and technical expertise levels, users experienced a consistent, efficient interface throughout.

Designed for real people and real needs, instead of generic user personas

Sometimes, the most valuable lessons come from specialised projects. Take VivaValet, a digital product we designed to make technology more accessible for elders. Generic design libraries would have failed here because they don’t account for age-related accessibility needs like declining vision, reduced dexterity, and cognitive differences. So we needed to go deeper. Through extensive UI research, we studied how elderly users learn, interact, and think about digital interfaces. This led to crucial design decisions, like:

• Increased text size from 16px to 24px for better readability and less eye strain.
• Carefully selected typography optimized for legibility.
• Enhanced touch targets to prevent accidental taps, accommodating users with reduced motor skills.
• High-contrast color schemes tested with vision disability tools, improving visibility.
• Simplified navigation patterns aligned with elderly users’ mental models.

As surprising as it may seem, culture plays a big role in design libraries. What works well in one region may not translate effectively in another. Working across Southeast Asia has taught me that digital behaviors, expectations, and even visual preferences differ dramatically. A one-size-fits-all design library risks alienating users, making cultural awareness a key factor in creating effective, scalable designs.

Through research and testing, I’ve found that cultural considerations impact several design aspects, including:

• Visual hierarchy and UI density – Apps in Asia often have denser layouts compared to Western counterparts. This reflects cultural differences in written language structure. Asian characters convey more meaning per symbol, leading to a preference for compact, information-rich interfaces. Western apps, by contrast, use more whitespace and minimalistic layouts.
• Color meanings and symbolism – Colors don’t mean the same thing everywhere. In the West, red often signals errors or warnings, but for Chinese, it represents luck and prosperity. Similarly, white conveys purity in Western cultures but is associated with mourning in some Asian traditions. Understanding these cultural associations prevents unintentional miscommunication.
• Bilingual interfaces that feel native, not translated – Direct translation isn’t enough. Sentence structures, reading flow, and emphasis vary across languages. For example, Malay and Thai sentence structures differ significantly from English, requiring thoughtful UI adjustments to ensure readability and natural phrasing.
• Local payment behaviors – Even digital payments aren’t universal; different regions have preferred methods. In Southeast Asia, QR code payments and bank transfers are common, while Western users are more accustomed to credit cards and PayPal. A well-structured design library must support these regional differences without overcomplicating the experience.

By embedding cultural awareness into design libraries, we ensure that digital products resonate with real users, fostering trust and engagement. Rather than applying generic user personas, we tailor experiences based on how people naturally interact with technology in different markets, ensuring usability, familiarity, and long-term adoption.

Not self-limiting but continuously evolve to scale

Early in my journey, I could get away with rigid design libraries for smaller products. But enterprise projects taught me a valuable lesson: if your design library can’t evolve, your digital platform can’t either.

A truly effective design library must anticipate growth, supporting new features, products, and even entire business lines as you scale. Ultimately, a robust design library is key to removing friction when your product suite expands, ensuring consistent user experiences across new markets, functionalities, and digital platforms.

How do you know if your design library is too rigid?

A rigid design library often creates more problems than it solves. Some telltale signs include:

• Hardcoded components that break or require extensive customisation when a new feature or product is introduced.
• Overly prescriptive guidelines that don’t allow flexibility for different teams, leading to workarounds and inconsistencies.
• Minimal documentation or poor onboarding, causing teams to misuse or abandon the library altogether.

What does a flexible design library look like?

Now, I build design libraries that are:

• Component-based and scalable, ensuring that UI elements can be easily repurposed for new services.
• Structured for modularity, so teams can mix and match UI patterns rather than being locked into rigid templates.
• Supported by clear documentation and onboarding, ensuring that internal teams and external vendors can adopt it seamlessly

We treat our design libraries as living documents, continuously engaging with stakeholders and testing with real users to identify pain points and opportunities for improvement. This feedback loop ensures our design libraries remain relevant and effective, allowing organisation to grow without sacrificing brand consistency or user experience.

The joy factor, making digital products people love

Even in business contexts, emotional connection matters. When we worked with TNG ewallet on their in app parking, a locally infused microcopy was essential to making this an immediately resonant touch point for Malaysians. Users loved it so much they shared screenshots of our playful writing on social media.

As a Malaysian born and bred UX design and development agency, we know Malaysians well. We believe that adding delightful, culturally relevant details is key to creating memorable experiences. By infusing the local culture into interface elements, microcopy, and overall design, we make digital products feel personal and engaging, even for something as everyday as parking or payment applications. This human touch can transform mundane interactions into moments of genuine delight.

Real business metrics improvements

Remember that Fortune 500 enterprise project we redesigned? The results speak for themselves:

• 90% Monthly Active Users (MAU)
• 30% improvement in Manufacturing Plant Cycle Efficiency
• 50% reduction in plant interruptions
• Expansion across 14 applications

While the design library wasn’t the sole driver of these metrics, it played a crucial role in enabling rapid prototyping, structured validation, and efficient design production, helping teams iterate faster and implement changes at scale.

What surprised me the most was seeing other projects within the same enterprise begin adopting the design library, amplifying its impact far beyond the original scope. With a shared system in place, teams could build upon existing components, reducing duplication and streamlining workflows. This is the testament to what I mentioned in the introduction: a well-structured design library doesn’t just improve a single app; it has the potential to scale across an entire digital ecosystem of the organisation.

Over time, we’ve consistently seen how a well-structured design library accelerates operational excellence:

• Product and development teams release features faster
• Different departments easily maintain a unified brand
• Updates and maintenance become more efficient
• New team members quickly get up to speed
• External vendors deliver high-quality work with fewer inconsistencies

Ultimately, these metrics highlight that a well-structured design library isn’t just about looks; it’s a strategic asset that boosts operational efficiency, ensures user satisfaction, and strengthens brand credibility across the entire organisation.

Hard-won lessons: what actually works

After building design libraries for everything from small startups to major enterprises, here’s what I’ve learned:

Lesson #1: Start with understanding

Instead of jumping straight to UI components, start by understanding your users, operations, and vision. The strongest design libraries are built on deep insights, ensuring they address real needs rather than just assembling UI elements.

Lesson #2: Build for your reality

Focus on creating components that solve your specific challenges. Align your library with your team’s workflow and product requirements so it grows with your needs instead of forcing unnecessary constraints.

Lesson #3: Think long-term

Approach your design library as a strategic investment rather than a quick fix. The most successful libraries support where organisations are going, not just where they are today.

Lesson #4: Test with real scenarios

The true test of a design library is how well it handles your most complex use cases. Every library improves dramatically through thorough testing with users in real scenarios.

In fact, we’ve found that with the right foundational elements in place, you can go from hypothesis to user-tested prototype in a 5-day design sprint. Because the UI components already adhere to consistent branding and standards, teams can focus on testing new ideas, rather than building everything from scratch.

Final thoughts: Building a foundation for lasting impact

A well-designed design library is more than just a collection of UI components. It’s a foundation for digital success. By investing in a robust, flexible library, you can accelerate product development, create user-friendly experiences, and ensure your brand stands out in an increasingly crowded market.

At Stampede, we’ve helped organisations build design libraries that truly transform their digital capabilities. If you’re considering this for your organisation, let’s discuss how we can create something that doesn’t just look good, but delivers real impact. Reach out to studio@stampede-design.com

The post Design Libraries: The Key to Success (or Failure) 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.