还有一类是企业用户，这类用户可能又含两种角色，一种是为工作，使用产品的目的是提升工作效率，比如企业HR，使用人事系统来管理员工事务。举个小例子，对于企业员工的福利类别和税类别是根据员工的性质不同而不同的，这就需要HR来维护，从而提出需要HR管理福利类别和税类别的需求，但对于福利的种类和税表等，属于国家政策范畴，就可以不支持用户亲自维护。最好的方式是阶梯式、动态的，依据应该是企业性质、需求特点等。
想打磨出一款“有用、可用、易用、好用”的产品，请先做好框架设计。本文作者将结合自己的工作经验，分享了几个易被大家忽略的点。enjoy~
不管是B端还是C端产品，框架设计的重要性不言而喻，就像一篇文章的大纲结构，可以引导读者快速理解文章脉络和作者的思路。在它之下，是作者的知识结构，写作技巧，乃至他的经历 。一款产品也如此，受企业老板、用户、市场、技术等方面的束缚和影响。想打磨出一款“有用、可用、易用、好用”的产品，请先做好框架设计。我只是从自己工作的角度总结了一些大家容易忽略的点，换了一种更远的角度，从源头开始理解产品，可以减少一些团队后续的改动工作量。
一、明确产品的使用者
产品的使用者无非就两类人，一类就大街上的普罗大众，也就是大家常说的C端用户，他们手里的产品，一般只能看到前台页面，后台设置完全由公司运营团队负责。这类产品对用户体验比较看着，毕竟同类产品多，只要你让我不爽，我分分钟卸载。还有一类是企业用户，这类用户可能又含两种角色，一种是为工作，使用产品的目的是提升工作效率，比如企业HR，使用人事系统来管理员工事务。这类用户一般不是最终的购买决策者，但他们的意见往往起到主导作用。另一种角色我称为“B端的C端用户”，比如企业的普通员工，使用公司的人事系统发起申请，管理一些自己的日常事务。这类用户面对难用的产品往往只能默默忍受，边使用边吐槽。但是他们的吐槽涉及到“企业员工满意度”，会影响到公司管理层的考核。所以设计者请不要忽视了这类用户的存在。
因为2B产品存在太多的角色，而满足角色之间的相互协作和不同需求（有可能存在冲突的需求），是最基本的。同时还要考虑同一个用户分属不同角色的情况，设计产品的的入口时，是使用不同的账号登录两套系统，还是同一个账号登录后的页面切换。前者需要使用者创建多个账号，无形中增加了用户的记忆负荷。相反后者用户只需记住一个账号，利用角色权限分配，在系统做处理，如何让他在系统中不迷茫（比如清晰的菜单分类，明确的任务提示等），但这对于本身就业务复杂的产品，更将考设计师的水平了。所以，一套科学完善的用户权限机制至关重要。
二、确定产品的基础框架和底层架构
B端产品除了要考虑系统内角色之外，针对不同企业的特殊性需求也是设计者的一大挑战。我们作为乙方，如果只根据甲方的需求进行设计开发，无疑是最轻松的方式。但这只适合于传统的外包公司，对于有追求有理想的企业，必然有自己产品。现在都标榜自己是“新兴的SaaS企业”，我们只卖服务。既然如此，那么软件基础框架就成了产品的灵魂。
哪些需求是作为产品的标准功能，哪些需求是单独你这家客户提出来的，作为你的定制化，是需要额外收费的。这些在设计之初，就应该评审清楚。不要急着下结论，不要纠结于细节，虽然产品人员在前期需求设计时，对细节把握得越充分，后期沟通成本会减少很多。但在这个阶段却是不适合的，当一家客户提出某个需求后，需要做的是研究清楚该需求是共性还是个性，在这个行业里的专业性有多高等等。因为任何一款产品都是在需求池中泡大的，这将决定你产品在行业中的专业程度和权威性。
这里说的底层架构不是指技术上的类似于MPC-HC之类的架构，而是指产品经理需要明确的系统基础Core。就像一颗树的根部，无论如何生长，根部都是最重要的。上面提到的B端产品用户角色的复杂性，一套健全科学的权限逻辑就可以是基础Core的一部分。基础框架可以就可以理解成树干，当这两部分正常生长，剩下的就是开始让其枝繁叶茂，开花结果了。只有确定了这些，才能更准确地进行需求管理和确定任务优先级。从交互框架上，也不仅仅只是从信息架构层面设计，更可以从纵向维度，像穿针引线般将多个功能串联起来。
三、考虑产品的灵活性
当特性的数量达到一定程度时，会转变成共性。但这中间的过程，必然要考虑产品的开放性和灵活度。这会给后续的产品迭代节省成本，同时满足更多的用户场景。开放性可以体现在API上，一个好的SaaS产品会拥有一套强大的数据流转结构。绩效考核系统也许部分数据来源于另一个营销平台，部分数据也许来源于考勤系统等等。很多客户企业因为各种历史问题或业务原因，会在工作中使用多种软件互相协作。关于这方面，也可以先与技术人员多进行沟通。说到灵活度，需要产品经理比较强的预判能力，简单而言，需要考虑到该功能当前使用场景，未来的用户场景（之后发生需求变更的可能性多大），以及由该功能引发的其他需求变更。
举个小例子，对于企业员工的福利类别（福利城市、缴纳比例等）和税类别（减免值、计税方式等）是根据员工的性质不同而不同的，这就需要HR来维护，从而提出需要HR管理福利类别和税类别的需求，但对于福利的种类（如五险一金）和税表等，属于国家政策范畴，就可以不支持用户亲自维护。最好能了解行业里这种需求发生的频繁程度，当某个企业提出一个比较奇葩的需求时，你可以例举其他公司的案例，甚至提出更完美的解决方案。
四、了解产品的收费模式
2B跟2C在商业性质上也有很大的区别，B端产品以业务复杂著称，不像C端产品，用钱可以很快烧出一个复制品，B端产品都是慢慢熬出来的，战线长，成本高，不是说复制就能复制的。排除个例的谈情怀外，大家都是为了盈利赚钱的，2C可能先用圈用户，赚流量，一步步让你掏腰包。但是2B看起来更注重商业利益，很直接的交易行为。你付多少银子，我给你多少功能。有些初创企业能有客户就不错了，所以会出现一口价的情况，但这种模式真的好吗，服务既是主观又是客观的东西。最后你会发现，价格要么开高了要么开低了。最好的方式是阶梯式、动态的，依据应该是企业性质、需求特点等。
商业模式其实很复杂庞大，收费模式只是其中一个环节，但收费模式必然会关系到我们产品的框架结构。若你按license收费，当企业需要购买新模块时，是更新license授权还是通过在线升级？如果模块与模块之间单独收费，是否考虑了外部数据接口，是否可以通过人工批量导入。当激活多个模块时，每个模块之间数据如何流转及交互上的互动关联？模块内部是否可按某种功能组合的数量来收费，如果可以，用什么方式来限制用户添加多个这种组合？还有客户化内容，哪些功能是可以通过客户化团队来做，哪些由产品研发团队接手？系统框架结构都会由收费模式不同而不同。
以上任何一点往细了扩展，都可以是长篇大论，这里只做简单的概括，有机会再聊聊B端产品的其他方面设计。
祝好。
本文由 @一念 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Pexels，基于 CC0 协议
,
