Tableo
餐厅的二维码不应再只是一份PDF，而应成为销售渠道。
- 年份
- 2026
- 制作周期
- 9 周
- 技术栈
- React · TypeScript · Vite · Supabase · Vercel
- 产品设计
- 移动端设计
- 开发
- 数据库
- 支付
Kayzen Web自主开发的产品，在启用正式域名之前，暂以Vercel预览地址提供服务。
- 扫码后打开菜单
- < 1 秒
- Lighthouse 性能
- 91/100
- Lighthouse 无障碍低于我们 95 分的门槛：问题出在菜单的对比度上——菜单沿用各家餐厅自己的配色；相关整改已排入下一次优化计划。
- 87/100
需要解决的问题。
背景
Tableo 把餐桌上的二维码变成一个完整的界面：实时更新的菜单、点餐、支付、评价收集和客流数据。
限制
自 2020 年以来，二维码名声不佳，因为它最初被用来展示一份难以阅读的 PDF。这款产品必须从手机首屏起就扫除这段记忆，而且是在不利的环境下——嘈杂的店堂、单手操作、网络拥堵、赶时间的客人。
对策
先设计顾客端，绝不先做后台。菜单在一秒内打开，无需安装、无需账号，单手即可轻松阅读。餐厅老板的管理后台是后来才做的，并受限于顾客端实际产生的数据。
交付时测得的评分。
以下为线上网站的Lighthouse评分。我们如实公布：若某项分数偏低，其原因与改进计划会在下文写明，而不是避而不谈。
每一个设计取舍，及其理由。
为拇指而设计
分类导航吸附在屏幕底部，位于拇指可及的区域。触控目标不小于 44 px。人们看餐厅菜单时往往站着、单手，另一只手还端着酒杯。
照片可有可无，绝不强制
很少有餐厅拥有每道菜的像样照片。没有图片，菜单依然优雅；有照片时，它们是锦上添花，而不是页面的骨架。
一眼看懂的管理后台
餐厅老板在两个餐段之间查看后台。顶部三个数字，其余放在首屏以下。没有任何需要仔细研读的图表。
项目配色
棕褐色
#7C4A21
品牌识别、页头
奶油色
#FBF7F0
菜单背景
墨色
#1C1917
正文
下单绿
#15803D
确认
字体系统
标题字体
Outfit 700
正文字体
Inter 400
价格采用右对齐的等宽数字：对不齐的价格列，看起来就像一份敷衍了事的菜单。
幕后的技术实现。
- React
- TypeScript
- Vite
- Supabase
- Vercel
Supabase 实时推送
订单通过实时订阅即时传到后厨。定时刷新会在最显眼的地方增加延迟。
按门店隔离数据
行级访问策略：从结构上保证一家餐厅无法读取另一家的数据。在多租户产品中，这条规则属于数据库，而不属于应用代码。
第三方支付
没有任何银行卡数据经过本产品。由支付服务商负责卡号录入和 PCI 合规；对于这种规模的团队来说，这是唯一合理的选择。
网站如何被搜索到。
SEO 服务于软件销售
餐厅的菜单并不需要被索引——它每天都在变，也不回应任何搜索。SEO 瞄准的是“logiciel commande à table”（桌边点餐软件）、“QR code menu restaurant”（餐厅二维码菜单）这类餐厅老板会搜的词。
人人都能使用。
自2025年6月起，《欧洲无障碍法案》（European Accessibility Act）要求大量在线服务实现数字无障碍。我们在设计阶段就着手处理，而非事后补救。
重新审视菜单对比度
餐厅菜单常常滥用白底浅灰字。所有颜色组合都在 4.5:1 以上，包括价格和过敏原标注——它们是否清晰可读，关系的可不只是舒适度。
交付了哪些内容。
- 产品官网
- 顾客端（二维码）
- 餐厅管理后台
- 价格
- 账号
项目的推进过程。
顾客端
在写任何一行后台代码之前，先在店堂里测试移动端原型。
后台
菜单、分类、供应状态、营业时间。
点餐与支付
后厨实时推送，第三方支付服务商。
数据分析
客流、浏览最多的菜品、平均客单价。
