Research with the actual users
Not a focus group of managers. Sitting with the people who work the queue, watching where they hesitate, and finding out which of their workarounds are protecting them from a real problem.
Services
UI/UX Design
An internal tool nobody enjoys using is a design problem before it is a taste problem. We work on the flows, the dense screens and the states, alongside the people who use it.
The complaint is rarely about how the software looks, though it often does look dated. The task people perform most often is buried the deepest, search returns the wrong rows, and people keep a spreadsheet open beside the application because it is quicker. Software people sit in front of all day gets judged on how little it gets in the way. That is a harder standard than a handsome homepage, and it is the one we design to.
What the work covers
Where the actual design decisions get made
Design work on an internal system is mostly evidence gathering and decision-making. The drawing is the last part, and it goes faster when the questions underneath it have been settled.
Information architecture and flows
Where things live, what they are called, and how many steps stand between a person and the thing they came to do. Most of the felt improvement comes from here.
The interface itself
Layout, density, typography and the behaviour of every control. Expert users want the table to hold more rows and the keyboard to do everything the mouse can. Consistency beats novelty for someone on the same screen every day.
Accessibility written into the brief
Deciding this at the end is what makes it expensive. Contrast, focus order, labels and keyboard paths belong in the brief alongside everything else; retrofitting them after an audit produces a compliant interface that is still unpleasant to use.
A design that cannot be built is unfinished
The handover problem is familiar enough. A deck of beautiful screens arrives, the engineers start building, and within a fortnight much of it has been quietly renegotiated at the keyboard: this spacing does not exist in the component library, that animation costs a frame budget nobody has, this table falls apart at the row counts the real query returns. The design was a picture of a screen, not a specification.
So the designers sit with the engineers who will implement the work, in the same repositories, and the output is components rather than images. Each one carries its states: empty, loading, partial, error, and the case where a field holds far more text than anyone expected. The people who design a system here are the people who build and operate it, which removes the argument about who owns the gap.
What you receive
The things that outlive the engagement
A project leaves behind more than a set of screens. These are the artefacts that keep their value after the engagement closes.
Design and handover tooling
Tooling matters less than the convention it enforces, and if your team already works in something, we work in that. The list below is what we reach for when the choice is open.
- Figma
- FigJam
- Framer
- Storybook
- Style Dictionary
- Chromatic
- React
- TypeScript
- Tailwind CSS
- Radix UI
- axe DevTools
- NVDA
- Playwright
What buyers ask first
Usually not, if people depend on it daily. A single big reveal retrains everyone at the same moment, breaks every piece of internal documentation, and gives you no way to tell which change caused the drop in throughput. We would rather move one workflow at a time, in releasable slices, and keep the old path alive until the new one has been earned.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.