UI & UX Design

No, and we would rather not. A brand and an interface are different jobs: a brand is built to be recognised across a poster, a business card and an app icon, and an interface is built to be operated for eight hours. We take your brand and work out what it means in a product context: which of your colours can carry text and which cannot, what the type scale becomes at 13px, how the logo behaves in a 48px header. Where something genuinely does not survive that translation we will tell you and propose the smallest possible change rather than a rebrand.

Less than agencies sell and more than teams want. Five people doing the real task in front of you will surface most of what is wrong with a flow, and that is a day of work rather than a phase. What justifies more is a domain nobody on the team has lived in, clinical, regulated, industrial, where the risk is not that the design is unclear but that it is confidently wrong about how the job is done. We scope research against that risk rather than by default, and we would rather do one honest day than four weeks of interviews that produce a deck.

Both, and the second is the one that matters. A file full of screens is a description of one moment. What a team builds from is the system underneath it: named type and spacing steps, colour roles rather than a palette, components with every state drawn, and the rules for when to use which. We also write down the reasoning, because the next decision your team makes without us is only consistent if they know why the last one went the way it did.

Yes, and it produces a better result than designing at them. Our designers work in your review process, look at components as they are built rather than as they were drawn, and are available for the question that starts with what should happen if. The alternative, design finishes, throws the file over a wall, and moves on, is how a good design becomes an average product, one reasonable developer decision at a time.

More carefully than a new one, because you are changing something they have learned. The failure mode of a redesign is not that it looks worse, it is that it costs your most experienced users their muscle memory and they tell you so loudly. So we find out what people actually rely on before touching it, change the things that are genuinely broken, leave the things that are merely dated, and where a change is large we ship it to a slice of accounts first. Sometimes the honest recommendation is a smaller redesign than the one that was requested.

Access to somebody who does the job, and real data. Those two, in that order, are worth more than any brief. Beyond that: whatever you have on how people currently use it, the questions support answers most often, and the list of things everybody already knows are wrong. We do not need a finished specification: if you have one, it is useful, and part of our job is to find out which parts of it survive contact with a user.

It gets you most of the way, and the remaining distance is engineering rather than design. What design decides is contrast, focus order, whether controls are identified by more than colour, whether flows can be completed by keyboard, and whether anything depends on hover. What engineering decides is the semantics: real headings, real labels, correct roles, and what a screen reader announces when something changes on the page. We do our half properly and tell you plainly what the other half involves, rather than implying a design pass makes a product compliant.

The drawing is rarely what sets the date. A design phase waits on the same things a build does: access to users, decisions from people who are busy, and content that somebody has to write. A contained flow is a matter of weeks. A system for a product with many screen types takes longer and pays for itself the moment your team builds the twentieth screen without asking us anything. We give you a date against a written scope and tell you which parts of it depend on you rather than on us.