上一篇文章讲的PC端产品的两个重点讲的比较大，这一篇关于PC端产品的设计经验分享就会比较细一点。
本篇文章主要是按照产品设计流程去详细聊聊个人认为的做好PC端产品细节中比较重要的三点。
1，需求整理
社区产品其实从产品架构上来说都差不多，社区产品之间的不同之处大多是因为公司的业务，资源和发展方向的不同而带来的。所以很多需求是来自于业务方，我们这边基本上就是运营同事了。产品经理在接收业务方的需求时一般听到的是：我们现在需要一个***功能，这个地方的流程是这样的，这个地方做一些限制就好了。此时产品经理需要做的是有两个：第一是弄清楚业务方的底层需求，他背后的最终目的到底是什么，目的是不能直接被业务方想要的流程带跑，很多时候他的需求换个设计实现会更好；第二是弄清楚他现在想做的功能的所有场景以及以后可能的发展方向，目的是为了将功能设计的灵活，可复用。举例：在做投票功能的时候，运营说明他需要在投票期间用户不能看投票结果，投票结束后才能看投票结果。如果直接按照他这个流程走开发直接写这一个逻辑就够了。但是考虑到运营如果以后想要投票期间看到投票结果怎么办，或者投票后为保护数据不想让用户看到最终结果怎么办。可不能每次发一个投票改一次代码吧，所以这个地方很自然就应该做成一个完整的可让运营组合选择的模块，投票期间选择能不能看，投票结束选择能不能看。为了做的更加完善，还可以选择一定的参与权限和查看权限。虽然这样做了让开发和测试很恼火，但是产品得扛住了，坚持做完善的产品。
2，功能设计
在把需求整理出来后应该对整个功能的流程比较清晰了，大概做成什么样子心里是有底了。复杂的功能可能需要先画个流程图，如果没那么复杂的功能就可以直接写文档和画原型了。写文档和画原型其实是可以相互补充的，很多时候文档写完了再去画原型就会发现自己遗漏一些东西，反之亦然。至于是先画原型还是先写文档就要看各自的习惯了，我更习惯于先画原型，然后把重点标注在原型上，这样在写文档的时候对着原型图可以尽可能的不落下任何一个字段，并且很多备注可以直接copy再补充一下就OK了。
PC端产品设计的不同主要是页面里的元素太多了，很多时候功能描述里两句话描述完功能流程，然后很大篇幅都是在写页面有哪些字段和操作。那怎样让文档更加清晰呢，还是按功能流程走。这个功能的主线是怎样的，比如投票模块，主线就是新建-页面展示。那在功能描述里就可以分为这两个大的模块，然后再去分别描述新建有哪些字段和操作，以及页面展示有哪些字段和操作。除了字段和操作需要详细描述之外，很重要的一点就是格外注意操作带来的影响。有些操作甚至会带来新的页面和字段。举例：投票模块是可以设置投票开始和结束时间的，先不说这两个字段之间的一些约束条件（比如开始时间必须早于结束时间），这两个时间的设置就会让页面出现好几种情况。其中最容易想到的就是“离投票结束还有*天*时*分”以及投票结束页面。很容易遗漏的就是离投票开始还有多久这样一个字段。为什么会遗漏，我自己反思了一下，可能常规我们接触和看到的就是这两类。所以在思考的时候要想清楚每一个可输入的操作可能带来的所有情况，仔细想想会带来的场景，仔细看看所存在的字段，这样会减少很多漏洞。
还有一点需要注意的，有些字段如果不是常规一定会出现的或者一定不会出现的，需要说清楚在其他地方是否会出现。举例：“投票”字段，本来我是直接放在题目前面打个中括号，意思就是说明是跟着投票贴的题目，目的是为了让用户一眼能区分是普通帖子还是投票贴。然后UI设计师为了更加好看，于是从标题里拿出来放在了帖子的最上方，相当于一个标识（我承认确实好看很多）。最后就是因为没说清楚这个字段是跟着帖子标题的，于是在其他列表里，比如消息和通知之类的，前端就没有做投票贴的标识。
3，关联功能
像社区这类牵一发动全身的产品，做一个小的功能点都需要仔细考虑其对其他功能的影响。最好的方式就是把所有功能过一遍，详细到字段。再拿投票功能举例：社区有个功能是用户可编辑已发布的帖子（就像写简书，还可以重新编辑了更新发布）。那在写投票模块的需求时就需要写清楚：
投票贴在修改的时候不允许修改投票内容（即编辑器里的发帖内容）和选项设置（对选项的增删改以及单多选的设置），只能修改标题，板块和其他设置（投票时间的起始时间不能修改）。编辑完成后的帖子点击发表则进入正常发表的流程（需要发表前的防呆），发表的时间更新为最新发表的时间。发表成功则帖子更新修改，发表失败则帖子保持不变。其他异常同新建发帖。
