最近在做的项目中有一个小功能——对单据的全局操作，如打印、分享、转发、关注、收藏等十几种操作。
不同场景下显示的操作不同。操作多了，自然需要根据频率、重要程度等给一个显示优先级顺序。我把这十几种操作放到一起的时候，发现有几个操作从字面上看非常相似，如“分享”和“转发”，“收藏”和“关注”。
这几个名词有何不同？
从字面上严格的说，的确不一样。分别如下：
分享/share：可用于不同端、不同应用之间，比如把淘宝网上的商品分享给微信好友
转发/forward：用于同一应用中，比如把微信消息转发给其他人
收藏/favorite/collect：主要目的是收到一个固定的地方，方便后面翻看，收藏的内容可能不会再更新
关注/follow：关注的是未来动态的更新变化
实际项目中怎么用的？
当然在实际项目中，这几个操作对应的功能也是完全不同。分别如下：
❤️分享：将单据分享到IM聊天窗口（可监测记录到），聊天窗口的二次分享无法被单据监测记录到。
❤️转发：转发是在单据上完成的，可将转发、评论等内容记录在单据上，二次转发也会被监测记录，具有更高的安全性和更正式。
❤️收藏：针对已经完成的不再流转的单据。
❤️关注：针对流转中的单据，单据的流转变化会产生通知。
有必要做成不同的功能吗？
用户在浏览信息时看到两个相近的操作，需要思考、尝试，操作成功之后也不可能形成记忆，下次还是需要再试错。对于轻量级功能来说，是不友好的。
可以怎么做？
🍃优化方向一：将两个类似功能进行合并，把一个功能升级，这样减轻了用户的认知成本，同时可以减轻开发人员的功能维护成本。如上面项目中，收藏功能其实可以放到关注中，分享功能可以升级实现转发功能中的有迹可循的功能。
🍃优化方向二：可以换一个概念，如上面项目中，把转发功能，换成意见记录等概念。
思考
🤔当然，B端产品的改动都需要很谨慎，最好的方案是在设计前就做好规划，否则对已有功能的稍微改动都可能带来一大堆客户的投诉。
在这次项目中，因为担心改动成本更高，最初产品经理采用了小风险的方案，即同时使用4个不同的概念。中间发生了几次波折，首先是作为UE的我，提出了方案的不合理性，PM坚持；之后开发觉得方案不合理，PM坚持；上线前，UE和开发依旧觉得方案不合理，于是上升到项目的master，重新评估方案。最后的结果，方案不合理不可上线。
在这个过程中，看起来仿佛设计、开发的工作内容都白做了。但是：衡量一个设计师的工作量，不单单是看他输出了什么。设计师pass掉一个不合理的需求，阻止了功能的上线，虽没输出产物，但让产品体验更好了，减少了测试、后期的维护。这难道不是更有价值的吗？
网友评论