You’ll have a few different departments

At the start, there’ll be many index pages that only list entries, eg. suppliers, buyers, orders. Then you add filtering, searching, and sorting to those lists. Over time, you’ll also add actions to each entry.

This is a natural progression.

Eventually, the processes for each department start getting more defined

Issues start happening when different jobs need to see different information and do different things.

One page trying to do multiple things won’t be able to do any of them very well.

Dumping all the information into one page also slows it down and makes it tough to keep it presentable.

The order index is often the first to suffer from this. Different jobs require very different information about orders. They also need different status dashboards and different filtering abilities.

When you reach that point, consider building more specific interfaces for each of the departments and roles

For instance, fulfillment needs to see which orders are overdue, what stage of fulfillment they are in, what logistics they use.

Depending on the order state you can also selectively show more or less information. For example, when the supplier is fulfilling the order, you can show their contact information. But, if it’s a third-party logistics provider, you can show the tracking link.

Similarly, depending on the state of the order, you can show different actions. So, for instance, if the order is delayed, you can make it easy for the admin to pre-emptively message the buyer to let them know.

Without a dedicated dashboard for the fulfillment team, all this information would go into the order list.

After doing this for every department, the order list gets very crowded. So, it won’t work well for anyone.

The best way to solve this is to have separate dashboards for each job. Generic indexes can still exist, but work should be done on custom-tailored pages.

And each interface should only have the information and actions relevant

For Supplybunny, the fulfillment got their dashboard. It had the order statuses, what logistics they use, and the necessary follow-up actions. That information was then removed or made less prominent in the generic order index. At the same time, the fulfillment dashboard also didn’t have generic columns such as order value or buyer and supplier names. Instead, it had order weight and pickup and delivery addresses.

The primary actions for the two pages were also different. In the order list, access to documents was primary. On the fulfillment page, it was to follow up with the delivery contact.

We also built different dashboards for customer service, tracking customer communication, reviews, among others.

The main benefit is more efficient operations

But also that the dashboard models your processes more closely. This way you can mold your processes through the dashboard interface as well.

Onboarding and training get a lot easier too. Firstly, it’s because pages would be better designed therefore easier to understand. But also because they’ll contain only the subset of information that’s relevant to the person.