想打磨出一款“有用、可用、易用、好用”的产品，请先做好框架设计。本文作者将结合自己的工作经验，分享了几个易被大家忽略的点。enjoy~

　　不管是B端还是C端产品，框架设计的重要性不言而喻，就像一篇文章的大纲结构，可以引导读者快速理解文章脉络和作者的思路。在它之下，是作者的知识结构，写作技巧，乃至他的经历 。一款产品也如此，受企业老板、用户、市场、技术等方面的束缚和影响。想打磨出一款“有用、可用、易用、好用”的产品，请先做好框架设计。我只是从自己工作的角度总结了一些大家容易忽略的点，换了一种更远的角度，从源头开始理解产品，可以减少一些团队后续的改动工作量。

　　一、明确产品的使用者

　　产品的使用者无非就两类人，一类就大街上的普罗大众，也就是大家常说的C端用户，他们手里的产品，一般只能看到前台页面，后台设置完全由公司运营团队负责。这类产品对用户体验比较看着，毕竟同类产品多，只要你让我不爽，我分分钟卸载。还有一类是企业用户，这类用户可能又含两种角色，一种是为工作，使用产品的目的是提升工作效率，比如企业HR，使用人事系统来管理员工事务。这类用户一般不是最终的购买决策者，但他们的意见往往起到主导作用。另一种角色我称为“B端的C端用户”，比如企业的普通员工，使用公司的人事系统发起申请，管理一些自己的日常事务。这类用户面对难用的产品往往只能默默忍受，边使用边吐槽。但是他们的吐槽涉及到“企业员工满意度”，会影响到公司管理层的考核。所以设计者请不要忽视了这类用户的存在。

　　因为2B产品存在太多的角色，而满足角色之间的相互协作和不同需求(有可能存在冲突的需求)，是最基本的。同时还要考虑同一个用户分属不同角色的情况，设计产品的的入口时，是使用不同的账号登录两套系统，还是同一个账号登录后的页面切换。前者需要使用者创建多个账号，无形中增加了用户的记忆负荷。相反后者用户只需记住一个账号，利用角色权限分配，在系统做处理，如何让他在系统中不迷茫(比如清晰的菜单分类，明确的任务提示等)，但这对于本身就业务复杂的产品，更将考设计师的水平了。所以，一套科学完善的用户权限机制至关重要。

　　二、确定产品的基础框架和底层架构

　　B端产品除了要考虑系统内角色之外，针对不同企业的特殊性需求也是设计者的一大挑战。我们作为乙方，如果只根据甲方的需求进行设计开发，无疑是最轻松的方式。但这只适合于传统的外包公司，对于有追求有理想的企业，必然有自己产品。现在都标榜自己是“新兴的SaaS企业”，我们只卖服务。既然如此，那么软件基础框架就成了产品的灵魂。

　　哪些需求是作为产品的标准功能，哪些需求是单独你这家客户提出来的，作为你的定制化，是需要额外收费的。这些在设计之初，就应该评审清楚。不要急着下结论，不要纠结于细节，虽然产品人员在前期需求设计时，对细节把握得越充分，后期沟通成本会减少很多。但在这个阶段却是不适合的，当一家客户提出某个需求后，需要做的是研究清楚该需求是共性还是个性，在这个行业里的专业性有多高等等。因为任何一款产品都是在需求池中泡大的，这将决定你产品在行业中的专业程度和权威性。

　　这里说的底层架构不是指技术上的类似于MPC-HC之类的架构，而是指产品经理需要明确的系统基础Core。就像一颗树的根部，无论如何生长，根部都是最重要的。上面提到的B端产品用户角色的复杂性，一套健全科学的权限逻辑就可以是基础Core的一部分。基础框架可以就可以理解成树干，当这两部分正常生长，剩下的就是开始让其枝繁叶茂，开花结果了。只有确定了这些，才能更准确地进行需求管理和确定任务优先级。从交互框架上，也不仅仅只是从信息架构层面设计，更可以从纵向维度，像穿针引线般将多个功能串联起来。

　　三、考虑产品的灵活性

　　当特性的数量达到一定程度时，会转变成共性。但这中间的过程，必然要考虑产品的开放性和灵活度。这会给后续的产品迭代节省成本，同时满足更多的用户场景。开放性可以体现在API上，一个好的SaaS产品会拥有一套强大的数据流转结构。绩效考核系统也许部分数据来源于另一个营销平台，部分数据也许来源于考勤系统等等。很多客户企业因为各种历史问题或业务原因，会在工作中使用多种软件互相协作。关于这方面，也可以先与技术人员多进行沟通。说到灵活度，需要产品经理比较强的预判能力，简单而言，需要考虑到该功能当前使用场景，未来的用户场景(之后发生需求变更的可能性多大)，以及由该功能引发的其他需求变更。