培养的是业务感。做产品设计时，代表的不是产品经理，也不是技术，而是作为真正的需求提出方，你面临到问题，希望系统提供怎样的支持？

设计建议：

01服务心态。系统是为业务做支撑的，解决不了业务问题的系统设计基本没用。

02同理心。跳出原有框架，站在需求提出方的视觉来体会业务痛点，以此思考解决方案。

03流程和系统结合。将业务流程从头到尾梳理清楚，充分考虑线上和线下操作的联动，再在流程中需要系统支持的环节中加入系统功能，让线下流程和线上功能完美贴合。

2极简思维

简单的功能却沉浸在复杂的逻辑或交互；也曾认为简单的功能是设计者的失职，直到无数次的锤炼和洗礼，才知道大道至简。

系统功能或流程，尽量追求极简，极简的流程极大的减少人工成本，极简的系统操作起来更加流畅更容易上手。

设计建议：

01流程大于交互，首先思考流程的极简，再考虑基于流程来实现系统的简洁。

02交互设计上，向C端设计取经：突出页面核心功能区，一眼就明白主次；核心按钮摆放在更加显眼的位置，以突出重点。

03根据不同的场景和状态展示不同的功能，不要一股脑都罗列出来，形成乱花渐入的局面

04以成本和效率为首要目标，设计时让系统代替人工，极力减少人为操作和人为判断成本

3 积木思维

要符合SOA理念的，理想的B端设计模型是将已有庞大复杂的流程化繁为简，先碎片化为一个个可以独立使用的服务，将这些服务都存放进工具箱里，然后再根据业务场景提取相应的服务，像搭积木一样，重新组装为业务需要的模块，快速适应业务变化。

设计建议：

01当一个功能被多个业务共用时，考虑将其抽象，作为一个独立的服务。将各个系统的取消逻辑统一为一个取消服务，供各个系统调用。

02服务的拆分和重组的颗粒度需要根据实际需要制定。将关联性强的功能一起封装打包为标准服务，若业务需要更粗或者更细粒度的服务，再定制化开发。

03积木虽好，但终有其局限性，当一个工程的需求超过了当前所有积木能够组装的范围，强行组装适得其反。

4 脉络思维

大部分时间在梳理流程和业务逻辑，遇到突如其来的大项目时，需要产品经理协助梳理。

脉络思维要求我们像庖丁解牛一样，先找到需求的主骨架，顺着骨架继续拆解四肢、内脏、筋骨，一步一步拆解到最小颗粒度，做到游刃有余。

设计建议：

01先理清主干和次要场景。主干场景是业务方提出需求的初衷，最需要支持的功能，此类需求优先级一定最高;次要场景一般是搭配主干场景使用的，优先级较低。

02扩展辅助和异常场景。业务方不会考虑太多，需要产品经理在梳理主干和次要场景的过程中完善。

03包含多个功能，涉及多个角色或者操作步骤时，考虑充分解耦，分成多个场景需求来处理。

5 全局思维

全局思维是一种大局观，要求站在一个更高更广的视角俯视全局，做到心中有数，不要在单个细节的得失处理中迷失自我了。

设计建议：

01明确方向，目标为王。船长在航行过程中，经常遇到风雨坎坷和烟雨迷雾，要求船长能时刻保持清晰的目标感和方向感，分主次、懂取舍，带领船队突破阻碍，到达目的地。

02大局意识，合纵连横。设计单点，考虑整面，由面再及点。设计单个功能时，考虑上下游系统的联通，以及本系统横向模块的影响，不能只考虑功能本身。

03以终为始，反向演绎。根据项目目标，结合资源、时间等因素综合评估，反向推演各里程碑和阶段性目标，以此做取舍，保证大目标的实现。

04审时预判，提前规划。产品经理要懂得审势，根据自己的经验和公司战略，提前做出一些预判和规划，以防事情到跟头了措手不及。

05适时归零，空杯心态。新环境新业务面前，为了更好的掌握全局，我们要学会适时的归零，多吸收，懂变通。

6回路思维

无论设计现场动线，流程，还是系统功能，都要有清晰的路径，包括正向和回路，除了能正向操作达到目标以外，还需要能回转到上一阶段。有来无回的，就是死路。

设计建议：

01设计实现自闭环，不过分的依赖于外部系统和因素。

02流程上和操作设计上充分考虑逆向和异常流程，而往往是最难却最容易被忽视的。

03系统新功能上线时，要考虑到新老功能切换的间档期的数据处理和老功能的正常使用。

7 开放思维

在一个系统设计之初，需要有开放的心态，考虑到未来与内外部业务和平台的协同，打破孤岛效应，让系统联通协作起来，如此才能产生更大的价值。

设计建议：

01在以单一需求为出发点时，思考是否支持其它业务的发展，若有类似的业务发生的，提前做好预留。

02设计新系统时，思考与其它系统的协同和联通，开放自有数据、服务、接口，让数据自由流转，产生单个系统无法实现的价值。

03实现公司内部业务的功能时，思考未来能否为外部业务赋能。