UI/UX and product design for software that people use all day
Designing a tool somebody operates for seven hours a day is a different discipline from designing a landing page. Density, keyboard flow and error recovery matter more than a striking first impression.
What design delivers here.
Design that ends at a pretty picture creates work rather than saves it. These are the outputs a development team can build from.
Interface design and prototypes
Clickable prototypes covering the real paths, including the ugly ones — empty states, validation errors, partial data, the record with forty line items. Those are the screens that decide whether software is pleasant to use, and the ones most often skipped.
Information architecture
How the data is structured, named and navigated. Get this wrong and no amount of visual polish rescues it; get it right and much of the interface becomes obvious. This is where most of the value in a redesign actually sits.
Design systems
Components, spacing, type and states documented once so that every future screen is consistent without a designer being consulted each time. Essential the moment more than one person builds the interface, which is nearly always.
Designed by people who also build it.
We are an engineering firm that designs, not a studio that hands over a folder of images. That shapes the work: nothing gets specified that cannot be built at reasonable cost, and the handover is a specification a developer can implement without a series of clarifying calls.
How a project runs
- Observation of the current process with the people who actually perform it — what they work around tells you more than what they request
- Information architecture and flows before any visual work, because that is the expensive thing to change later
- Interactive prototype covering the main paths plus the awkward states, tested with real users rather than with stakeholders
- Design system and component documentation, so consistency survives after we leave
- Build-ready specification: spacing, states, behaviour, breakpoints — not a picture with the details left as an exercise
Designing for density
Business software is judged on the thousandth use, not the first. That inverts a lot of consumer design advice: generous whitespace becomes scrolling, a friendly wizard becomes six clicks where one would do, and an interface that hides complexity behind progressive disclosure becomes an obstacle to somebody who knows exactly what they want. We design for the operator who has been using it for two years, while keeping the first day survivable.
Accessibility, in practice
Sufficient contrast, keyboard operation, sensible focus order and labels that screen readers can use. In the UK this is a legal obligation for public-sector bodies under the 2018 accessibility regulations, and since June 2025 the European Accessibility Act extends similar duties to many commercial services across the EU. Beyond the legal duty, the practical argument is simpler: it is far cheaper designed in than retro-fitted after a procurement process asks about it.
Things clients ask before starting.
Can you design something another team will build?
Do we need a redesign or just fixes?
How do you test designs?
Can you work with our existing brand?
Usually leads into these.
Tell us where users get stuck.
Send us the screens people complain about, or the process you are about to build. We will tell you where the design effort is worth spending.