01 遇到的问题
“不是在开会中，就是在开会的路上”这是大部分职场人士，特别是作为产品经理的我们的真实写照，那么，在约会或赴约过程中的你，是否遇到过以下类似的经历：
- 会议发起人，在根据会议计划创建会议邀请前，不知道受邀人是否有时间参与或没有受邀人请确认好时间，盲目发出邀请。这样就可能会出现受邀人无法参加会议的情况，如受邀人无法参与会议且及时反馈原因，发起人还可以根据反馈结果及时调整会议，但如果受邀人没有及时反馈问题，就会造成到了会议会议时间，发起人一个人坐在会议室，迟迟等不到受邀人的情况，此时再去调整会议计划，必将会议影响会议目标的达成。
- 会议发起人，发出会邀请后，由于某些原因临时取消或变更了会议，没有及时在会议管理应用上更新会议信息，由于会议室在系统信息仍是被占用中，导致其它用户在计划会议时间范围内无会议室可约。
02 场景分析
汪童学，因某个需求需要与需求方进行会议讨论，参会的人员包括需求提出方和需求涉及到的上下游业务负责人，共计8人。由于会议需要对需求进行分析讨论，会议是需要有投影仪、白板或者智能会议平板，基于可用的会议室资源，最终通过会议管理应用发起了会议邀请，会议时间为：明天14:30——15:30结束，会议室在5楼521。
由于汪童学在选择邀请参会人员时，人员列表仅提供了姓名和、头像信息，没有提供被邀请者的在计划会议时间内是否有其它会议或工作安排，所以发起出邀请后，可能会出现受邀人的日程安排与计划会议时间冲突的情况。例如：在发出会议邀请之后，贺同学反馈，在14：30—15：30时段有其它重要会议要参加；陈童学安排了外出拜访工作，无法参加会议；于童学反馈调休无法参加会议。
汪童学提前约了今天下午2:30的会议，由于汪童学不了解预约的会议的室是否在有还未结束会的会室，临近会议开始时间，汪童学与其他受邀人到达会议室门口时发现上一场会议仍在进行，为了让会议正常进行，汪童学临时找了另外一个会议室。
以上场景阐述了，“约会”的不同节点可能存在的问题，而导致问题发生的主要原因可以总结为两点：
- 发起人、参与人、会议室三者之间信息的不对称。 例如：“问题1”出现的原因，主要是因为发起人、参与人、会议室三者之间信息的不对称，发起人在选择参与人时，不知道参与人当前工作状态是什么，日程安排的时间与计划会议时间是否存在冲突，如在产品设计上，为发起人提供受邀人的工作状态、日程安排等信息，同时在会议发起人发出会议邀请之后，基于受邀人的角色设计邀请确认反馈机制，就可以在一定程度上避免的问题的出现。
- 产品流设计未实现闭环。 例如：“问题2”出现，就是因为产品设计上对会议是否真的开始、是否在仍 在进行，没有设计相关的确认机制，导致会议其实提前结束或已经取消，但会议室在系统信息中还是被占用中。
1. 信息优化
会议是一种有组织、有领导、有目的，在限制定的时间和地点，按照一定的议事程序进行的议事活动。在约会前，发起人需要了解在计划会议时间范围内参与者是否可以参与、是否有符合要求的会议室可用、会议室的设备配置是否能满足会议需求等信息，才能快速并准确的按计划完成“约会”动作。
所以预约会议的过程，其实是对人、会议室、时间三个要素（发起人，会议计划，包括时间、主题等；参与者：工作状态、日程安排等；会议室，会议室的位置、空间、设备、时间等信息）的进行匹配过程，要解决三要素匹配过程中信息不对称的问题，就需要在产品设计中针对三要素信息进行优化设计。
例如：从发起人的角度，为发起人提供被邀请者的日程信息；从被邀请者的角度，提供日程管理工具；为发起人和被邀请者提供沟通的渠道。
2. 流程优化
流程用于描述事情进行或事物发展所经过的程序，任何事物都有它的流程，例如吃东西时需要经过投送、张嘴、咀嚼或吞咽等程序。会议也不例外，会议从开始到结束，是一个过程。
到了会议开始或结束时间，会议是否真的开始？会议是否正在或仍在进行中？从流程的角度来看，针对以上问题要给出明确的答案，就需要从发出会议邀请起到会议开始、进行、结束关键节点，做好流程的设计的与控制。
例如，在到了会议开始时间的前后，利用应用内的推送信息，提醒发起人及时确认会议是否开始，如在一定时间阀值内，发起人仍没有确认开始会议，则自动取消会议。如此，不仅从系统信息中获取会议进行的状态信息，还可以为会议行为分析提供数据支撑。
03 优化设计
1. 参与者
对发起人而言，拟邀请的参与者是否有时间参与会议，直接影响会议是否能按计划执行，如果系统不能尽可能为发起人提供拟邀请参与者的工作状态、日程安排等信息，发起人只能盲目发出邀请。
现状：
选择成员列表，成员列表只展示头像、姓名等信息，发起人根据成员列表提供的信息无法知道成员的当前工作状态是什么，有没有其它日程安排，导致选择的过程是盲目的，那么选择的结果与会议计划的存在冲突的可能性就会变大。
优化：
信息优化：由于用户的上下班打卡、工作沟通、日程管理都是基于KS APP进行的，所以在优化方案中，除了在选择成员列表展示头像、姓名等基础信息，还为发起人提供了成员的工作状态、会议安排、同步日程等信息，在一定程度上解决发起人与参与人信息不对称的问题，发起人在选择成员可以根据成员的工作状态信息双向动态调整会议计划。
2. 会议室
对于线下会议而言，会议室是必不可少的空间，会议室的可用时间与会议计划时间是否匹配，会议室的空间是否可以容纳参会人员，会议室配备的设备是否满足会议需求，这些都直接或间接影响会议是否能按计划举行。
现状：
会议室列表向发起人提供了会议的位置、可容纳人数、会议室设备、会议室状态信息。但其中会议室状态，仅以状态标签形式告诉发起人会议室的状态，具体哪个时段可用，发起人需要进入会议室二级页面查看；
如用户进行二级页面后，发现会议室的可用时间段与会议计划时间不匹配，用户需要返回列表页面，重新选择并查看其它会议的详细信息，这样的设计，不仅影响用户体验，还会影响发起人选择会议室过程的效率和结果。
优化：
在选择会议室的过程中，会议室的位置、状态、可约时间、设备等信息对于发起人而言是优先级较高的信息，针对现状优化方案做了以下处理：
- 会议室列表排序：根据会议室剩余可约的时间进行倒序排序，从时间维度优先将剩余可约时间段更多的会议室推荐给用户。
- 将会议室的“生命线”通过时间轴的形式展示给用户，数字代表时间、橙色代表已约的时间段、绿色代表可约的时间，发起人在会议列表层级页面就可以明确认知道会议室当前的状态是什么、哪些时段已经被约，哪些时段可以约，可以更快、更准确的选择符合计划的会议室。
3. 会议过程管控
会议时间到 了，则到代表会议自动开始了，会议时间结束了，则代表会议会议自动结束了，那么会议是否真的开始、是否仍在进行中，从系统信息中无法得知，直接导致人（会议参与人）的信息和会议室的信息，在系统信息中得不到及时更新。例如：会议实际没有开始，但是发起人没有在会议管理应用中取消会议，真正需要会议的用户到线下确认之后，才知道有会议室可用。
基于以上现状，从发起人、参与者的角度，分别针对会议开会、进行、结束等进行了如下优化设计：
（1）发起人
确认开始：从发起人的角度，在会议开始前几分钟，利用KS应用内消息推送，提醒发起人确认会议是否开始，从流程提供确认机制，以确认会议是否真的开始，会议室资源是否真的投入使用。
取消：如果因某些原因，需要取消会议，用户可以通过取消功能及时取消会议，以及时更新会议信息并释放会议室资源。
创建群聊：基于发起人的用户角色，为用户提供快速“创建群聊”的功能，用户点击创建群聊，系统可以自动根据会议主题和人员创建群，方便参会相关人员在会前、中、后讨论并同步信息。
延时：在会议即将结束前的一段时间，发送消息推送，提醒发起人是否需要延长会议时间，如需要延长时间，则可以通过延长时间功能，延长会议时间，避免会议冲突的问题。
结束：在到了会议结束时间之后，发送消息推送，提醒发起人及时确认会议是否结束，以及时更新会议状态和会议室的使用状态。
（2）参与者
在发起人发出会议邀请之后，推送系统信息，引导参与者及时确认是否接受邀请，只有接受会议的参与者达到一定比例或全部接受，则意味着会议成行，推送时间、循环次数、比例可根据需求灵当配置；如因为时间冲突，无法参加会议，可以利用拒绝功能反馈拒绝原因和可以参加会议的时间。
04 反思
从用户体验五要素的角度来看，产品设计上实际上是对产品战略、范围、结构、框架、表现的设计。本文案例从信息、交互、流程的角度对现会议管理应用进行优化，基于此总结以下两点：
- 在产品设计中，对信息的处理需要从用户、场景出发，对信息的优先级和聚合尽量做“最优”处理。
- 流程是产品的经络，一通则百通，在产品设计中，要尽量从全局上做到流程 的闭环，不要像本文中的案例只看见“约会”，却看不见发起约会后的事。