Expertise
Design that arrives before the architecture hardens
By the time a mockup reaches engineering, the data model is settled, the routes exist and the API has opinions. Whatever the design wanted to change about any of that is now a rewrite. We put design engineers on the delivery team from the first conversations instead, and they stay through it.
Information architecture
The decisions that are cheap now and structural later. What an object is called, what contains what, and which screen owns a piece of state will still be shaping the product long after the visual design has been replaced twice.
- Object and relationship modelling done alongside the data model, not downstream of it
- Navigation that matches how the work is actually organised in the business
- URL and route structure treated as part of the design
- Naming agreed once, then used identically in the interface, the API and the documentation
Operator interfaces
Screens somebody uses for six hours a day, which have almost nothing in common with screens somebody visits twice. Density, keyboard paths and error recovery matter more than anything on the marketing site.
- Dense tables that stay readable, with the columns the job needs rather than the ones available
- Keyboard-first paths for the tasks done hundreds of times a week
- Bulk actions with a real undo, because the alternative is a support ticket
- States for empty, loading, partial and failed designed alongside the happy path
Design systems
A product with its own consumers and its own release cycle. Treated as a folder of components, a design system is abandoned within two years and the estate ends up with three of them.
- Tokens and primitives versioned and published, with a changelog teams can read
- Figma libraries kept in step with the code, since the ones that drift stop being opened
- Accessibility built into the primitives, so consuming teams inherit it
- Adoption measured, because a system nobody uses is a cost rather than an asset
Design in an assisted codebase
Assistants write a great deal of the interface now, and they drift toward whatever they have seen most. Consistency has become an engineering problem with a design input rather than a review habit.
- A design.md that states the vocabulary, the layout rules and the things never to do
- Lint rules behind the conventions, because an unenforced convention is a suggestion
- Component APIs shaped so the wrong composition is awkward to write
- Review that catches drift while it is one file
What we build
- Design engineers on the delivery team, not a studio upstream of it
- In from the first conversations, while the information architecture can still move
- The same people through delivery, so the screens are built by the people who drew them
- Design systems, component libraries and operator interfaces, taken on their own
How this is delivered
Forward-deployed teams
Product, design and engineering people who sit inside your business, find the real problem, and ship it.
FAQ
Questions we get asked
Do you do design without engineering?
Yes. Design systems, component libraries, and the design. md that keeps an AI-assisted team consistent are all work we take on their own, and they are often how a longer engagement starts.
What we do best is a product where design, product and engineering sit in one team, so that is what we will suggest when it fits the problem. It is not a condition of working with us. That model is /services/forward-deployed.
Is design in house?
Yes, and on the same team as the engineers rather than in a studio that hands work over. That is the whole argument: a design engineer who is in the room when the data model is being decided can change it, and one who arrives afterwards cannot.
What does a design engineer actually produce here?
The surfaces people use, and the system underneath them so the next screen does not start from nothing. The reusable components every client design system here starts from were built the same way, and you can see where that led in the Fabric case study at /case-studies/fabric-pro.
When is it too late to bring design in?
It is never too late to make a product better, but it gets expensive at a predictable point: once the data model, the routes and the permissions are settled, a design change becomes a rewrite and stops being worth it. If you already have those, we would rather work inside them honestly than draw something that implies you rebuild.
How can we help?
A conversation with the people who would do the work, rather than with the people who would sell it.