不知道大家在做产品设计时有时候会不会和我一样，一个很简单的功能却给忽略了，或者一个很常规的应用点视而不见，等提交技术开发后才发现少了一点给开发带来了很多困扰，于是不得不一遍遍地和开发进行沟通与解疑。
后来发现大部分沟通都是无用的，既阻碍了开发的整体思考和持续开发，也打断自己的手头工作。真正有效的沟通个人觉得在两个时间点最合适，开发前和开发后，开发前需要沟通这个产品的整体思路以及未来存在的拓展性，开发后验证产品的思路，再一次进行沟通，补缺。开发过程中的沟通往往都是对产品设计中的答疑，如果产品设计的能更完善一点，这种可有可无的沟通定会减少许多。
增删查改显算传，产品设计的七字真言，也是产品经理的基本功。
增：数据会增加到怎样的一个量，当这些量增加到一定程度时页面需要怎样的表现形式。拿新浪微博的实时刷新来说，当微博条数持续增加，我们是按微博数量来固定分页，还是按照页面的长度来分页，还是根本就不用分页，持续的刷新下去，抑或是刷新和分页并存。
删：这个也是常规性操作，既然数据有增加，就会有删除的需求，哪些数据可以删，哪些不能删，删完之后数据会呈现怎么样形态等。
查：这是快速获得信息的一种方式，从繁杂的数据排列中准确定位出用户想知道的结果，通常会有好几种查询方式及查询条件，不管是哪种都要表现出来。
改：可分为两种来表现，一是用户对原有数据的修改，哪些可以哪些不可以，可以修改哪些元素，哪些元素一旦确定将不提供修改等；二是对设计的修改程序实现的方式，从一种方式更改为另一种方式程序是否易于实现。
一般来说产品经理做到以上四点就能把原型做的非常完善，假如数据做成了列表样式，是否考虑到了分页？是否需要排序？排序的话按什么条件进行？排序满足不了需要的话是否需要搜索框？查询框？查看详细列表的打开方式是怎样的？本页操作还是新窗口操作？跳转之后需不需要跳回来？选择数据支持单选还是多选？单选的话用下拉还是radio？如此等等细节交待的越清楚，和开发的沟通越少。
显：数据的显示，根据需要做哪些显示，显示的方式是怎么样的，不同用户的权限是否一样，不一样的话数据如何表现。这里的表现的是背后逻辑。
算：指计算规则，比如热门文章=点击数*1+评论数*2+分享数*3诸如此类的背后计算的数值。此类规则约定之后可以节约很多时间。
传：数据的传递，不同服务器之间的数据传递，考虑到用户体验的时候ajax的传递，还有一些api的数值传递等等。
每当在做产品设计的时候都在心里默念这七个字，基本上设计出来的产品功能点全能涵盖到，省去了开发中的许多不必要的沟通与交流。一般产品经理做到前四项就差不多了，后三项应该属于提升性能力。
当然这只是产品设计中的方法论，基本功，最重要的还是对产品方向的把握，对产品需求的清晰认识以及对市场的敏感感知。
