Interfaces designed for the person using them all day

Designing software people are obliged to use

There is an important difference between designing a consumer application somebody downloads voluntarily and designing the system a warehouse supervisor must use for eight hours whether they like it or not. Consumer design competes for attention. Business design competes with the paper notebook the supervisor will quietly return to if your screens waste their time.

That shapes everything we do. The most frequent task receives the fewest interactions, even if that makes a rarely used administrative screen slightly less elegant. Fields that can be filled automatically are filled automatically. The keyboard works so hands never need to leave it during repetitive entry. Lists remember what you were looking at. Errors appear next to the field that caused them, as you type, rather than at the top of the page after a long form is rejected.

None of that is decorative and none of it shows up in a screenshot. It shows up in whether the data in your system is accurate a year later, because software that is slow to use gets filled in from memory at the end of the day, and data entered from memory is fiction.

Structure before decoration

We begin with what a screen is for and who is looking at it, not with colours. That means deciding what must be visible immediately, what can be one interaction away, what belongs on a separate screen entirely and what should not exist at all. Removing things is usually the highest value activity in interface design and the hardest to persuade people to accept.

Once structure is agreed, we design a system rather than a set of pictures. A type scale that stays readable from a small phone to a large monitor. Spacing that repeats consistently. Colours with defined roles. Components such as buttons, tables, forms, alerts and empty states that behave identically everywhere. The benefit is that the product can grow for years without drifting into visual chaos, because new screens are assembled from parts that already exist.

Light and dark, done properly

Many products claim a dark appearance and deliver an inverted one, where text becomes hard to read and brand colours vibrate against a black background. A proper dark scheme is a second complete design decision, with its own contrast relationships and its own adjustments to shadow, elevation and colour intensity.

We build both schemes as sets of design tokens, so every colour has a defined role rather than being written into individual components. The interface respects the device preference by default and offers a manual switch that is remembered, and both schemes are checked for contrast rather than assumed to pass.

Accessibility as a baseline

Around one person in five has an impairment that affects how they use software, and many more are temporarily affected by bright sunlight, a broken arm or simple tiredness. Designing for that range improves the interface for everybody, and in many organisations it is also a legal expectation rather than a courtesy.

Our standard includes sufficient contrast, text that scales without breaking the layout, a logical heading structure, labels properly connected to their fields, visible focus indicators for keyboard use, targets large enough for imprecise taps, meaning never carried by colour alone and respect for the reduced motion preference. These are not extras, they are what a finished interface looks like.

Designers who build what they draw

A common source of waste in software projects is a design produced in isolation and then handed to developers who discover that parts of it are impractical, expensive or impossible with the real data. Because the same team designs and builds here, that gap does not exist. If a layout would require an unreasonable number of database queries, we know while it is still a sketch, and we find an approach that looks right and performs well.