UX and UI design
A design handed over as a set of pictures always contains decisions that cannot survive being built. Not because the designer was careless, but because a picture only has to show one state, and software has to handle all of them: empty, loading, too long, error, offline, and the one where the user’s name is forty characters.
We design alongside the engineering rather than in front of it. The output is a working system rather than a picture of one.
How we work
Tokens
Colour, type and spacing decided before the first screen.
Real states
Empty, loading, error and too much data, designed on purpose.
Keyboard first
Keyboard and screen reader paths designed, not tested at the end.
Handoff
A repository, not a document nobody opens twice.
Tokens before screens
We settle colour, type scale, spacing and states as named tokens early, and every screen is then assembled from them. It sounds bureaucratic and it is the opposite: it is what makes a design consistent without anyone policing it, and what makes a change to the palette a one line change rather than a week of finding every place a colour was typed in by hand.
Contrast is checked when the tokens are chosen, not after sign off. On this site every colour token carries its measured ratio in a comment beside it, including the ones that had to be raised from the original handoff and by how much. A token chosen for a reason should say what the reason was.
Real states, not the happy path
For every component we specify what it looks like empty, loading, and wrong, plus focus and disabled. Most of the friction users feel in software lives in exactly those states, and they are the ones that get invented hurriedly by a developer at the end of a sprint if a designer did not decide them.
Keyboard and screen reader are part of the design
Focus order, focus visibility and what a control announces are design decisions, not implementation details. If a modal traps focus badly or a custom select cannot be operated from a keyboard, that is a design that did not consider it rather than a bug introduced in build.
We design for right to left as a first class direction too. Hebrew is not a mirrored version of the English layout: it affects where icons sit, how mixed Latin and Hebrew text behaves in a line, and which parts of an interface should not flip at all.
Handoff is a repository, not a document
Where we build, the handoff is the code. Where another team builds, we hand over tokens, components and the state specifications rather than flat exports, and we stay available while it is built, because the questions that matter always arrive during implementation.
What we do not do
We do not do brand identity from scratch: naming, logo systems, brand strategy. We work with the brand you have, or alongside the studio that made it. If you need a brand created, you need a brand studio, and we will happily work to what they produce.
We also do not produce design as a deliverable disconnected from building. If you want screens to take to a developer you have not chosen yet, we are probably the wrong supplier: the value we add is in the decisions that only surface when someone has to build the thing.
Research, proportionate
We do the research the decision actually needs. For a checkout used by thousands of people a day, that is usability testing with real users and it pays for itself. For an internal tool used by nine people, it is talking to the nine people, which takes an afternoon and is more accurate than any proxy.
What we avoid is research theatre: a month of workshops producing artefacts that inform nothing, on a project whose real constraints were known on day one.
Related
Design and build together is usually web development or a custom platform. Where the interface is the front of a store, see e-commerce engineering.
Common questions
Can you work from our existing brand guidelines?
Yes, that is the normal case. We will flag where the guidelines cannot survive contact with an interface, most often colour contrast on small text and states the brand never had to define, and propose the smallest change that fixes it rather than a rework.
Do you use Figma?
Yes, and we treat it as a working tool rather than the deliverable. The deliverable is the built system.
Can you redesign without rebuilding everything?
Usually yes. A token level change to colour, type and spacing can move a product a long way visually without touching its structure, and it is dramatically cheaper than a rebuild. We will tell you when structure is genuinely the problem.
How do you handle accessibility in design?
Contrast is checked when tokens are chosen. Focus states are specified per component. Keyboard paths and announcements are part of the spec. Doing it here costs almost nothing; finding it at launch means redesigning.
What if we already have a developer?
Fine, and common. We hand over tokens, components and state specifications rather than flat files, and we stay reachable during the build. We would rather answer questions while the thing is being made than review it afterwards and list what went wrong.
More services
Next
Tell us what you are building, or what is breaking.