上周完成了我的第二次正式的产品设计，做完之后感觉在Web设计方面的积累还有一点薄弱，已经做好了书单准备恶补。不过，现在自己在产品设计阶段的流程掌握已经比较清晰，在本文中将大致的方法和一些需要注意的地方总结出来。我的设计流程，也大致按照下面的顺序进行。其中省略多次评审的步骤。
一、需求分析
在这里我把需求按照来源和目的分为下面4种，基本涵盖了我在设计过程中所遇到的情况，也比之老教材中的分类更具针对性，更易理解。
1.用户需求
用户需求也是整个产品所要完成的核心业务，通常也是用户使用的直接原因。
（1）写出产品所要解决的核心需求：比如订酒店、找工作。
（2）将核心需求的流程画在纸上，比如选择酒店->支付->入住->评价。
（3）考虑核心需求流程的支线可能，即该环节操作是否成功，反馈是积极的还是消极的。并在出现判断逻辑的地方画出分叉的情形，使流程完整可用。比如在上述的入住环节，用户未能成功入住，会产生取消订单的支线流程；入住后反馈很差，则需要投诉流程。
（4）围绕核心需求流程实现的某个环节，用户需要哪些辅助需求：比如辅助用户有效率地选择酒店，就可能需要搜索、筛选、排序等；又比如用户从选择酒店到支付之间，需要有详细信息和安全保障来支撑他做出预订决策。
以上所有，完全可以用一些不同的故事来表述，能够比较完备地讲通，也就基本掌握了用户需求。
2.商业需求
为了达到某种商业目的的需求，这些需求有产品出生时就有的，也有可能来自运营，区别于其他需求的特征就是，它们并不能从根本上影响产品核心业务流程的完成，但可以改变局部的统计数据或者流量分布。比如积分体系，从产生积分到积分商城消费积分，整个砍掉确实不会影响用户继续在平台上购买产品，但通过积分我们可以实现提升黏性、定向导流等很多目的。
3.常规需求
比如需要身份识别的产品，必有的注册、登录，账户设置。
再比如web端通常的页脚内容。
4.性能需求
我所设计的产品，暂时还未遇到对性能有要求的情况。以后遇到了再回来补充。
5.埋点
包括一些常规数据的埋点，以及设计出现分歧的预留验证方式（请尽情的用来打脸吧：）。
二、结构设计
把需求框架画到脑图之中，就有了最初的整个结构。结构层的设计包含信息架构和交互设计，此时也因产品类型不同而侧重点不一样。
1.传统web式
web端产品的信息架构，要从首页做起。首页包含了绝大多数功能的可视化入口，从首页出发，二级页面分别有哪些，完成什么功能，包含什么内容。这个过程，会做出整个产品的信息架构图。2.流水线式
通常出现在移动端较多。用户打开产品之后一步一步按照引导操作，每一步的目标单一。不会有无关信息杂糅。这个过程，一般会做出交互逻辑图。
在这一步完成之后，整个产品有多少页面，UI工作量大概有多少就可以初步有个预估了。
三、导航、规则、内容元素
对照刚才画出的结构图，思考所有需要有导航的地方。导航的用处有两个，让用户知道身在何处、让用户自在的移步。
所谓规则，就是一切需要搜索、列表等大量信息展示的地方，需要指明可搜索的关键词类型，列表项的分类，以及排序规则、筛选规则、单页最大容量。这些信息全部用备注形式标注在结构图中的相关页面上。举个现实中的例子，订单列表中，需要有第一级的tab区分订单类型，机票订单和酒店订单不可能混在一起。第二级的tab将用户关注的退款订单单列，出于引导点评，将未点评订单单列。而对于订单的状态，则根据流程的不同，有待付款、已付款未消费、未消费正在受理退订、已退订、已消费未点评、已点评等等，这些状态的不同，会影响这条列表项所包含的内容元素以及可操作行为。而这些思考，我的习惯是放在页面设计之前，否则做原型的时候，会改来改去。
四、页面布局
这个过程，主要依据所展示板块、元素的逻辑和优先级来进行，依照脑海中逐渐清晰的样子画出原型即可。给我印象深刻的点很少，待补充。
五、检查与优化
自己全面跑通五遍，看看有没有遗漏，之前的想需求时候的故事有没有顺着网页讲不下去的地方。并且找一找有没有可以优化的点，比如如何让初次注册后登录更方便，如何让短信验证时的输入更方便。
关于自查，还是放一张大牛的图吧。
六、输出PRD
水到渠成了吧。每个人的PRD，或者说针对不同产品不同处境的时候，都会有所侧重。我比较喜欢在名词解释和语言统一上着重花工夫。毕竟，很多时候大家讨论了很久的东西，对一个物品的描述可能用过七八个近义词，这时候不在文档开头统一口径，给出详尽的说明，到时候产品会在一个不经意的角落打你一巴掌= =。还有想吐槽一句，对于会把红包和卡券傻傻分不清的一些孩子，我还是得把所有名词之间的区别写的清清楚楚，毕竟差了十万八千里。
