UI and UX Design for Business Software UK

Design for software people use all day

Most design advice is written for marketing websites, where the goal is to impress a visitor for two minutes. Business software is different. Your accounts team might process two hundred invoices a day in it. A warehouse picker uses it on a handheld scanner with gloves on. A customer logs into your portal once a month and needs to find their statement without help.

Good design here is mostly about speed, clarity and avoiding mistakes: keyboard shortcuts for heavy users, sensible defaults, tables that sort and filter, forms that save progress, clear confirmation before anything irreversible, and error messages that say how to fix the problem. It looks calm and consistent because that is what makes it fast to use.

Research first

We start by watching people work. That might mean sitting with your sales team as they build a quote, shadowing a site visit, or screen-sharing with customers as they try to use your current portal. We look at analytics and support tickets for where people get stuck. Then we map the tasks: what triggers them, what information is needed, who approves what, and where things go wrong.

This is usually where the biggest wins appear. A step that exists only because two systems do not talk to each other can often be removed altogether with an integration, which no amount of visual polish would fix.

We also pay attention to where and how the software is used. A screen used at a desk with two monitors needs a different layout from one used on a tablet in a van, on a shop floor with poor signal, or by someone switching between the system and a phone call. Lighting, gloves, noise, interruptions and patchy connectivity all shape good design decisions, and none of them show up in a written brief.

Wireframes, prototypes and testing

1. Wireframes: low-detail layouts for each main screen, including the states people forget, such as empty lists, errors, loading and permission denied.
2. Prototypes: clickable Figma prototypes of the key journeys, realistic enough for users to try.
3. Usability testing: a handful of real users attempt real tasks while we watch. We note where they hesitate, misread or give up, and fix it.
4. Visual design: once the structure works, we apply your brand through a design system of colours, typography, spacing and components.

Changing a prototype costs far less than changing built software, so this is where we want to find the problems.

Accessibility built in

We design to WCAG 2.2 level AA, the current version of the W3C Web Content Accessibility Guidelines. In practice that means sufficient colour contrast, full keyboard operation with a visible focus indicator, proper labels on every form field, targets large enough to tap, error messages that are announced to screen readers, and no information carried by colour alone. Public sector bodies in the UK have specific legal duties under the Public Sector Bodies Accessibility Regulations 2018, and every UK service provider has duties under the Equality Act 2010. Accessible design is also simply easier for everyone to use.

Design systems and handover to build

For anything beyond a few screens, we create a small design system: a library of components such as buttons, form fields, tables, filters, modals and notifications, each with defined states and behaviour. Designers use it in Figma and developers implement it once in code, in React, Vue or Laravel Blade components, so every new screen is consistent and quicker to build.

Because our designers and developers work together, designs are checked for feasibility as they are made. We can hand over specifications to your own developers, or build the front end ourselves as part of a web application or customer portal project.

Redesigning an existing system

A redesign does not have to mean a rebuild. Often we can redesign the most-used screens first and roll them out within the existing application, measuring the effect on task time and errors before moving on. Where the underlying system is also old, we combine the redesign with a staged modernisation. Every design project is a fixed-price quote after a free chat.

What we deliver

• User research: interviews, task observation and analytics review
• Journey maps and task flows for the key processes
• Wireframes for every main screen and state, including errors and empty states
• Clickable Figma prototypes tested with real users
• A design system: colours, type, spacing and reusable components
• An accessibility review against WCAG 2.2 AA
• Developer-ready specifications, or front-end build in React, Vue or Blade

How it works and what it costs

Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.

1. Free chat

   Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.

2. Scoping

   We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.

3. Fixed-price quote

   You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.

4. Build and test

   We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.

5. Hand over and look after

   You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.

Related