在过去的一次产品设计中无意间踩到了前人挖下的坑，具体情况如下：
在做的业务是在线问诊，顾名思义就是在网络上看病，具体应用场景：患者张三在线预约医生李四，预约时间点一起上线，通过图文或者视频进行交流，医生边沟通边记录病人病情，最后为患者开具处方单（包括初步诊断，处理意见和药品）。
首先，移动端已上线的整体设计思路是医生只有完成当前病人诊断才能诊断下一位病人，完成诊断是以是否开具处方为标示（开完处方就直接把本次记录置为结束并且将视频中断，这样就能诊断下一个病人，未开处方则置为未完成状态）。而我在web端设计过程中，为了匹配线下的就诊场景（医生一边与患者面对面沟通病情，一边会在电脑或者病历本上记录病情，填写诊断），因此特意在视频过程中加入了开处方的切换入口，开完处方还能与患者作进一步的沟通，以视频结束和已开具处方两个结合来判断当前诊断是否完成。
但是技术反馈偏离之前的移动端设计，老的设计的初衷是方便程序控制，不会出现问题；而如果改成我的实现方式，则需要将重新考虑这个业务流程和异常情况，比如处方开完了，医生突然关闭了浏览器，这样就需要定时任务去轮询是否视频中断（如果中断，则将该诊疗记录置为结束）。但是我们都知道定时任务还是有点不靠谱，存在隐患。这个隐患是会导致医生后面更大的不方便（因为一个病人没有结束诊断是不支持看下一个病人的）。
很多时候一个人思考的时候是会将问题极端化，比如说我：问题来了，提升体验，预留隐患还是直接牺牲体验。如果是提升体验，则需要修改流程，重新考虑异常流程；如果是牺牲体验，则走老路即可。后来想了想，看问题也许过于极端了，是否存在新的排列组合，有更优的业务流程呢？
视频，文字，语音，图片都只是沟通的手段，不能作为诊断的结束。移动端将开处方作为诊断的结束，抛开客户端（web，h5，app）的区别，但是沟通还在进行，这不冲突而且也符合线下的就诊场景。于是就找到了第三种方式，诊断还是以开具处方为标示，而不需要考虑视频，语音是否结束。这样做的好处就是医生未患者开完药品之后，如果患者有问题还能继续沟通，而不是掐死这条路子。
末了，视频，语音，图文并不等于问诊，而是沟通的手段，处方只是沟通的其中一个环节罢了。最重要的是在产品设计中遇到的缺陷或者漏洞是去解决的，而不是被吓跑的。
