之前一直在探索一款阿里大数据产品的品牌设计及官网改版设计，反复试了很多次，效果都不理想。最近终于有了一些眉目，也算是对自己过去的努力有了部分交代。
对于一个从0到1、结构复杂、全新模式、没有竞品的产品来说，无论做什么都是一个探索和试错的过程，但我想在这个过程中积累的心得及总结，可以适用于其它各种产品，毕竟绝大多数的产品都没有我们现在在做的这么复杂和具有突破性。
之前试错的过程中，总是在专业方法上较劲：效果不理想，就探索方法；方法改善后自然会出现不同的结果，如果结果比之前的好，就证明新的方法更有效。但慢慢 的我发现，这种努力虽然有一定效果，但不能彻底解决问题：因为效果好与不好只是自己在某一个时刻的观念，这个观念会随着时间的推移逐渐变化。比如对一个设 计结果，我今天很满意，也许过了几个月觉得是垃圾。不是因为我善变，而是因为我对产品、对设计的理解不一样了。如果设计师只专注专业的方法论建设，而忽视 对产品持续的、渐入式的学习和理解，他会发现自己的变化永远赶不上老板的变化：之前老板不是认可这个方案了吗，怎么今天又变了？他是不是神经病啊。
所以方法论只是起到一个基本的辅助作用，更多的要依靠自身悟性、对产品的理解等。就好像学习语言一开始是依靠单词、语法和句式等，到后面就需要深入理解当地的文化、习俗等才可能逐渐融入。
最可怕的是：自认为的“理解”并不一定是真正的理解，思维定势及竞品分析可能是你理解产品的大敌。
避免被动——警惕思维定势及竞品分析
我们都知道要从整体理解产品，但什么是真正的“整体”？我以前觉得不过度关注某个功能、界面，而是从产品角度看问题就可以，而“产品”这个边界其实是模糊的。比如我们现在在做的产品 Y 有两个关联子产品 Z 和 M，这两个产品差别很大，由不同的产品经理分 别负责。所有人都把 Z 和 M 看作两件不同的事情区别对待，我也没能避免，甚至在设计 Y 官网文案时让不同的人分别负责 Z 和 M 的文案。而当我改变思路，从整体去描述 Y、Z、M关系的时候，我发现一切问题迎刃而解。所以在大家都遵循惯性思维的时候，你能不能不受影响，清醒的保持从整体看问题，这其实很难。
当然，如果再高一个层次，我还应该不仅从产品 Y 的角度看问题，还要从阿里系面向同类客户的所有产品角度总体看问题：看 Y 在其中所处的位置；在集团相关战略中的位置；如何和相关产品更好的合作，共同服务好客户；如何为集团带来更大的价值等等。如果再高一个层次呢？再再高一个 层次呢？那么无非就是从全国看到世界，从同行业看到相关行业，最后再到政治、经济、哲学等等……总之视野的高度是没有上限的。
二、“分析”而非跟随——不要被行业产品带偏
最开始的时候，我们对行业产品不够了解，对自身产品的理解也有限，不知道产品应该设计成什么样子，所以就觉得要多看看同行业的产品是怎么做的。当时看了好 多相关的行业产品，它们确实有一定共性，但个性的部分却是难以分析的。最后我们根据严密的分析结果，设计出了一个具有行业共性，但较平庸的保守设计。
我一直在反思为什么没能达到理想效果，我怀疑是不是之前的方法用的不够正确。而现在，当我对产品有了更新、更深的认识时，我认为已经没有必要再思考分析方法了，因为产品完全就在我的心中，我清醒的知道了设计方向，也不会再被行业产品牵着走。
当然我并不提倡完全不做任何分析，因为知己知彼，才能百战百胜。只是不建议做过度的分析，只要点到为止即可，更重要的是深刻理解产品，才能最终得出超出预期的设计。记得之前看过一本很好的书《交互设计沉思录》，里面也提到不要太过依赖竞品分析，这样会影响自己对产品的判断，从而失去创新机会。
你一定会好奇，我是如何从对产品的普通理解上升到对产品更深层次的理解的。
一、多和项目成员沟通
我们的项目比较复杂，产品经理＋运营有 十几个人，而我又是一个比较内向、不喜欢打扰别人的人，所以我以前习惯于管大家要各种项目ppt或文档资料，实在没办法了再去问，并且我总会这样暗示自 己：这个问题估计他也不知道；问这个没什么用吧……现在，我会消灭一切假设，不管结果怎么样，先问了再说。我也发现，虽然大家都很忙，但其实大家都很喜欢 互相沟通，不存在打扰的问题。所以现在，我会尽量定期和所有项目相关人员同步进展，这对我全面理解产品有很大的帮助。
二、多和leader级别的人沟通
leader的优点就是他们对产品会有更高层面的理解，并且经常会给你很好的指引和灵感。不过找leader沟通要注意有备而来，比如展示你目前的进展、 存在的问题，希望得到什么建议之类的。但要注意，leader说的未必全对，而且他们一般会给出一个大方向而不是具体细节，更多的是起到一个抛砖引玉的作 用。把leader的话当作参考、建议即可，千万不要机械遵从，这样就失去了沟通的意义。
三、结构化的输出
以前在阐述产品时，觉得能用一句话说清楚产品的目标人群、产品是做什么的（有什么重要功能）、特色是什么，就已经很不错了。而在描述一个复杂的企业级产品 时，这个要求是远远不够的。最好能用一幅图，系统的说明产品的组织、运作方式，在这个过程中能帮客户解决什么问题。比如我们是一个大数据产品，那就要从产 品整体角度解释清楚源头（数据源、数据融合方式）、运作（产品如何组织、分工，如何处理数据）、输出（数据最后以什么形式输出，到了哪里），不同类型的客 户如何使用以及最后帮助客户解决了什么场景下的什么业务问题。以前我画过很多类似的图，但是当时一是没有从产品整体考虑（更多的是从子产品角度考虑）；二 是没有结构化的输出（虽然也考虑了源头、运作、输出、客户使用场景等，但基本都是分别描述），所以效果并不好。
