When brand meets product: building identity into the UI
Most design teams treat brand and product as separate disciplines. That's a mistake. Here's how to unify them without losing either.
Every project we take on starts with a question we ask ourselves before we ask the client anything: what's the real problem here? Not the stated problem, not the brief, not the RFP. The real problem — the one that's generating all the symptoms the client is describing.
It sounds simple. It rarely is. Clients have been living inside their problem for so long that the shape of it has become invisible to them. They can describe the symptoms with precision — 'our bounce rate is high', 'users don't understand our differentiator', 'we look like every other company in our sector' — but the root cause is usually one layer deeper.
The best design work we've ever done has started not with a brief or a moodboard, but with a long conversation in which we systematically disassembled every assumption the client brought to the table. Not to be contrarian. To build correctly.
There's a saying in surgery: never operate on the wrong body part, no matter how well you do it. Design has an equivalent: never solve the wrong problem, no matter how beautifully you solve it. A staggeringly well-crafted identity for a product no one needs is still a waste of everyone's resources.
The work we're most proud of — the projects where the client called us six months after launch to say the thing had exceeded every target — those projects all had one thing in common: we spent the first two to three weeks of engagement doing nothing but listening, questioning, and mapping. We built the picture before we picked up the pencil.
What does this look like in practice? It starts with deep dives — structured conversations with the leadership team, individual contributors, and where possible, customers. We're looking for the gap between what people say and what they do, between the company's stated identity and its revealed identity, between the problem as described and the problem as experienced.
This phase is uncomfortable for some clients. It should be. We're not there to validate — we're there to understand. The best output of a discovery phase is sometimes not a cleaner brief but a completely different brief. A strategic pivot before a single pixel is moved.
If you're reading this and preparing a new project brief, here's our recommendation: before you write what you need, write what's happening. Describe the situation as it exists today — the business context, the competitive landscape, what your customers are saying, what's working and what isn't. The brief can come out of that. Good studios will help you write it.