案例思考001·会议室预订时段颗粒度
二O二二年·案例思考·第壹篇
互耕社群以免费形态重新启动了，但我一直没想好写点什么来作为2022年的开篇，
恰巧不巧，一位朋友的事给了我灵感。
事情的起因是这样的，他们公司要做一个会议管理子系统融入OA，
在设计会议室预订时段的颗粒度时，内部出现了一些分歧；
A认为：
最小颗粒度不必设置，就给个时间选择器，让用户自行选择即可
B认为：
如果按照这种做法，会导致用户不知道哪个时间段已被占用以致频繁报错，非常不友好。
应当设定一个最小颗粒度为时段，在视觉上才好把占用时段和非占用时段展示给用户。
就此展开了一场讨论~
（一）
A认为：
最小颗粒度怎么设置都不合理，让用户选择最好；
B认为：
会议室预订的最小颗粒度大多数都为30分钟，所以30分钟就最为合理；
A反驳：
认为B陷入了自我参考设计的陷阱，有时会议可能是10分钟，那么另外的20分钟就会被浪费。
所以应该先让用户自由的用时间选择器用起来，可能频繁报错不友好。
但一段时间后就能得出数据，先可用再好用，就能知道适合自己公司的最小颗粒度是多少。
或者至少也应该找找公司的历史会议来确定适合的时段。
B反驳：
正式的会议一定是30分钟以上，这不需要去调研，也不需要查什么历史会议。
10分钟的会议根本没必要在线上预订，在微信群或者抽支烟就沟通好了，自上而下传达就可。
A再次认为B是陷入了自我参考设计的陷阱：
在A的工作经历中，30分钟以内的会议也是常见的，这个“一定”是不科学的，没有依据支撑的。
B反驳：
如果是颗粒度再低，比如15分钟，设计上也一定不会友好。
把时间选择器换成时段选择器本身就是为了方便，
如果颗粒度太低反而变成了不方便，这个优化就失去了意义；
如果让你来评价，他们谁对谁错呢，争论的原由在哪里，怎么才能很简单的消解他们之间的争论呢；
（二）
其实会议室预订系统早就不是新奇的东西了，而我们遇到的问题，前人遇到的也不会少；
随手一搜就搜索到一篇文章
详尽的说明了经过数据验证和实际访谈得出的一些结论和最终实施的方案：
图：来自58UXD公众号，已经许可使用
如上图，通过数据和访谈表明，容易出现在两种场景：
1.预订后因各种原因没有进行
（预订30分钟，但没有如期进行，下一批会议成员却只能预订下一个半小时）
2.提前结束没有主动释放的会议
（通过数据发现员工预订会议室一般在120分钟，但实际使用时间不足60分钟的占比40%）
（三）
我们通过数据很容易发现，A的方案是错误的；
1.让用户自行选择时段，以免时间被浪费是很理想化的。
实际上预订会议都会预留出一些时间，只会让时间更长，而不会低于预期时间。
以不浪费时间为目标却反而会造成更多的浪费。
妄图在没有制度或者其他奖惩措施的情况下想让用户满足这种理想，
无异于自助餐厅不执行剩余收费还想让客户按照食量打餐
（但就这还是在有浪费可耻的公认道德约束下也做不到的）；
但B的方案也是错误的；
确实如A所言，B陷入了自我参考设计的陷阱。
但也因为A描述的场景并不合适，通常预订会议确实会超过半小时。
但由于A的实际经历让他觉得，低于半小时的会议也很多。
实际上是因为原因2：会议时间总是低于预期或者预设时间导致的提前结束；
所以最大的问题不在于最小颗粒度的设置，
而在于假如会议室在数据上被占用，但实际上无人使用的，怎么处理。
58UXD这篇文章已经给出了答案和详尽的方案
1.用户主动释放 2.其他用户可以抢占
那么颗粒度是不是问题呢，也一定是的。
但由于这是本公司内部开发的系统，所以实际颗粒度确实如A所说，需要结合公司会议的实际情况来决定。
但倒也不必把一个体验极差的时间选择器丢给公司去实验。
用户访谈才是最合适的，结合会议资料分析便可以得出很好的结果，
这样如果后续数据表明确实还有优化空间也不会太严重的影响第一版本的体验；
—————————————————————————————————————————
总结：
1.尽量思考多的场景，举例要举让人信服的例子；
2.对于不知道的东西，哪怕很简单，也要怀疑一下，不要陷入自我参考的陷阱；
3.不要照搬，要结合实际情况，做产品跟做项目是有区别的；
4.先可用再好用是可以的，但请注意，可用指的是不难用，不是不好用；
5.试错是对的，但不要什么简单的问题都需要试错，研究方法不只数据埋点分析，
历史资料和访谈问卷都是极好的，特别对于项目性质的产品而言；
6.做一个产品前先看看竞品，遇到问题时看看竞品如何解决
（包括设计问题如15分钟为颗粒度在58UXD那篇中也是实验过可行的）
哪有那么多创新，大家都只是在同质化严重的情况下找噱头争夺市场罢了；
留下一个思考：
假如该公司还要融入一套访客系统，受访员工可以为客户的访问预订会议室，在没有专属的客户接待室的情况下。
该如何让这两个系统不出现互斥呢？
