What's the best way to navigate 300+ food orders in a dashboard?

Question

I'm working on a dashboard for restaurant kitchen. This will handle incoming set meal requests that are initiated on the waiters tablet as they take the customers order. it will be viewed on a tablet as well.

It's quite a large restaurant and can have up to 300 meal orders at peak hours. I've designed the following UI.

Details of 4 orders can be viewed at a time, each order header is coloured based on the time left to full-fill the order, E.g. the estimated preparation time of an order is 15 mins, at 15-10 it will be green, at 10-5 it will be yellow and at 5 mins and below it will be red. The action button at the bottom of each order updates it status. Status is updated as start preparing > ready for collection > mark as complete.

The solution I came up with is the bottom panel below, which helps navigate all the active orders. It has tabs to filter by status. While this seems OK to navigate, I'm wondering is there a better way to make it easier for chefs to see all orders at a birds eye view and navigate easier. Right now it feels like there's too much information.

Answer 1

Add number grouping to quickly navigate to a particular part in the set of orders/numbers.

As an example I have added an idea to your current design. It's based on a time-line and allows to press on the range buttons, but ideally also in between them. Or if this is a native app, it could work with swiping to swipe fast through the whole range of orders (a bit like the iOS alphabet scroll function in the contacts app).

It is just one horizontal line of order numbers that can be scrolled horizontally and the time-line concept below to make scrolling over longer ranges easier. This idea also allows to have bigger buttons and status tabs. It will make them easier to spot and touch, which is a big plus for an app used under time pressure.

Answer 2

With so many elements it's somewhat complex. In fact I see some redundancy in the explanation and elements to show.

What can help is to put a little order in the arrangement of the elements.

At a glance you develop all the lower information in no order. I think it can be simplified to a double or triple entry table.

For example:

• Orders have two states: Active and Complete. This reduces all orders to just two groups.
• Complete orders don't need any extra information, their relevance is limited to showing them.
• Active orders have various states that could be shown in the second entry of a hypothetical table (hidden in the "completed" orders).
• It could be useful while designing and later in the use to define all these actions according to the time order

Answer 3

If a large number of orders needs to be managed in the same window, the best option is to divide them into different areas according its status, with easy access for each one.

Main division should be Active and Completed orders and Active orders should be grouped by their service status relative to the customer.

As in a restaurant efficiency in service time is a main requirement, I would sort active orders by elapsed time and progress, highlighting those that exceed what would be an acceptable service time.

Note: Although it's not in the wireframe I'd also add counters in both tab bar and vertical tabs to be aware of pending job at a glance. (E.g: Pending(180) > New Orders(2) Preparing(27) Partially Served (151) and so on..)

Answer 4

I presented my idea below with it's roughly described content so that you may customize with the components you already have more concisely.

• Mainly I removed the below components to the left of the screen which actually keeps the same tab bars but only have a CTA button to show at first glance. You may still try to use the same tab bar, I couldn't illustrate further since it was not possible with the prototyping tool.
• Then I displayed the orders at main sight of the user to be able to list or search any of the needed order as (s)he wish.
• And last, at the right part of the screen, I presented a section to be able to edit what's on the card a.k.a orders here.

By this presentation, it's more intuitive I suppose for the user;

1. with the left of the screen, it's just for selecting/viewing all the orders,
2. middle of the screen is just for searching and viewing the selected order,
3. and the right of the screen is just for editing selected order (both for chefs and servants).

Note: I didn't need to illustrate further as you have very informative presentations for instance order cards since it's not a high fidelity.

Answer 5

My main question would be how the chefs and waiters are going to use this app. You might end up with two different views for these two user groups!

As for the chefs, are they doing to focus on a single order all the time, prepare everything from it, finish it, and only then move on to the next? Or are they going to "peek" ahead to see what they might be able to do in parallel? I'm not a chef, but I could imagine that a little "bulk processing" might be beneficial, which would mean for the screenshot you provided, to prepare 2 Waldorf salads, 2 mixed salads, and 2 assorted satays in parallel (possibly even start with 4 "generic salads", if the "mixed" and the "Waldorf" are close enough). If such a bulk processing is feasible, you might want to break up the "chef's view" and not even show full orders, but group by "similar dishes" first, then (of course) sort them by "order age" (so that a singular, rare order doesn't accidentally get pushed back all the time). In this case it's mandatory to create a separate "waiter's view", as they must be able to see the orders as such.