Skip to content
Madsoft
← All capabilities
06Product & Interface Design

Designed for the person who did not choose it

usable

The screen is where a system meets someone who is measured on throughput, did not pick the software, and cannot stop to read a manual.

01How we work

Organised around the task, not the schema

Software shaped like its database makes every user learn its internals. Software shaped like the job puts the next decision in front of the person who has to make it, with the three things they need to make it and nothing else on screen. The difference shows up as throughput, and as whether anybody uses the thing a year later.

Built for the worst conditions, not the demo

A gate in direct sunlight, a counter with a queue, a phone on a metered connection, a browser nobody is allowed to upgrade. These are the real conditions and they are design constraints, not caveats: large targets, high contrast, forms that survive a dropped connection, pages that work before the JavaScript arrives.

A design system somebody else can use

What we hand over is not a set of screenshots but components, tokens and rules another team can build with after we have gone, with accessibility checked in the pipeline rather than audited at the end. A design that only its author can extend is a liability dressed as a deliverable.

02What this covers
  • Operator consoles organised around the task, not the schema
  • Design systems that survive being handed to another team
  • Interfaces for small screens, metered bandwidth and bright sunlight
  • Accessibility checked in the build pipeline, not audited at the end
03What you are handed
  1. 01Flows mapped from observed work, with the exceptions named
  2. 02A component library and design tokens, documented
  3. 03Accessibility checks running in the build pipeline
  4. 04Interfaces tested on the hardware and connection they will run on
04Recognisable by
  • Staff keep a parallel paper or spreadsheet process beside the system

  • Training takes days because the screens follow the database

  • The tool works in the office and fails at the counter or the gate

06Questions we are asked

Do you do design without the build?

Yes, and it works best when the people who will implement it are in the room for the decisions. We will say where a design will be expensive to build, because a specification that ignores that is a bill someone else pays.

Will it match our brand?

If you have one, we work inside it and extend it where operator screens need things a brand guide never covered. If you do not, the system gets a coherent one that is yours.

How do you test with real users?

On site, during real work, on their own devices — not in a conference room. The exceptions people have invented to get through the day are the most valuable thing you will learn, and they only appear in the real setting.

Is accessibility included?

Yes, as a build check rather than an end-of-project audit. Keyboard paths, contrast and screen-reader structure are tested in the pipeline, so a regression fails a build instead of reaching a user.

Further reading

Start here

Bring us the problem nobody has solved.

A 30-minute technical briefing. We will tell you what we would build, roughly what it costs, and honestly whether we are the right people for it.