UX for Internal Business Systems: Making Complex Work Simple

Plenty of internal systems have every feature that was asked for in the brief, and staff still keep the real record in a spreadsheet next to it. The software fights the order the work happens in, so people find the faster route.

If you are about to build or rebuild an internal tool, the outcome is decided by how the screens are laid out and how early the people using them get to correct you. Below is what usually goes wrong, and what you can ask a vendor before anyone starts work.

Why staff go back to the spreadsheet

The pattern repeats almost everywhere. The system exists, the licence is paid, and the record the warehouse actually trusts is one Excel file that one person maintains. The official system gets filled in afterwards, sometimes every few days, sometimes the week before month end.

Logging one item out takes a dozen clicks: pick the location, pick the document, search for the item code, enter the quantity, save, go back to the start for the next line. In Excel that is one row, and a long list is finished before the system has loaded its second page.

The cost turns up somewhere else. You read a summary built from numbers that are a few days old, then approve a purchase against stock that has already moved. The process also depends on one person who knows what is in that file, so the work stops when they take leave.

Complex work, simple screens: what that actually means

Simple does not mean fewer features. Warehousing, billing and scheduling are genuinely complicated, and that complexity cannot be deleted from the screen. What you can control is how much of it one person has to carry at once.

The difference shows up most clearly in forms. A form that mirrors a database table shows every column in that table, in the order the columns sit in the database, so region code, branch code, document type and tax status all land on one page together. A form that mirrors the task asks only for what the system does not already know, in the order an admin would ask a customer for it.

The rest gets filled in by the system. Once the admin picks the customer, the delivery address, payment terms and agreed pricing appear, because all of that is already stored. One screen does one job, and it arrives half complete. The general argument for what design is worth to a business is set out in the business value of UX design; this piece is the internal-systems case of it.

Design the path through the day, not the feature list

Start from the sequence one person moves through, not from the module list. A sales admin receives a request by chat or email, checks stock, confirms price and delivery date with the customer, then records the order. Those four steps are the frame for the screens.

Follow that frame and the stock check sits on the same page as the order being typed, rather than in a different menu that forces a second browser tab. The confirmation message to the customer can be drafted from there too, because that is where the work happens.

Features nobody reaches on that path have a cost. They still have to be built, tested, maintained and later understood by the next developer, and nobody opens them. Record them for a later stage and decide after the system has been in use for a month. For the customer-facing side of the same discipline, we cover that separately in UI/UX design and business growth.

The screens that decide whether people use it

Three of them carry the weight. The daily list answers one question: what do I have to deal with today, ordered by what is most urgent, without setting a filter first. The single record view holds one order or one customer with its history attached, so someone can answer the phone without opening three pages.

The third usually has no design at all, which is the screen for when something has gone wrong. Stock goes negative, a payment lands twice, an admin picks the wrong customer and the record is already saved, or goods ship against an order that was cancelled.

In a lot of internal systems that ends in an error message with no way forward, or in a message to the vendor's phone. That is the point where staff stop trusting the software and open the spreadsheet again, because in Excel they can fix a mistake themselves on the spot. So ask early: when the data is wrong, who is allowed to correct it, from which screen, and is the change recorded.

Designing for the person who was never trained

Internal systems keep inheriting new people. Someone starts next month, someone covers a colleague's shift, a shop lead opens the system only at month end. None of them were in the training session three years ago.

What helps them is labels in the words the business already uses. If the warehouse calls it a delivery note, the screen says delivery note, not "outbound shipment document". State has to be visible without interpretation: is this order paid or not, shipped or still waiting. Actions that can be undone also make a new person willing to try.

The same requirement covers staff running the largest text size on their phone, or working in a bright warehouse with one hand holding a box. That belongs to this design work rather than a separate project, and we go further into it in accessibility and inclusive design.

Working screens beat a design document

We hand over product design as screens you can open and click, not as a PDF. Your operations lead cannot judge a workflow from a picture in a document, but they know something is off the moment they try to enter one real order.

So there is a demo every week and a private preview link from the first week. The people who do the work can open it themselves and say "that is not the order we do it in" while changing a design decision is still cheap. The same comment arriving after launch means rework.

The reasoning behind each design and technical decision is recorded next to the code. Whoever maintains the system later inherits the thinking rather than only the files, and does not undo something that was deliberate.

What to ask before the build starts

You do not need to understand the technology to judge whether a vendor will handle this part properly. Four questions are enough, and they sound different coming back from a vendor who has thought about it.

• Who will watch an admin or a warehouse person do the job before a single screen is designed, and when.
• When do I get a screen I can click, and who on my team is allowed to try it.
• What happens when the data is wrong: who may correct it, and from which screen.
• If the flow you design turns out not to match how we work, what does changing it cost and at which stage.

That last question connects directly to how you pay. Because scope and price are agreed in writing before each stage begins, a wrong design direction costs one stage at most rather than the project, and you can stop after any stage without an argument.

One more thing, which often saves more money than good design does. If an off-the-shelf tool sold on a monthly subscription already covers the process, we will say so, and you spend nothing on a build.

Tell us which part of the system your staff skip

You do not need a technical requirements list. Describe which parts of the current system staff work around, and what records they still keep outside it. If there is no system yet, walk us through one admin's day from morning to close. The first call is free and there is no deck.

If an off-the-shelf tool already solves it, we will say so. If something does need building, discovery gives you a written plan and a fixed price, and that document is yours whatever you decide afterwards. Use the contact form, which opens WhatsApp, or email hello@arktik.id.