Fully Booked 的每个阶段都有固定预算，而创始人需要确信它对运营商真正有用。描述功能的文档很容易被误读，可以一路点击体验的原型却不会。因此每个阶段都先在 Figma 中完成设计和连线，创始人在开发开始前亲手点一遍。
在原型里发现一个错误只需几分钟，而在代码里发现同样的错误要花上几天。这样的工作方式让每个阶段都不超出范围，也让开发人员拿到每个界面的完整参照。
### 三个文件，一个产品这些设计分布在三个 Figma 文件中，分别对应移动应用、客户网站和管理后台，共用同一套颜色样式和组件。运营商从应用切换到 PDF 再到业务主页，看到的是同一个品牌；开发人员无论构建哪个界面，读取的都是同一套设计令牌。
### 像真实产品一样连线界面被连接成完整流程，点击一笔预订就会打开它的详情、地图上的路线以及之后的每一种状态。预订详情原型把每种变体并排摆放，并标出它们之间的跳转路径，创始人正是这样在地图界面开发之前就批准了它们。
### 每份文档，连同发出它的那一下点击一起做成原型整套文档（报价单、取消通知、邀请函、发票、确认函和司机行程单）都在 Figma 中排好版，并用箭头连到发出每份文档的应用界面。创始人可以顺着运营商的一次点击，一路看到客户收到的那一页，同时审定措辞。
### 主屏幕，多个方案反复尝试运营商主屏幕在原型中经历了好几个版本，每个版本都要通过同一项检验：运营商能否看到自己赚了多少，并一键到达每一种多赚钱的途径。最终选定的方案，就是今天应用中的样子。
### 业务主页，写代码之前就已成形为运营商带来直接预订的业务主页在开发前就已完整设计，包括车队相册、简介、评价、地图、营业时间和预订表单，并以原型形式完成评审。引入直接预订的那个阶段，起点就是一个大家早已认可的页面。
### 管理后台和客户网站文件管理后台和客户网站的文件涵盖从登录到付款的每个页面和每种状态，因此网页开发人员依据的是完成的画面，而不是猜测。每个阶段都把新页面加到同样的文件里，让产品在多年之后依然保持一致。
### 原型带来了什么对创始人来说，原型意味着能放心地批准功能，并且只为已经商定的内容付费。对开发人员来说，它意味着没有歧义；对运营商和客户来说，它意味着每个界面在送到任何人的手机之前都已经过充分讨论。
界面背后的思考见UI 与 UX 故事，成品见Fully Booked 故事。