What Makes Our Approach Different From Typical Agencies
Every agency says they are different. It is practically a requirement of the industry. You will find it on homepages, in pitch decks, and in the first five minutes of every introductory call. "We are not like other agencies." And then, more often than not, the experience that follows is almost indistinguishable from every other agency the client has worked with before. Same presentation-heavy process. Same disconnect between the work produced and the reality of what the team can actually build and ship. Same moment about two thirds of the way through the project where the client realises the deliverable is not quite what they needed and it is too late to substantially change direction.
So when we say our approach is different, we understand completely why that claim deserves scepticism. Words are easy. What is harder, and what actually matters, is being able to describe specifically and honestly what is different, why it is different, and what that difference actually produces for the teams we work with. That is what this is. Not a claim. An explanation.
The Agency Model Is Broken and Most People Know It
The traditional agency model was designed for a different era of product work. It made sense when design was primarily a communication discipline, when the job was to produce assets that looked good and communicated a brand message clearly. That model, where a client hands over a brief, an agency disappears for several weeks, and then returns with a polished presentation of work, maps reasonably well onto a campaign or a brand identity project. It maps extremely badly onto product design.
Product design is iterative, contextual, and deeply entangled with engineering, product strategy, and user behaviour in ways that make the traditional handoff model genuinely unfit for purpose. A design produced in isolation from the engineering team is a design that has not yet been tested against the reality of what can actually be built. A design produced without ongoing contact with real users is a design built on assumptions that may or may not hold up. A design produced in response to a brief without interrogating whether the brief describes the actual problem is a design solving the wrong thing beautifully.
What the Traditional Agency Relationship Actually Looks Like
In the traditional model, the client is essentially a customer and the agency is a supplier. The client specifies what they want, the agency produces it, and success is measured by whether the deliverable matches the specification. That sounds reasonable until you remember that in product work, the specification is almost never the whole story. The client often does not fully know what they need until they see what they asked for and discover it is not quite right. The agency, having been paid to deliver the specification, has little incentive to push back on it before they start. The result is a process that produces technically correct work that misses the actual need, followed by a revision cycle that nobody planned for and nobody budgeted well.
Why Beautiful Work Does Not Always Mean Useful Work
There is a particular trap that visually talented agencies fall into regularly. The work looks extraordinary. The presentations are impressive. The screens are polished to a level that makes everyone in the room nod appreciatively. And then the work goes into development and something starts to unravel. The designs did not account for the states that real users produce in real usage. The flows look clean in a prototype but create confusion when a user arrives without the context that the designer had in their head while building them. The visual decisions that look stunning in isolation create problems when they have to live alongside the rest of the product's existing interface. Beautiful work and useful work are not the same thing, and confusing them is one of the most expensive mistakes in the product industry.
We Start With the Problem Not the Brief
The single biggest structural difference in how we work is that we treat the brief as a starting point for investigation rather than a specification for execution. When a brief arrives, our first move is not to start designing. It is to start questioning. Not in a challenging or adversarial way. In the way that a good doctor questions a patient's description of their symptoms before reaching for a diagnosis. The brief is the symptom. The actual problem is usually several layers deeper, and finding it is worth far more than responding quickly to the surface version.
This is not a comfortable position for everyone. Some clients arrive wanting to see designs quickly and interpret the questioning phase as delay or over-complication. But the teams we work with most successfully are the ones who have learned, often through previous experiences of rushing past this stage, that clarity at the start of a project is the fastest route to quality at the end of it.
Why the Brief Is Never the Whole Story
A brief is a document produced by people who are close to a problem and therefore have a particular perspective on it. That perspective is valuable but it is never complete. The person writing the brief knows the product deeply but may have lost sight of what it is like to encounter it for the first time. They know the business goals clearly but may have filtered them through assumptions about what design can and cannot achieve. They know what they want to change but may not have fully investigated whether changing it will actually produce the outcome they are hoping for. These are not failures of the brief writer. They are natural consequences of being close to a problem. Our job is to bring distance and fresh perspective to a situation that the internal team is too embedded in to see clearly.
The Questions That Change Everything Before Design Begins
The questions we ask before design begins are not the standard discovery template questions. They are the questions that surface what is actually at stake. Who will be most affected if we get this wrong and what will that cost them? What have you already tried and what did that attempt reveal about the problem? Where does the current experience break down in the user's own words rather than in the team's interpretation of their words? What would need to be true about the user's behaviour for this design to be considered genuinely successful? These questions take time to answer well. And the answers almost always change the shape of the design work that follows in ways that make it significantly more likely to hit the actual target.
Our Product Design Process Is Built Around Your Reality
Most agencies have a process and they apply it to clients. We have a process and we adapt it to each client's specific reality. The distinction sounds small and is actually enormous. A process applied uniformly treats every project as if it has the same constraints, the same team dynamics, the same stakeholder structure, and the same technical context. No two projects do. Our product design process is built around understanding what is actually true about your team, your product, and your users before deciding how the design work should be structured and sequenced.
This means that two engagements with us can look quite different from each other at the surface level while being driven by exactly the same underlying principles. A startup building an MVP needs a process that is fast, flexible, and comfortable with ambiguity. An enterprise team scaling a product needs a process that is structured, stakeholder-aware, and careful about consistency with existing patterns. Applying the same process to both would serve neither well.
Designing Within Constraints Rather Than Around Them
Constraints are not obstacles to good design. They are the conditions that make good design possible. A design that ignores technical constraints produces work that cannot be built without significant compromise. A design that ignores team capacity constraints produces work that cannot be maintained without burning people out. A design that ignores budget constraints produces work that cannot be realised without painful scope reduction at the worst possible moment. We treat every constraint the team shares with us as useful information rather than a limitation to push against, because working within real constraints is the only way to produce work that actually ships and actually works in the world.
How We Keep the Work Grounded in What Actually Ships
The gap between design and reality is one of the persistent problems of the product industry. Designs that look perfect in a tool get implemented in ways that lose something important in translation. We close that gap by keeping engineering in the conversation from the very beginning rather than bringing them in at the handoff stage. We share works in progress with the engineering team while they can still be shaped by their input. We ask about implementation complexity before committing to visual approaches that would create it. We document design decisions and the reasoning behind them in a way that gives engineers genuine understanding rather than just a set of specifications to execute. The result is design work that survives contact with reality far better than work produced in isolation.
Collaboration That Goes Beyond Presentations and Handoffs
The presentation-and-handoff model of agency work is fundamentally a one-way relationship. The agency produces, the client receives, feedback is collected, revisions are made, and eventually something gets signed off. We do not work that way. Collaboration for us means something more specific and more demanding: being in the thinking together rather than just sharing the outputs of thinking separately.
This looks like working sessions where both the client's team and our team are building something together in real time rather than presenting finished work for approval. It looks like feedback conversations that happen early and often rather than formal reviews at predetermined milestones. It looks like design rationale that is explained and discussed as it develops rather than presented as a finished argument after the fact. It looks like the kind of relationship where a client team member can message us mid-sprint with a question and get a substantive response rather than a note that it will be addressed in the next scheduled review.
What Real Creative Partnership Looks Like in Practice
Real creative partnership means shared ownership over the quality of the work rather than a clean division between the party responsible for producing it and the party responsible for approving it. When we work with a team, the designers on that team become part of the creative process rather than an audience for it. Their knowledge of the product, the users, and the context is built into the work from the beginning, not consulted at the review stage. Their instincts about what will and will not work with their specific user base sharpen and redirect our design thinking in real time. The best work we have produced has always been the result of that kind of genuine collaboration, where it is genuinely hard at the end to say whose idea any particular element was, because it emerged from a real creative conversation rather than from one party's isolated thinking.
Why We Measure Success by Outcomes Not Deliverables
Deliverables are the wrong measure of success in product design. A deliverable is a thing that was produced. What actually matters is what that thing does for the user and for the business once it is live in the world. We care about whether the design we produced reduced drop-off at a critical point in the flow. We care about whether the product we helped shape is getting the engagement metrics the team was hoping for. We care about whether the visual system we built is actually being used consistently by the engineering team six months after we handed it over. These outcomes are harder to measure than a deliverable count, but they are the only honest measure of whether the work was worth doing.
The Long Game: Building Something That Grows With You
Short-term thinking produces short-term results. An agency that designs for the current brief without thinking about where the product needs to go produces work that solves today's problem and creates tomorrow's technical and design debt. We think about the product trajectory, not just the current state, because the design decisions we make now will either support or constrain the decisions that need to be made in a year's time.
Thinking Beyond the Project Into the Product Future
When we design a component, we think about how it will behave when the product has twice as many features and three times as many user types as it does today. When we establish a visual language, we think about whether it can scale across new surfaces and new contexts without requiring a complete redesign. When we make a structural decision about navigation or information architecture, we think about whether it can accommodate the product growth that the team is planning without becoming a bottleneck. This kind of thinking adds time in the short term and saves enormous amounts of it in the medium and long term, and we have seen the difference it makes in products that have grown from small to substantial while remaining coherent and usable throughout.
What Teams Take Away Long After the Engagement Ends
The most durable output of a good partnership is not the design files. It is the shift in how the team thinks about and approaches design problems. Internal designers who have worked alongside us come away with sharper instincts about problem framing and user-centred thinking. Product managers who have been through a well-structured discovery and design process with us become better at briefing design work for the next project, whether that involves us or not. Engineering teams who have been included in design conversations from the beginning rather than brought in at the handoff stage develop a different relationship with design that produces better outcomes across everything they build afterward. We consider that lasting shift to be the real measure of whether a partnership was genuinely valuable.
Conclusion
The difference between a typical agency and a genuine design partner is not about the quality of the visual work, though that matters too. It is about where the relationship starts, how deeply it goes, and what it produces beyond a set of deliverables at the end of a project. It starts with honest investigation rather than immediate execution. It goes deep enough to include the engineering team, the product strategy, the real constraints, and the actual user behaviour rather than sitting at the comfortable surface of a brief. And it produces not just better designed products but better equipped teams who carry the benefit of the partnership forward long after the engagement has ended. That is the difference. Not a claim. A way of working.
FAQs
1. How do you handle clients who have had bad experiences with agencies before and are understandably cautious?
We take previous bad experiences seriously as useful information rather than something to reassure our way past. Understanding specifically what went wrong in previous partnerships tells us where we need to be most deliberate about demonstrating a different approach. We do not ask anyone to trust us on the basis of a claim. We try to earn it through specific behaviours in the early stages of the engagement that demonstrate the difference rather than just describing it.
2. Does your approach cost more than a standard agency model?
The honest answer is that it depends on what you are comparing. Our day rates are competitive with other experienced design studios. But more importantly, the total cost of a well-structured engagement with genuine problem framing and strong internal collaboration is almost always lower than the total cost of a traditional agency engagement that produces deliverables requiring substantial revision because the problem was not properly understood at the outset. We have never met a client who saved money by rushing past the thinking phase.
3. What types of products and teams do you work best with?
We work best with teams who have a real problem they are genuinely trying to solve and are willing to engage seriously with the investigation that understanding that problem requires. We work well with startups who need to move fast without losing quality and with enterprise teams who need design capability that can operate at scale without sacrificing the thoughtfulness that makes design valuable. The common thread is teams who want a genuine thinking partner rather than a production service.
4. How do you handle situations where the client wants to go in a direction you think is wrong?
We say so, clearly and with our reasoning laid out. Telling a client what they want to hear when we think it will lead to a poor outcome for their users or their product is not something we are willing to do, because it is not actually helpful. At the same time, we are clear that the final decision belongs to the client and we respect it once we have made our case. What we will not do is silently produce work we think is wrong and let the outcome speak for itself.
5. How long does a typical engagement last and what does the end of one look like?
Engagements vary significantly in length depending on the scope and nature of the work. Some are focused and short, a defined phase of discovery and design direction for a specific problem. Others are ongoing partnerships where we are embedded in the team's work continuously over many months. The end of an engagement looks like a deliberate transition rather than a sudden stop: documentation of decisions and rationale, knowledge transfer sessions with the internal team, and a clear handover of everything the team needs to carry the work forward confidently without us.