Making a warehouse system you can read at a glance

Datapel builds warehouse management software for businesses across Australia and beyond. Their product did a lot. Stock lookup, order tracking, receiving, despatch, assemblies, accounting integrations. The problem was that it had grown one feature at a time, and it showed.

Scope: 8 core modules, 6 report families, point of sale, and light and dark themes.

The problem

Warehouse staff and managers spend their whole shift inside this tool. When it is slow to read, they pay for it on every order.

When I started, four problems kept coming up.

1. No one could get the reports they needed. Reporting was the main reason managers opened the system, yet reports were scattered across menus and opened in different ways depending on the module. Forecasting was close to impossible.
2. Nothing stood out. Every row, number and status looked the same. To spot a late order or a low stock line, you had to read the whole table.
3. Each module felt like a different product. Sales, Despatch and Transfers had been built at different times, so their layouts, filters and actions didn't match. Learning one didn't help you with the next.
4. The interface looked its age. It worked, but it felt dated next to the tools Datapel's customers used every day, and new users needed a long time to get comfortable.

The real challenge was fixing all of this without taking anything away. Power users knew where everything lived, and a warehouse can't stop working while people relearn their tools.

What I did

I owned the experience end to end: research, information architecture, interface design, the design system, and front-end build. Being both designer and developer meant every decision had to survive contact with real data, not just look good in Figma.

Here is how I worked through it.

1. Listened to the people using it. I spoke with Datapel customers and internal staff about where they lost time. Reports came up in almost every conversation.
2. Mapped every module. I audited Receiving, Assemblies, Item List, Transfers, Sales, Despatch, Locate and the Dashboard side by side. Most of them did the same few jobs: find a record, check its detail, act on it. They just did it differently.
3. Designed one pattern, then applied it everywhere. Instead of redesigning eight screens, I designed one register layout and one set of components that every module could share.
4. Rebuilt reporting around how people actually ask questions. User feedback shaped the navigation, the flows and how data is grouped inside each report.
5. Built it. I turned the design system into front-end components so the light and dark themes stayed in sync in code, not only in the file.

Problems I solved

One place to start, in every module

I moved the core modules into a single icon bar across the top: Dashboard, Receiving, Assemblies, Item List, Transfers, Sales, Despatch and Locate Contacts. Wherever you are, every other part of the warehouse is one click away.

Below it, every screen now follows the same layout. Search and filters sit on the left. The register sits in the middle. Details for the selected record open underneath. Once you learn Sales, you already know how Despatch works.

Registers you can scan, not read

The old tables made you read every row. I added a coloured status dot and a status tag to each line, so open, late and completed orders separate themselves at a glance. Each register shows its record count up front, so you know the size of what you are looking at before you scroll.

I also gave people control over density. View More Details and View Less Details let a manager see everything while a picker sees only what they need. Saved views like By Price or By Order Quantity, plus Create View, mean people stop rebuilding the same filter every morning.

Detail without losing your place

Previously, checking a record meant leaving the list. Now, selecting a row opens its detail in a panel below: location, quantity on hand, quantity on hold, batch serial and bin, with tabs for details, attachments and notes. You check a line and move to the next one without losing your place.

Shortcuts where the work happens

Each module's most common actions now live in the side panel. In Sales that means Display Sale Details, Cancel Order, Start DataPOS and New Sale Order. I grouped shortcuts for every module (Item List, Receiving, Assemblies, Transfers, Despatch and Sales) so nobody has to dig through a menu for an everyday task.

Reporting that answers questions

This was the heart of the project. I reorganised dozens of reports into six families that match how people think about their business: Purchase, Stock, Sales, Transfer, Assemblies and Contacts. Every report now opens the same way, with the same filters in the same place.

The Report Form Viewer gives every report one consistent preview with page controls, zoom and a one-click Download as PDF. No more guessing which format a report will arrive in.

A faster till

DataPOS, the point-of-sale flow, is used at a counter with a queue. I designed it around the keyboard and the scanner. The common actions are big tiles, each labelled with its key: F4 for Customer Search, F3 for Stock Search, F5 to void, F9 to view sales. A large scan field sits front and centre with the running total beside it. Action buttons show their shortcut too, like DEL to remove a line and F8 to take payment, so staff learn the fast way just by using it.

One system, two themes

To keep eight modules consistent, I built a single component library: navigation, table headers and rows, tabs, form fields, buttons, popups and pagination. Light and dark mode share every component, so a change made once shows up everywhere.

Colour does real work here. Blaze Orange is the primary colour and marks actions and the active module. Admiral Blue is the secondary colour and anchors the navigation. Green, amber and red are kept for status, so they always mean something. Headings use Madani Semibold for character, and everything else uses Inter, which stays readable in dense tables.

Dark mode wasn't an afterthought. Warehouses run long shifts, often under harsh or dim lighting, so people needed a choice. Designing both themes from the same tokens meant neither one was a compromise.

The result

The new system takes less time to learn and makes it clear what each part does. Because every module follows the same pattern, someone who knows one screen can find their way around the rest. And reports, the part people complained about most, now all open the same way from one clear place.

User feedback after rollout pointed to a clear improvement in both satisfaction and speed, especially around generating reports.

What I'd take forward

The biggest lesson was that consistency is a feature. Users didn't ask for a design system. They asked to stop relearning the tool every time they changed modules. Solving that one problem fixed half the others.

Being the developer as well kept the design honest. Long product names, empty states and 3,000-row registers showed up early, so the final screens hold up with real data, not just with placeholder text.