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

前后端开发产品配比(四点把控B端产品的框架设计)(1)

不管是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 协议

,