2023年还在上一个团队，当时有一个产品设计，大胆抄袭了企业微信，把它的日程待办搬了过来。
业务背景如下：
为了给采购人员提供工具支撑采购业务跟进，第一采购订单创建之后的审核、报出、确认，方便采购人员跟进自己负责订单的审核情况、报出情况、供应商回复确认情况，确保订单的有效及时报出。也清晰看到已经完成订单的占比情况；
第二是发货的跟进，关注迟迟待发货的订单、等待门店收货的发货单，可以及时催供应商发货、跟进门店收货，监控门店异常收货。
功能层面终于上了心心念念的日历看板，采购业务产品本身也有较强的时效性诉求，特别是如今零售流通行业对于供应链效率要求越来越高的时代。
曾经一度也在纠结满足这个业务诉求到底用一种什么呈现才好，那种带有巨强时间属性的产品（比如：机票、酒店这种严格分布在时间线上产品）放在日历的维度是天然成立的，因为用户有心理预期就是对于基于时间的需求（我要哪天住酒店，我要哪天飞，我要哪天出去旅游）。
而这次对于采购链路的跟单过程也采用日历看板模式，则是将原来的一维信息升维处理，需要用户大脑对于一维信息的处理过程，在经过简单的组装之后二维呈现在看板上，让用户获取信息时大脑减少思考过程，达到的结果就是让用户觉得自然的发生。用户的业务数据采集过程，完成了对于业务闭环的数据沉淀，然后自然的享受数据带来的价值，提升驾驭感，这个时候用户不再只是数据的投喂工角色、同时也是数据的驾驭者。
这次产品引用的主要是：日历看板+待办，日历看板由用户投喂的订单、发货数据编织而成，待办由系统自动策略+用户添加组成，提醒落位到不同的日历天，用户需要做的就是在平铺的时间线上进行常规的数据投喂，然后让一切自然发生，处理当天待办、识别分析异常、采取业务动作。
产品设计过程中思路、交互、甚至视觉方案借鉴参考有什么大碍呢？
当然，我们构建产品的过程并不能从它处作为起点，最多只是参考信息而已。自己产品的构建过程一定是从自己的业务、用户、商业目标中生长构建出来的，我们要满足的是自己用户的目标、业务目标、商业目标。
上述的方案其实只完成了第一步，即底层跟办的数据、逻辑模型搭建，最多算是到达了框架层而已，表现层的空间还有很大，产品也在持续的优化演进之中。
