B端产品往往信息繁多，架构复杂。所以对信息进行合理分类，设计一个好的信息架构十分重要。其中最重要的一点是——遵循合理的一致的规范，而这个规范也一定是围绕着我们的设计目标来的，我们最想让用户关注到什么，最想产品能解决什么问题。一是方便用户理解产品，在第一眼时就能对产品有简单的认知;二是方便后续有新功能加入时，仍能遵循原来的规范。

　　先根据流程整理出，完成所有任务需要的信息(并进行优先级划分)，再根据遵循合理的规范分类组合(最好在信息架构中标明出)。

　　例如，我们的设计目标是“帮助用户及时发现发现xx问题，高效解决问题”，那么我们分类的规范则可分为“发现问题”“分析问题”“处理问题”“预防问题”几个维度来对信息进行分类。

　　3.原型设计

　　先画草图再画原型，为最终版本设计，始终围绕设计目标做设计，每个设计都应有出处，版本迭代时要注意和之前版本的融合

　　a.先画草图再画原型

　　根据流程图中标记需要出的页面，画完草图就可以和内部或产品经理讨论整体思路了。既能快速表达想法，提高效率，也能在方案有偏差时，不至于因为沉没成本高而不愿舍弃。当草图得到认可后，那么之后原型的大框架基本上就没什么问题了，这样即使原型有什么被质疑的地方，也很好缩小范围，知道要改什么具体的地方。

　　b.为最终版本设计

　　有的时候，可能因为时间的原因，有些方案就只能实现一半，而一半的效果又往往不是当前时间、资源下的最优解。于是，有些交互便会为当前情况下，做出中间版本的设计。(没错，就是之前的我)可实际上，这样的设计，并没有给未来带来任何好处，反而会徒添之后开发修改的任务量。

　　正确做法是: 只为最终版本设计，如果开发时间不够，那么标明目前版本的优先级，有些开发难度高且价值不大的，则放在下一版本实现。

　　c.始终围绕设计目标做设计

　　设计师进行原型设计时，通常会陷入一个误区: 做着做着，就忘了当初为什么这样做，然后深陷细节，忘记当初的设计目标。实际上，并不需要做这么多。时时反思自己的设计是不是围绕设计目标，可以防止自己做很多不必要的设计。

　　d.每个设计都应有出处

　　要理解为什么要有这些步骤，理解后台逻辑究竟能不能实现，不能想当然地做设计。理解了这些步骤的来源，来能更好地结合用户心理做更符合用户心智、更高效的设计; 理解了后台逻辑，才不会做出逻辑上极难实现的设计。

　　例如，“后台验证用户手机号”，是应该在“用户点击获取验证码”时验证还是在“输入验证码点击确定”后验证呢?从体验角度上，“点击获取验证码”基本上就能确认用户已成功输入了自己的手机号，理应这时验证会节省几个步骤，用户体验会更高效自然一点; 但是如果再多了解一些后台逻辑的话，可能就会发现这还存在着很多问题了。

　　e.版本迭代时注意和之前版本融合

　　一个产品是一个整体，版本迭代有新增模块时，要考虑这个模块与之前的其他模块有什么联系(做好信息架构，也可提前帮助解决这个问题); 之前产品的惯有交互形式是怎样的; 相同类型的功能有什么联系，能不能整合; 有哪些地方是需要和之前产品保持一致的，等等。

　　4.多方评审

　　最终评审前分阶段找相关人员进行评审，陈述方案时注意自上而下表达，明确会议主题，记好会议纪要

　　a.最终评审前，分阶段找相关人员进行评审

　　在需求分析阶段，找主对接的产品经理来确认自己产出的设计思路，整体流程等大方向有没有什么问题; 在设计阶段，也要保持和内部人员以及产品经理的沟通，确认主要的原型页面，在接着细化细节，再与主对接的产品经理沟通。在这个过程中，还应积极向视觉、开发同步传递需求及设计理念。

　　这样与相关人员经常保持沟通，信息同步，既可以减少自己因闭门造车而在最终评审时的大返工，又可以让团队人员提前了解提前做好准备，从而提升团队效率。

　　b.陈述方案时注意自上而下表达