Service
UI and UX Design
Interface design for software people use all day: fewer screens, denser information, and a design system your engineers can build from directly.
The problem
What usually goes wrong
Business software is usually designed for the demo rather than for the fourth hour of a shift. Generous white space and large cards look calm in a screenshot and force scrolling when someone has ninety records to work through.
The opposite failure is a screen that shows everything and prioritises nothing, where the field that matters is the same size as the one nobody reads.
Design for operational software is an information problem before it is a visual one.
Scope
What we deliver
Task analysis
What each role does in a day, how often, and where the current tool costs them clicks or certainty.
Information architecture
How records, lists and actions are organised, named and reached. Most usability complaints are navigation complaints.
Interaction design
Flows for the paths that matter, including the error and empty states that get skipped and then get built badly.
Design system
Tokens, type scale, spacing rhythm and components, delivered as documented values engineers implement directly.
Accessibility specification
Focus order, keyboard paths, target sizes, contrast pairs and screen reader semantics, specified per component.
Prototype
A clickable version of the critical paths that your team can use before the build is committed.
Method
Technical approach
We watch the work first. The most valuable output of a design engagement is usually the discovery that two of the seven screens carry ninety percent of the time, and that one of them is missing a field people keep in their head.
Density is set by the task. An operational list gets tight rows, tabular numbers and keyboard navigation. A customer facing flow gets room, one decision per screen and plain labels.
Colour carries meaning sparingly. One accent marks the primary action and genuine alerts. Status is communicated by text and position as well as hue, so it survives a colour vision difference and a bright cab.
The design system is written as tokens rather than pictures, so implementation does not drift. Type scale, spacing rhythm, border treatment and component states are values an engineer can read.
Accessibility is specified alongside each component. Contrast pairs are chosen and recorded, target sizes clear 48 pixels, focus is always visible, and motion respects the reduced motion preference.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Task analysis covering each role in scope
- 02Information architecture and navigation model
- 03Interaction flows including error, empty and loading states
- 04Design token set covering colour, type, spacing and borders
- 05Component library with documented states
- 06Accessibility specification per component
- 07Clickable prototype of the critical paths
- 08Design source files handed over at delivery
Related
Systems this service builds
- Customer and Client PortalsA logged in area where your customers see their own status, documents, invoices and history, which removes the phone calls that only exist because they cannot.
- Custom CRMCustom CRM software for account relationships, sales pipelines, activity history, permissions, reporting and integrations with your operational systems.
- BI Dashboards and ReportingAgreed metric definitions, modelled tables and a small number of views tied to decisions, so a meeting argues about the action rather than the number.
FAQ
Questions people actually ask
Can you design without building?
Yes. A design engagement can end at the prototype and the design system, and your own engineers can build from it. The tokens and component specifications are written for that.
Do you work from our existing brand?
Yes. Where a brand exists we build the system inside it and tell you where a rule needs an exception for accessibility, such as a contrast pair that fails on small text.
What tooling do you hand over?
The design source files and the token set. Tokens are the part that matters, because they are what keeps the implementation and the design from drifting apart.
How do you validate the design before we build?
With a clickable prototype run against the real tasks by the people who will use it. Problems found there cost minutes; the same problems found after the build cost weeks.
Do you design for dark mode?
Where it is useful. Dark mode through tokens is straightforward if it is decided at the token stage and awkward if it is added later, so we ask early.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.