项目概况

发餐台是壹向智慧咖啡馆系统中的一部分，安装在门店平板上，由服务员操作，当餐品在后厨制作完成后便会出现在发餐台，客人来领取餐品后，服务员在发餐台上标记该餐品已被领取。

如何流转

用户通过自助点餐、人工点餐下单的餐品先进入后厨工作站，餐品制作完成后，厨师在后厨站上将相应餐品状态设为“制作完成”，这个时候餐品就流转到了发餐台。当客人来取餐时候，服务员在发餐台上将相应餐品状态设为“已领取”。

设计方案

发餐台的界面上，有两种情况。一是没餐品订单的情况，一种是有餐品订单的情况。没有订单的时，显示一句提示，以免界面的空白让人误以为是数据的显示不正常。在有订单的时候，就要考虑如何排列订单，一屏排多少个订单？一个订单里默认显示多少个餐品？因为SaaS系统针对的是咖啡店、轻餐等西餐型的餐厅，一个订单默认显示3个餐品能满足大部分订单的展示。一屏显示的订单数量不是越多越好，也不是越少越好，太多了成了无效干扰信息，太少了影响操作效率（需要大概率确保发餐的订单正在当前屏幕中），所以结合餐厅的出餐效率和每个订单显示的餐品数，一屏定为显示8个订单。

一个订单的餐品不会同时制作完，发餐台订单中的餐品也会有不同的状态：可领取、制作中、已领取，所以在界面上需要对不同状态的餐品有不同的视觉表现。从优先级来看，可领取>制作中>已领取。

在餐厅的日常运营中，经常会碰到客户催菜或问询的场景：“我的×××做完了没有”。这个时候，服务员就会问客户的订单号，但是订单并不一定在当前发餐的界面中，所以需要一个查看全部订单的入口。另外对于一些需要打包的餐品，发餐台上也应该需有所体现，服务员可以在发餐前将餐品打包好。

在发餐台服务员最核心的操作就是“领取餐品”，领取的时候，有可能一次领一次，有可能一次领多个。“领取”这个动作既要考虑操作效率，也要防止误操作。对于防止误操作，传统最简单的方式就是询问式的“二次确实”，显然这个操作效率太低。那么左滑餐品列表显示“领取”，这种移动端常见的操作呢？这种操作在日程生活中当然没问题，但是考虑到餐厅的应用场景就有些不合适了。首先，发餐服务员有时候是带着手套的（因为发餐台的服务员，除了发餐，还要打包、制作饮料等工作），显然就不是适合滑动操作（带着手套操作屏幕的时，他们大多数是用指关节敲）。即使忽略手套的因素，在繁忙时段需要频繁操作时，滑动的效率还是过低。所以，最终采用的方式是：通过点击餐品列表选中餐品，通过点击“领取”完成发餐操作。这样既解决了误操作问题，也解决了多个同时领取的效率问题。

一个订单默认显示3个餐品，那么超过3个的订单，就需要一个查看订单全部餐品的入口。当餐品数量超过3个时，就显示“展开”。