Consumer apps compete for attention. Business software doesn't, your team has to open it either way. That changes what design is for: not persuading anyone to come back, but making sure the person who has to do this fourteen times today can do it without thinking. Most internal software fails at that, and the symptoms are consistent.
| What you're seeing | What it usually means |
|---|---|
| Your team went back to the spreadsheet | The new system takes more steps than the old one for the task they do most |
| Every new person needs a training session | The interface encodes knowledge that should be visible on screen |
| The same support question comes up weekly | One screen is ambiguous, and nobody has fixed it because it's “just training” |
| Nobody uses the feature you paid to build | It's discoverable in the wrong place, or it solves a problem in a way people don't recognise |
None of these are training problems, though they're usually treated as one. All four are design problems with specific, findable causes.
Design agencies and development firms both say "UI/UX." They usually mean different things, and it's worth being clear which one this is.
Every system we ship is designed, screens, flows, states, and the decisions about what goes where. It's part of the build, not a line item you can decline.
We assess an existing application against how people actually use it and give you a written report with prioritised, specific fixes. You can hand that report to any developer, including ones who aren't us.
Where the logic is sound and the interface is why adoption failed.
Because the same team builds it, nothing gets designed that can't be built, and nothing gets quietly simplified in development without a conversation.
Logos, brand identity, marketing sites, illustration, motion design, not our field, and you should hire people whose whole practice is that.
If you're choosing a partner based on visual craft and aesthetic range, there are studios far better suited than us and we'd rather you used one.
We don't produce Figma files for someone else to implement. Design here is attached to systems we're building or auditing.
If your software is unattractive but your team uses it fluently, leave it alone. Cosmetic redesigns of functional systems are the least valuable work in this field.
We design business software so it's fast to use for people who use it every day. That's a narrower claim than "UI/UX design" and it's the one we can actually make.
Software your team is required to use fails differently from software people choose. The failures are consistent enough to name.
Every field the database has, laid out in the order the schema defines, with the same visual weight. The screen reflects how the data is stored rather than how the work is done, so the field someone fills in forty times a day sits between two they've never touched.
What fixes it: designing from the task backwards. Watch someone do the job, find the sequence, and build the screen around that. Frequently used things get prominence; rarely used things get out of the way.
Someone in scoping said “but what if a customer has three billing addresses?”, and now every single order screen carries the complexity of a case that occurs twice a year. The exception got designed into the default path.
What fixes it: designing the common path to be fast and putting the exception one deliberate click away. Most business software is slow because it's permanently prepared for something that rarely happens.
Every option presented equally, no defaults, nothing pre-filled, nothing suggested. It feels neutral and it's exhausting, the user makes forty decisions to do one thing. Neutral interfaces push all the cognitive work onto the person.
What fixes it: defaults that are right most of the time, and clear primary actions. An interface with an opinion is faster even when the opinion is occasionally wrong, because being wrong occasionally is cheaper than deciding constantly.
It was demoed, approved by people who won't use it daily, and shipped. The confusions that kill adoption are almost never the ones the people who commissioned it predicted, and they surface in the first ten minutes of watching one real user.
What fixes it: watching actual users, before launch, doing real tasks with no help. It's the cheapest research there is and it's the step most consistently skipped.
For internal tools and portals, watching real users before launch is the difference between adoption and a quiet return to email.
You don't commission this separately. It's how every system we ship gets made.
What happens in what order, including the failure cases, empty states, errors, partial data, someone doing it wrong. Those states are most of real software and they're what gets skipped in mockups.
Not clickable prototypes. Prototypes tell you whether people understand a concept; real use tells you whether they can do the job, and only the second one predicts adoption.
Same team, so the compromise conversation happens at design time rather than being made silently by a developer at 11pm.
Business software should be legible, consistent, fast, and accessible. Ambitious visual concepts age badly and slow people down. If you want something visually distinctive, that's a studio engagement and we'll say so.
Process, stack, pricing, and what you receive on handover are all on web applications, design isn't priced separately because it isn't optional.
You have an application. People use it reluctantly, or don't. You need to know why, specifically, before you spend anything on fixing it.
We work through the system doing the tasks your team actually does, then watch three to five of your real users do the same with no help. Not a heuristic review from a checklist, a checklist tells you what's unconventional, and watching people tells you what's costing them time.
Each with the screen, what goes wrong, why, and roughly what it costs in time or errors. Not “improve information hierarchy,” the actual thing, on the actual screen.
So you can see which are an afternoon and which are a rebuild. Most lists are heavily weighted toward the afternoon end, which is the useful discovery.
Of the sessions, so the people who'll implement the fixes can see what happened rather than reading about it.
Sometimes the interface is fine and the real problem is the process, the data quality, or that the system solves a problem people don't have. We'll say so, and that answer saves more money than the audit costs.
Nothing. The report is yours. Hand it to your own developers, another agency, or nobody. We'd rather run audits that go elsewhere than have people assume the recommendation is shaped by wanting the follow-on work.
If the fixes point toward a rebuild, web applications covers how that works, and the audit fee comes off the build.
Internal tools and admin panels — Used all day, by the same people, for the same tasks. Speed and muscle memory matter more than anything else here.
Client and vendor portals — Used occasionally, by people who won't be trained and won't try twice. Obviousness matters more than efficiency.
Dashboards and data interfaces — Where the hard part is hierarchy: what's on screen first, what's one click away, and what shouldn't be there at all.
Field and mobile tools — Used standing up, outdoors, in gloves, on old phones. Large targets, high contrast, minimal typing, and a design that assumes bad conditions rather than ideal ones.
Not for design-only builds, we don't produce Figma files for someone else to implement, because designs handed over without the team who'll build them tend to get quietly changed in development. The UX audit is genuinely standalone: you get a written report and you're free to take it anywhere.
No. That's a different discipline and you should hire a studio that does it properly. We work within a brand you already have, or with restrained defaults if you don't yet.
Yes, and it's common. We'll flag anything that's expensive to build relative to its value or that misses a state, empty, error, loading, partial data, before we start, so the conversation happens at quote stage rather than mid-build.
$399, and it takes about a week. That includes sessions with three to five of your real users, a prioritised written report, and a recorded walkthrough. If it leads to a build with us, the fee comes off the build.
Sometimes. Sometimes the interface is fine and the problem is that the system solves something people don't actually need, or that the data in it isn't trusted. The audit is designed to tell you which, because spending a redesign budget on a non-design problem is a common and expensive mistake.
Task-focused research as part of design and audits, watching people work, understanding the sequence, testing with real users. Not large-scale generative research, ethnographic studies, or survey programmes. Those need a dedicated research practice.
We build to WCAG AA, keyboard operation, contrast, focus states, screen reader semantics. For business software this isn't only compliance: the same choices that make an interface usable with a screen reader tend to make it faster for everyone.
Then engage a design studio and bring us the result, we build from external designs regularly and well. Our visual work is deliberately restrained because that's what business software should be, and it's an honest limit rather than a philosophy we'd defend in every context.
If you're considering a build, the design work is part of it, process, pricing, and what you receive are all on the web applications page.
