会议室和工位预订应用：先规划规则，再设计界面

先明确要解决的预订问题

会议室和工位预订应用即使外观精致，也可能每天让人感到麻烦。日历无法替你决定团队能否预订会议室一整个下午，也无法决定一个人能否同时占用两个工位，或者没人到场时应该怎么办。这些都属于政策决定，应用需要始终按统一规则执行。

先从人们现在反馈的问题开始。它们通常很普通：有人预订了会议室却始终没来，有访客到了办公室却找不到工位，或者两个团队都以为自己预订了同一个空间。在选择按钮、颜色或通知文案前，先把这些情况记录下来。

不清晰的办公室预订规则会悄悄浪费空间。员工可能连续几个月每周一都预订工位，但这些日子大多在远程办公。其他人看不到可用工位，只好留在家里，尽管许多已预订的座位其实空着。会议室也有同样的问题，因为人们会为了“以防万一”而多预订一段时间。

先做出一小组决定：

• 谁可以预订每种空间，以及最多可以提前多久预订
• 一次预订最长可以持续多久
• 用户能否同时保留多个预订
• 无人签到时，应用何时释放会议室或工位
• 计划发生变化时，谁可以覆盖或修改预订

让政策与界面设计分开。“签到后 30 分钟仍未到场就释放工位”是政策；“在预订旁边显示倒计时”是界面选择。政策帮助公平分配空间，界面则帮助人们理解政策。

例如，一个六人团队可能在 10:00 需要会议室，同时团队中的一名成员预订了同一个上午的工位。这没有问题。但如果会议室规定必须在 15 分钟内签到，而没人到场，应用就应在 10:15 释放会议室，并通知团队。

用员工看得懂、也能提出意见和修改的句子来写政策。不要写“尽快取消未使用的预订”这种模糊表述。应明确时间、动作和例外情况：“除非组织者完成签到，否则应用会在会议室开始时间过后 15 分钟释放该会议室。”规则越清楚，重复预订、冲突提示和通知就越容易构建。

列出空间和使用应用的人

当每个空间都遵循同一套规则时，预订应用很容易失效。建立符合实际办公室情况的资源清单：封闭式会议室、开放式工位、安静区域、电话亭、培训区、停车位，以及需要共享的设备。

为每个空间使用人们熟悉的名称。如果两层楼都使用“3 号会议室”这个名称，就很容易出错。“海湾会议室，2 楼”能让访客知道该去哪里。工位区域也一样，名称最好说明用途，例如“靠窗工位”或“支持团队区域”。

记录会影响选择的详细信息。一个有屏幕和摄像头、可容纳六人的会议室适合客户通话，却不适合 12 人的工作坊。在用户预订前就显示无障碍信息，不要等到预订后才把它藏在备注里。

每条资源记录应包括：

• 位置、楼层和附近的地标
• 容量和可用设备
• 无障碍信息，例如无台阶通行或可调节工位
• 接受预订的时间
• 是否需要经理批准预订

访问规则也需要同样具体。在创建日历前，先决定谁可以预订每项资源。销售团队可以预订客户会议室，而任何员工都可以预订共享工位。有些部门会议室可以在特定时间后向所有人开放。

避免使用“仅限员工”这类模糊权限。在应用中明确列出群组：员工、承包商、办公室经理、访客和管理员。然后写清楚每个群组可以做什么。承包商可能可以预订一天的工位，却不能预订会议室。办公室经理可以更新会议室信息，也可以在空间因维护关闭时取消预订。

只有在审批能防止实际问题时才加入审批。大型会议室、高管空间、非工作时间的访问权限，以及配有专业设备的培训室可能需要审批。普通的双人会议室通常不需要。审批步骤过多，会让人们重新回到聊天消息和电子表格。

Koder.ai 可以通过聊天把这份资源清单转化为早期应用计划。用简单语言描述每个空间、用户群组及其权限，让界面和通知遵循办公室规则，而不是自行猜测。

一步步定义可用性

可用性不只是日历上的一个空档。每个空间都有自己的开放时间、限制和关闭日期。在设计日历前，先用简单语言定义这些规则。

先按空间类型分别处理。安静工位可能在周一至周五的 8:00 到 18:00 开放。会议室可能为了客户通话而开放得更晚。如果某个部门管理一间会议室，就要在发布日程前应用相应的访问限制。当应用允许用户选中空间，却在最后一步拒绝预订时，人们会感到很恼火。

设置最短和最长预订时长。工位可以使用半天或全天时段，会议室则使用 30 分钟的时间段。最短预订时长设为 15 分钟，常常会让日历出现难以利用的零碎空档。对许多办公室来说，会议室按 30 分钟、工位按半天预订更容易管理。

判断一个时段是否开放时，按清晰的顺序检查：

1. 确认空间在请求时间内处于开放状态。
2. 检查节假日、维护、清洁和私人活动。
3. 检查空间是否已经被其他预订占用。
4. 应用预订时长和访问规则。
5. 应用提前预订时限。

管理员应为关闭时段添加原因。“更换投影仪，13:00 至 16:00”比日历上的一大片空灰区域清楚得多。公司假日可以关闭所有相关空间，私人活动则可能只关闭一间会议室。

确定人们最多可以提前多久预订。如果办公室出勤情况经常变化，两周的预订窗口可能就够用。如果团队需要规划工作坊或访客会议，60 天的窗口可能更合适。组织者可以比普通员工提前更久预订，但应用应清楚说明这种差异。

检查规则之间是否冲突。如果工位允许全天预订，但办公室 8:00 开门、18:00 关门，就要在应用中定义“全天”的具体含义。如果会议室 18:00 关闭，那么两小时的预订就不能从 17:00 开始。提前处理这些小细节，可以避免之后出现令人困惑的冲突提示。

第一版规则应保持简短，让办公室经理几分钟内就能审阅。政策批准后，Koder.ai 可以帮助你把书面规则转化为日历逻辑、管理员控制项和通知。

设置重复预订规则

重复预订可以免去每周重复预订同一个工位或会议室的麻烦。但如果应用把重复预订当成一整块永久占用的时间，也会带来问题。设计日历前，先确定规则。

提供符合办公室日常习惯的重复选项：每天、每周和每月。每周重复适合每周二 10:00 的团队会议。每天重复适合在短期项目中使用同一个工位的人。每月重复适合每月第一个周一举行的工资审核等活动。

每个重复系列都需要结束日期。不要提供“永远持续”这一选项，它可能让热门会议室在几个月内悄悄被占用。让用户选择结束日期或固定的重复次数。如果办公室政策有要求，应用也可以限制系列长度，例如最多重复预订 12 周。

保存前检查每个日期

应用应检查每一次重复发生的日期，而不是只检查第一次预订。会议室可能在其中一天因维护关闭，也可能有其他团队已经占用了系列中的某个后续时段。

确认前显示预览，包括会议室或工位、时间、重复模式、结束日期和预订总数。如果有些日期无法预订，应列出具体日期并说明原因。

例如，Priya 每周三 14:00 至 15:00 预订 Cedar 会议室，连续八周。设施团队在第四个周三关闭会议室进行维修。应用应允许她确认另外七个开放日期并跳过维修日期，或者为那一次会议选择其他可用会议室。

未经用户许可，不要自动把会议转移到另一间会议室。不同地点可能影响参会者、设备和无障碍安排。

让修改结果可预测

用户需要两种编辑方式：修改单次预订，或修改整个系列。如果 Priya 只把第六次会议改到周四，其他七次预订都应继续安排在周三。如果她把整个系列的时间改为 15:00，应用应重新检查所有未来日期，并在保存前报告冲突。

取消也应采用相同方式。允许用户取消某一个日期、所有未来日期，或整个系列。这样可以避免未使用的重复工位预订一直占用同事本来可以使用的空间。

决定签到如何运作

只有有人实际使用空间，预订才有意义。设置一个较短的签到窗口，在预订开始前不久开放，并在开始后不久关闭。例如，预订时间为 10:00 的会议室可以在 9:50 至 10:10 之间签到。这样人们有时间到达，也不会让空会议室整个上午都被占用。

选择一种确认到场的方式。用户可以在应用中点击“签到”，扫描门口的二维码，或者使用会议室外的平板设备。整个办公室最好保持一致。如果工位使用应用签到、会议室使用墙上的平板，就要清楚解释两种方式。

未签到后释放空间

在构建通知前，先写好未签到规则。签到窗口结束后，应用应取消预订，并重新开放会议室或工位。同时告知原预订人发生了什么。

公平的政策通常会包含一小段宽限时间。用户可能因为上一场会议延迟，或排队等电梯而晚到。一个小时的会议室预订可以设置 15 分钟宽限期，而会议时长为 30 分钟的办公室可能需要 5 分钟。

决定反复未签到是否会带来后果。可以先发送提醒，再考虑对经常占用却不使用空间的人暂时限制提前预订。一次错过预订通常不足以实施严厉惩罚，计划总会发生变化。

允许会议主持人为全组签到

对于群组会议，主持人应能替所有人签到。要求每位参会者都确认，会增加不必要的阻力。如果主持人没有到场，可以在预订开始后允许另一名受邀参会者接管签到。

规则触发后，应用应立即释放未使用的会议室。然后提醒那些希望在会议室空出时收到通知的人。一条简单的消息就够了：“Orchid 会议室现在可用，直到 11:00。请在被别人预订前使用它。”

保留活动记录，包括预订时间、签到时间、取消操作和释放原因。办公室经理可以利用这些记录找出纸面上看起来很忙、实际上却经常空置的会议室。当两个团队都声称预订了同一个空间时，活动记录也有助于解决争议。

Koder.ai 可以帮助你在花时间打磨界面前先建模这些操作。在聊天中描述时间安排、谁可以确认到场，以及释放政策，再用真实预订测试几种未签到情况。

编写清晰的冲突提示

预订冲突提示应使用简单语言解释问题，并告诉用户下一步该做什么。“预订失败”这类消息只会增加客服请求。清晰的提示能让用户不用猜测，就选择其他会议室、工位或时间。

同一个空间的所有时间重叠都应被阻止。如果 Maya 预订了 Alder 会议室 10:00 至 11:00，应用必须拒绝任何覆盖这段时间的其他预订，包括 10:45 至 11:30。个人工位也应遵循相同规则。

在提示中写明空间、日期和冲突时段。例如：“Alder 会议室已在周二 10:00 至 11:00 被预订。你请求的时间为 10:45 至 11:30，与现有预订重叠。”除非办公室政策允许，否则不要透露现有预订人的姓名。

给出有用的下一步

如果应用能找到替代方案，就显示出来。可以提供请求时间内座位足够的开放会议室，或显示同一会议室最近的可用时间。对于工位，应先推荐所选区域内的开放工位，再推荐其他楼层。

建议应尽量接近原始请求：

• Birch 会议室，8 个座位，10:45 至 11:30 可用
• Alder 会议室，11:00 至 11:45 可用
• Cedar 会议室，6 个座位，10:45 至 11:30 可用

使用直接的状态标签，例如“预订已确认”“预订被阻止”“预订已修改”和“预订已取消”。每种结果都需要不同的信息。

谨慎处理重复预订

办公室之后临时关闭，可能会与几个月前创建的重复预订发生冲突。一个团队可能每周一预订 Cedar 会议室，之后管理员决定在某个周一关闭办公室进行维护。应用应标记这一次发生，而不是删除整个系列。

要准确告诉用户发生了什么：“你在 10 月 14 日周一的 Cedar 会议室预订已取消，因为办公室将进行维护。其他每周预订仍然有效。”如果关闭只影响部分时间，就提供可用时段或其他合适的会议室。

任何变更都要把相同的信息发送给所有受影响的人。清晰的提示可以避免人们到了现场才发现会议或工位预订已经被应用阻止或取消。

创建与规则匹配的界面

在要求用户填写细节前，先让他们看到可以预订什么。可用性视图应默认显示用户所在的办公室、当前日期和可能的工作时间。如果会议室需要主持人签到、有容量限制或因维护关闭，就在搜索结果中显示相应状态。

对大多数办公室来说，简单列表就很好用。每个结果可以显示空间名称、楼层、空闲时间、容量，以及显示器或摄像头等设备。需要在 14:00 找一间六人会议室的人，不应经过多次点击才能比较选项。

缩短预订流程

用户选择空间后，把选定的日期和时间带入表单。允许他们调整时间，在应用支持的情况下添加参会者，并查看适用规则。重复工位预订可以显示结束日期，以及将要创建的未来预订数量。

保存前使用一个确认页面。重复显示人们经常填错的细节：

• 空间名称、办公室位置和楼层
• 日期、开始时间和结束时间
• 容量及所选设备
• 重复安排，如有
• 签到截止时间和取消规则

“确认预订”应创建预订，“返回”应带用户回到编辑页面。用户不应该猜测应用是否已经保存修改。

把修改放在用户预期的位置

为每个人提供“我的预订”区域，并优先显示即将到来的预订。显示“已确认”“等待签到”“已取消”或“因未签到而释放”等状态。把修改和取消操作放在预订卡片或详情页上，不要藏在很远的设置菜单中。

用户修改重复工位预订时，要清楚说明选择。他们可能只想修改这个周二，也可能想修改未来所有周二。如果新时间与其他预订冲突，应保留原预订，直到用户选择一个空闲选项。

如果 Maya 把 10:00 的会议室预订改到 11:00，而另一个团队已经占用了该会议室，应用应说明冲突，并提供临近时间或类似会议室。未经提示，不应直接取消她原来的 10:00 预订。

走一遍真实的预订场景

Maya 在混合办公的办公室工作。她每周二和周四都需要使用产品团队附近的工位，于是创建了一个重复预订，为 D-14 工位预订 9:00 至 17:00。应用在保存系列前检查工位日历，并确认每个可用日期。

几周后，设施经理发现 Cedar 会议室需要维修。会议室将在周三至周五关闭，其中包括 Maya 的团队每周四下午在那里举行的计划会议。经理将会议室标记为不可用，并记录维修时间段。

应用不应在没有通知的情况下删除 Maya 的会议。它应找到与关闭时间重叠的预订，保留不受影响的每周会议，只标记周四的预订需要处理。用户不应因为一个例外就重新创建整个系列。

Maya 会收到清晰的提示：“Cedar 会议室在 5 月 16 日周四 13:00 至 15:00 因维修不可用。”消息写明受影响的会议、日期和时间，让她可以快速处理。

然后应用尽可能提供符合原始人数和时间的替代方案：

• Birch 会议室，周四 13:00 至 15:00
• Maple 会议室，周四 13:30 至 15:30
• Cedar 会议室，周五 13:00 至 15:00
• 保留会议时间，改为视频通话

Maya 选择 Birch 会议室并确认修改。应用只更新这一次预订，通知参会者，同时保留之后周四在 Cedar 会议室的预订不变。活动记录应显示这次例外由维修关闭导致。

同一个应用也可以在 Maya 到达 D-14 工位时要求她签到。如果她错过允许的签到窗口，应用就把工位释放给其他人。除非她取消，否则未来周二和周四的重复安排仍然有效。

这个场景可以检验重复预订、临时关闭、提示、替代选择和签到规则是否能够协同工作。如果某一步在纸面上就很难理解，放进应用后也会让人困惑。

测试规则并规划构建工作

当规则相互矛盾时，预订应用就会失效。在花时间打磨日历、按钮或通知前，先测试规则。从少量会议室、工位、用户和几天内的示例预订开始。

先检查基本可用性。每项资源都需要明确的可预订时间、时区、相关容量，以及清洁、维护或私人活动的关闭时段。一个看起来 8:00 可用、实际却要到 9:00 才开放的工位，很快就会损害用户信任。

使用简短的测试清单：

• 在会议室正常开放时间内和开放时间外分别预订一次。
• 尝试预订另一个人已经占用的工位。
• 创建一个跨越节假日或关闭日期的重复预订。
• 分别测试准时签到、迟到签到和完全未签到。
• 取消预订，并确认空间重新变为可用。

特别关注重复预订。如果 Maya 每周二预订 D-14 工位，连续八周，而办公室在其中一个周二关闭，应用应跳过那一天并说明原因，不应创建没人能使用的预订。同时测试只修改一次预订和修改整个系列的区别。

未签到也需要同样仔细地测试。如果用户在宽限时间结束后仍未签到，应用应释放会议室或工位并通知用户。测试准确的时间边界：在释放前一分钟签到、在释放时刻签到，以及在释放后一分钟签到。工作人员应立即看到新释放的空间。

像忙碌的员工一样阅读每条提示

冲突提示应写明空间、日期和时间。“D-14 工位已被预订，时间为 10:00 至 14:00”远比“预订冲突”有用。在可能的情况下，提供直接的下一步，例如查看附近的开放工位或选择其他时间。

也要测试重复预订的提示。用户需要知道是某一次预订失败，还是整个系列发生了变化。避免为同一事件发送多条提示，一条清晰的消息就够了。

把经过测试的规则变成构建计划

把每条已批准的规则写成简短陈述：谁可以预订，什么时候可以预订，什么情况会阻止预订，以及未签到后会发生什么。把例外情况放在相关规则旁边，不要放进另一份单独的文档。

Koder.ai 的规划模式可以在开发开始前梳理这些流程。在聊天中描述会议室和工位预订应用，加入规则和测试用例，然后创建第一个小版本，包括资源列表、可用性日历、预订表单、签到操作和冲突提示。在添加管理员控制项或报告前，先用示例用户测试它。