一次失败的slack抄袭经历

去年年底，笔者曾经作为交互设计师参与过某个slack-like产品的设计当中。因为最后该项目被全盘推翻并且笔者在后期因为项目变动离开该项目组，所以特意把项目过程中的一些教训写出来告诫后来人。

#人人都是产品经理

每个人对于产品都有自己的理解但是并不是每个人都应该主导产品设计。在产品设计阶段的早期因为实际的决策者并不是直接管理的产品经理而且直接决策者（估计因为时间不足）也没有留下任何系统性的文档（比如竞品研究 思路阐述等等）并匆匆开工导致后面许多问题的出现和决策都处于扯皮状态。后面接手的产品经理一方面并不一定理解和认可先前的决策，同事也因为制度不周全而要同时监管多个项目而无暇思索，导致早期产品设计一团糟。

产品设计一团糟的表现通常为产品理念不清晰以及逻辑问题以及对异常状态处理机制的思考不周，比如群组被删除后相关文件怎么办以及群组内的文件被分享出去后和该群组的关系等等。这种设计上的混乱倘若加上多平台不同的限制和接口上的设计问题在项目中期很容易成为一团乱麻。后期产品经理尝试思索并且解决这些问题，然而他并没有通过很好的方式共享他思索的成果和判断依据。导致在中后期依然为了同样的问题研发、设计、产品依然始终在兜圈。遗憾的是，相似的功能由于在某些版本（比如web）上线，导致某些领导对此有特殊的理解（这些理解可能基于经验也很可能是随便一说）导致有问题的设计不能及时纠正或是重新理清。

参与产品设计讨论的每个参与者可能都有项目管理工具与通讯工具的使用体验和角度，这些经验会让他们会产品本身提出许多可能有益的建议。问题是当每个人都可以用自己的体验说事或是企图把一切都推给迅速上线后等数据验证而放弃充分的思考，那么如何衡量功能点的设计目标以及是否达成目标甚至是改进方向就成为了问题。“国情”和“用户体验”在没有经过审视的情况下容易变成幌子，为一个产品揉入一堆无法互相配合甚至是互相冲突的功能。同时由于这群功能都可能有着先天残缺（因为也很可能和别的残缺的功能混在一起成为更大的模块），导致后期产品经理很容易得出一个结论——这个产品看着还好但是小毛病很多。

——磨刀不误砍柴功，不要充忙进入开发阶段

——团队知识要共享，否则团队根本没有共识...

——盲目的敏捷开发容易导致产品全盘推倒重来

——产品经理对于产品的全面思考很重要

—— 用户体验/敏捷开发/数据说事/国情…每个人都会说这些词....但是绝大多数人也仅仅会说

#国情问题

作为slack-like的一款产品，很容易在国内碰到一个问题——国内外企业市场的特性很不同。slack是一款针对有着扁平管理结构的小型团队的产品。遗憾的是，在我所经历的项目当中，有一种试图把slack-like产品改造成适用于大中型企业产品的倾向（每个设计都会先被质疑在某些极端情况下怎么办的困境）与另外一种简单按照slack先做不要自己瞎想的倾向（表现在从高层到产品经理都会这样说，即便他们先前要求产品某些特性必须适合中国特色非扁平化大型团队的需求）。这两者倾向中的冲突，既代表着对国内企业市场的认知上不够清晰更意味着产品定位不明。

从某种意义而言，slack既是项目管理工具也是一种im和邮件这种通讯工具的变体。在国内试图仿效这个独特的产品，可能需要对需要切入的企业市场有着明确的认知。试图从沟通工具上切入（比如开发那些大团队更需要的高级的沟通功能（视频会议））与从项目管理上切入（如 oa，投票，任务管理等简单管理功能）完全不是一回事。两者都意味着大量的时间人力物力投入与产品设计倾向。就如针对会话列表功能，如果更偏向于沟通工具那么通讯录以及对于聊天的管理（starred/mute/search）都会极为重要与此同时产品也会更可能基于群组与人与人之间的对话。如果倾向于项目管理，那么会话列表可能会基于项目，人与人之间的沟通只是作为补充而存在。基于不同切入点的基准上，对于国内市场不同的理解和期望会极大的影响产品的设计成果。如果偏向于im，那么整个产品设计都会倾向于用rtx，企业qq作为参照对象，如果偏向于项目管理工具，那么如tower/jira等工具也很容易进入产品的参照范围。最坏的情况可能是试图完整兼备通讯工具与项目管理两个特性，也希望涵盖中国特色的大中小团队不同的需求的宏大产品愿景。这种情况下通常leader们今天看的是项目管理软件明天看得是微信后天或许看上了别的什么，简而言之因为产品特性的跨界而带来的什么都想学什么都想要。

——国内外不同市场的特性有所不同，盲目仿效国外产品前必须想清楚。

——对于跨界产品的把握并不那么容易，从产品到细节都是如此。

——如果一开始就试图涵盖全部场景，那么最终很可能疲于奔命。

#事情不会自动变好

作为一名交互设计师，在这个slack-like产品的设计过程中时常感受到无奈与无力感。其一是因为方案不断在变动而且时间极为紧迫缺乏足够时间去打磨方案（具体表现为例如产品方向以及最终从初步交互方案到最终产品评审后整个方案都几乎推倒重来，但是deadline几乎不变）。同时，也因为因为种种原因对于每个细节都出于想太多（照顾极端情况以及尽量使用简陋的控件）以及想太少（对于具体每个细节之间的展现方式的思索）之间。再者，产品经理表现出希望尽量减少研发的工作量，但是要求设计出一切都简单使用系统控件但是交互体验上有如那些小而美有着丰富动效和精致控件的方案。

以上的问题都仅仅是表面现象，这些问题指向另外一个核心问题——一个产品的初期作为设计师应该把时间投入到什么方向。个人认为，多数产品的初期都应该专注于其核心场景以争取核心用户而不是简陋的搭建一个吸引不了任何用户的“大局”。具体对设计而言，如其一开始就考虑各种极端状况（比如人多组织多的大公司/有着极端权限管理需求的公司/比如坚韧不拔喜欢1024分辨率的企业），倒不如基于更实际的场景进行设计。同时，在早期就开始有必要对基本控件和布局关系进行思考并且如实记录以免日后忘却这些思考。当然，这些思考本身必须最终化为有着中等保真度（层次重点准确，尺寸恰当并且充分考虑异常状况的原型）以及相关的笔记。简而言之，个人倾向于仔细做好有限的内容（甚至多出几个版本）也优于后期功能堆积导致的崩盘或推倒重来。

或许有些人会认为，一开始应该尽快搭建一个宏大的框架方便视觉设计师尽快输出（凡是一开始就想着直接出视觉图的都太自信）。同时一开始也应该覆盖尽可能多的功能——反正日后都会改好的。遗憾的是，事情不会自动变好反而很容易滑坡。因为产品经理在后期更倾向于拓展功能而非抽出时间给设计和研发重构某些细节。一个具有缺陷的设计，可能日后会连累其他设计，具体体现为糟糕的控件被多次复以及简陋的布局导致无法塞入更多内容。

——自然而然的等着日后某个时间的重构可能是自我安慰罢了

——在设计上投入更多的时间（从思考到原型呈现以及文档记录）