b端是什么意思，B端的实际操作详解？( 二 )

1）梳理流程
梳理流程，是理解业务，了解产品的第一步
2）梳理页面
产品存在多少个页面，页面之间的跳转关系是怎样的，是如何进行交互的，怎么跟业务进行关联的，结合具体的流程进行梳理页面，可以进一步帮助我们俯瞰整个产品的组成架构。
利用Xmind将页面进行归纳梳理，优先梳理流程页面，将所有页面列举出来，然后在页面层级列举详尽功能，将业务与功能进行串联。
3）梳理用例
简单来说就是梳理系统中有哪些角色，每一类的角色能使用这个系统做什么。
一个完整的用例图，就像一幅骨架支撑着整个身体。在设计产品时，我们往往从架构出发，当一个整体架构出来后，细节的地方不至于会影响大局。而在熟悉产品时，往往是从细节出发，就像医生看病，医生不会让你上来就直接手术检查。
4）梳理权限
B端产品不同于C端产品，B端产品更注重权限的管理，对权限控制的要求更高。所以，在B端产品设计时，需额外注意权限的控制问题。
梳理所有角色的不同页面权限、数据权限、功能权限一定是放在熟知产品一定阶段后，在此阶段再去梳理权限，更加容易理解整个系统是如何基于现实业务场景进行设计的。
公司的墙面上还贴着这样几句话“基于场景做方案，基于场景做服务，基于场景做产品”、我觉得加上业务会更好——“基于业务场景做方案，基于业务场景做服务，基于业务场景做产品”，在B端产品设计中，场景的考量一定是贴合业务的，脱离业务场景的需求，大多数是不可做的需求。
另一句是“做产品之前，先将自己变成用户”，放在C端，这句话我是认同的，但在B端，我是不认同的。
二、需求篇B端的需求来源于产品所面向的客户，定位的客户不同，产品设计的业务流程、功能侧重点都不同，此时，需求的判断和筛选就显得格外重要。
在来这家公司入职的第四天，我被派到外省出差驻点服务，期间接到一个需求，针对这个需求，当时只是简单的向甲方相关人员了解了下，然后就想当然的去做了，直到第一次与甲方过完需求后，才发现牛头不对马嘴，最终的结果只能是重新梳理需求，直到现在，这个需求仍有没有考虑周全需要优化的地方。
存在几点错误：

盲目自信，误以为自己理解了需求，想当然的就按照自己的想法去做了
没有反复的跟客户进行确认，在没有充分的了解业务场景的前提下，就开始着手工作
只顾全了单方面角色使用的情况，欠缺考虑多方协同的情况，在B端产品，大多时候会涉及到多方参与
未去深入了解系统，不熟悉公司的开发方式，跟研发人员欠缺前期的需求沟通，未站在更高层次去看待需求

为什么会说未站在更高层次去看待需求呢？在B端，需求可能没有真伪，只有可做可不做，就比如客户告诉你这个需求要做，因为他花了钱。既然是花了钱的东西，就要体现出物有所值，你的服务响应也是体现的一方面。其次就是老板的想法，你得找到充分的理由告诉他，这个需求到底是怎样的一个需求，值多少钱？如果不值钱的需求，做出来最后也只会落得一地鸡毛。
在C端，用户会被贴上不同的标签，用于进行区分，在B端同样，也需求对客户进行分级，所以才会有标准化产品和定制化产品。
不同的客户需求存在差异性，这也导致B端的需求往往很难做到统一标准化来满足不同客户的需求差异。
在面对B端需求时，这里有几下几个建议：贴合业务场景、深入一线调研、主动引导客户、持续接收反馈。