4

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.

  • 1
    Before submitting what I'm thinking, I wanted to underline a couple of inconsistent parts so that I want to alter what's outputted already. Even order 218 presented yellowish background at the buttom of the page, it's demonstrated as it has green headline (topic) which points out it's newly ordered. Other than what's desired to be achieved (it's clear I suppose to get an order track dashboard), if you can make a bit clarification on how did you presented this dashboard (it's obvious not clear so far), there might be more people to support or improve the idea behind the current dashboard. – Erhan Yaşar Jun 16 at 14:35
  • 1
    Have you tested before if a tap on touch screen works when you have greasy / wet hands? Do you have a clear understanding what a chef needs to prepare an order? For instance what happens when the customer says: 'I want a Waldorf Salad without apple'. Is a 'tap' the right interaction for completion? – Kevin M. Jun 17 at 8:01
  • Why are there duplicate order numbers in the tab below? – jazZRo Jun 19 at 7:34
  • @jazZRo ignore them. No there shouldn't be each order number is unique and should have only 1 instance – Ameen Akbar Jun 19 at 8:09
  • 1
    Why is it that a user/chef even needs to navigate the orders? What benefit is it to see the 50th order from now (for example), when the chefs only need to work on the most important orders (the oldest ones). If the purpose of the system is to improve efficiency, then the system should automatically determine which orders the chefs see. Don't leave it to the chefs to try to work it out themselves, they will get lost and mess it up. – musefan Jun 23 at 12:57
2
+50

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.

enter image description here

| improve this 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

enter image description here

| improve this answer | |
2

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..)

enter image description here

| improve this answer | |
  • and what's your prototyping tool? (: – Erhan Yaşar Jun 22 at 14:51
  • 1
    The same as yours @ErhanYaşar :-D Love it! – ɐsɹǝʌ ǝɔıʌ Jun 22 at 15:23
1

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.

order dashboard

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.

| improve this answer | |
  • how would it look when the user clicks "all orders" – Ameen Akbar Jun 17 at 7:31
  • It's the same tab bar component you used but just vertical and the rest of the tabs hidden under this collapsed side panel. The prototyping tool was not satisfactory and you may feel free to modify on your own idea for the rest of the illustration. – Erhan Yaşar Jun 17 at 7:34
  • Only for curiosity. What's the tool you used to make these mockups? They're amazing! – ɐsɹǝʌ ǝɔıʌ Jun 17 at 9:58
  • 1
    It's plain, old Balsamiq, almost the same (or maybe really the same) mockup tool UX.SE provides. I couldn't open the UI Wireframe tool provided within the environment even updated flash but quit trying so that I exported @ɐsɹǝʌǝɔıʌ ǝɔıʌ . – Erhan Yaşar Jun 17 at 10:24
  • @ErhanYaşar Thanks! I'll take a look at it. It is quite interesting. – ɐsɹǝʌ ǝɔıʌ Jun 17 at 10:52
1

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.