Most products fail at the join between what was decided and what got built. We work on both sides of it.
Flows, states and edge cases first — the parts that decide whether a product is usable long before anyone argues about a colour. Then the interface, drawn against real content and real constraints.
Everything is handed over as something a developer can build from, because the same people build it.
No, and that is the constraint the whole studio is arranged around. Every screen is drawn by someone who will be in the repository afterwards, so a flow that cannot survive a slow network or an empty state gets caught while it is still a rectangle rather than a sprint.
The problem, whoever is closest to it, and access to whatever already exists — a spreadsheet, a competitor you like, an old build. We do not need a brief written in our language. The first week is usually us writing the brief back to you and you telling us which half is wrong.
First, not last. Loading, empty, error, one item, four hundred items and the longest name your database will ever hold are drawn before the happy path is polished, because those are the states that decide whether a product feels solid and they are the ones that get skipped when time runs out.
We do audits and usability tests, and we are honest that a five-person test is a smoke alarm rather than a study. For a product that has users already, their behaviour is better evidence than anything we could stage, so we start by reading what is already there.
There isn't one, in the usual sense. The same people build it, so the design system arrives as code with the design file next to it. If you do take it in-house, you get both, and the file is the one we were actually working from rather than a tidied copy.
Yes, and we would rather extend one than replace it. A system nobody uses is a very expensive PDF; the useful question is which three components are doing all the work and whether they are right.