Product UX/UI design for software and apps

Why B2B software UX design is different

Most design advice online is written for consumer apps, where the goal is a first-time visitor who signs up. Business software turns several of those rules upside down:

• Expert, daily users: a planner or an accounts clerk uses the same screens all day. Speed for the experienced user matters more than a gentle first visit.
• Density over minimalism: tables with many columns, filters, saved views and bulk actions are features, not clutter.
• Keyboard first for repetitive data entry: tab order, shortcuts and sensible defaults.
• Roles and permissions: the same screen shows different data and actions to a sales rep, a manager and a warehouse lead.
• Data that comes from elsewhere: product codes, customer references and statuses from the ERP, often with history you cannot simply rename.
• The buyer is not the user: the person who signs off the project rarely uses the tool, so research has to reach the people who do.

What a product design project includes

The steps are the same whether we design something new or rework a tool already in use. What changes is how much research is needed at the start:

Usability testing with real users

Usability testing does not need large numbers. Jakob Nielsen's classic analysis for Nielsen Norman Group found that testing with five users uncovers about 85% of usability problems, and that three rounds of five, fixing problems between rounds, teach you more than one study with fifteen. Where the software serves clearly different groups, such as office staff and drivers, each group needs its own participants: three or four from each when there are two groups.

Each session gives a participant realistic tasks, such as 'raise a credit note for two damaged lines on this order', and asks them to think aloud while we watch where they hesitate, misread or give up. The GOV.UK Service Manual suggests sessions of 30 to 60 minutes. Office software can be tested remotely over screen share; for tools used in a warehouse or a van, we test where the work happens.

Accessibility and a consistent design system

We use the W3C's WCAG 2.2 at level AA as the reference for contrast, keyboard use, form labels and error messages. Two of its newer criteria matter a lot in business tools: targets large enough to tap reliably (2.5.8) and focus that is never hidden behind sticky headers or panels (2.4.11). Accessible design also helps everyone else: the warehouse worker in gloves, the manager on a small laptop, the colleague with tired eyes at the end of a shift.

A design system (shared components with their states and rules) is what stops every screen looking like it came from a different app. It also makes future features faster and cheaper to design and build, because most new screens are assembled from parts that already exist.

Redesigning a tool that is already in use

A transport company could ask us to rework its planning tool. We would first measure how long the most frequent tasks take today and where errors happen, then redesign those tasks first and test them with the planners, leaving the rest untouched. Changes reach users in stages, so nobody loses a working day to relearning everything at once.

If the tool itself needs rebuilding, that is custom internal tools development; if the product does not exist yet, start with MVP development and discovery. Either way, you see designs and prototypes at a working demo every two weeks, and the project has one fixed price; more on how we work.