发布时间：2019-1-5 分类： 行业资讯
想要打磨“有用，可用，易于使用，易于使用”的产品，请先进行框架设计。本文作者将根据自己的工作经验分享几个容易被每个人忽视的观点。享受〜
无论是B面还是C面产品，框架设计的重要性都是不言而喻的，就像文章的大纲结构一样，它可以引导读者快速理解文章的背景和作者的内容。想法。根据它，作者的知识结构，写作技巧，甚至他的经验。对于受老板，用户，市场和技术约束和影响的产品也是如此。想要打磨“有用，可用，易于使用，易于使用”的产品，请先进行框架设计。我只是总结了一些人们可以从他们自己的工作角度轻易忽视的观点。为了从源头更改产品，我们可以减少一些团队后续更改的工作量。
一、明确产品的使用者
产品的用户只不过是两类人，一类是街头的普通大众，也就是人们常说的C-end用户，他们手中的产品只能看到头版，而且背景设置完全由公司运营团队控制。对...负责任。这种类型的产品相对以用户为导向。毕竟，有很多类似的产品。只要你让我不开心，我会在几分钟内卸载它。还有一种企业用户，可能有两个角色。一个是工作，使用产品的目的是提高工作效率，如企业人力资源，使用人事系统来管理员工事务。这些用户通常不是最终的购买决策者，但他们的意见往往起主导作用。我称之为“B侧C侧用户”的另一个角色，例如公司的普通员工，使用公司的人事系统来启动应用程序并管理他们自己的一些日常事务。这些用户通常只能在面对困难的产品时默默忍受，同时使用侧面吐痰。然而，他们的口号涉及“员工满意度”，这将影响公司的管理评估。所以设计师不应该忽视这些用户的存在。
因为2B产品具有太多的角色，并且必须满足相互合作和角色的不同需求（可能存在相互冲突的需求）。同时，我们必须考虑同一用户属于不同角色的情况。在设计产品入口时，使用不同的帐户登录两个系统，或者在登录同一帐户后切换页面。前者要求用户创建多个帐户，这会不可避免地增加用户的内存负载。相反，后一个用户只需要记住一个帐号，使用角色权限分配，系统中的进程，如何让他在系统中不混淆（如清除菜单分类，清除任务提示等），但是这个对自己来说很复杂。该产品将按设计师级别进行测试。因此，科学和完整的用户权限机制是必不可少的。
二、确定产品的基础框架和底层架构
除了考虑系统中的角色外，B-end产品也是设计师面临的主要挑战。作为乙方，如果我们只根据甲方的需求进行设计和开发，那无疑是最简单的方法。但这仅适用于传统的外包公司。对于那些有理想追求的公司，他们必须拥有自己的产品。现在他们都宣称自己是“新兴的SaaS公司”，我们只销售服务。在这种情况下，软件基础架构成为产品的灵魂。
哪些要求用作产品的标准功能，哪些要求由客户单独提供，因为您的定制需要额外费用。这些应在设计之初进行审查。不要急于得出结论，不要陷入细节。虽然产品人员在设计初期就掌握了细节，但沟通成本会降低很多。但在现阶段，这是不合适的。当客户要求某种需求时，需要做的是找出需求是普通的还是个人的，行业的专业性等等。由于任何产品都在需求库中，因此它将决定您的产品在行业中的专业性和权威性。
这里提到的底层架构并不是指像MPC-HC这样的技术类似架构，而是指产品经理需要明确的系统基础核心。就像树的根一样，无论它们如何生长，根都是最重要的。上面提到的B端产品用户角色的复杂性，一组合理的科学许可逻辑可以作为基础核心的一部分。基本框架可以理解为主干。当这两个部分正常生长时，剩下的就是开始使它们蓬勃发展。只有识别出这些，才能更准确地确定需求管理并确定任务优先级。从交互式框架来看，它不仅可以从信息架构层面进行设计，还可以从垂直维度进行串联连接。
三、考虑产品的灵活性
当特征数量达到一定水平时，它将变为共性。但中间过程必须考虑产品的开放性和灵活性。这将节省后续产品迭代的成本，同时满足更多用户场景。开放性可以反映在API中，而优秀的SaaS产品将具有强大的数据流结构。绩效评估系统可以部分地来自另一个营销平台，并且一些数据可以来自考勤系统等。由于各种历史或商业原因，许多客户公司使用各种软件在工作中彼此协作。在这方面，您还可以先与技术人员沟通。在灵活性方面，您需要产品经理具有强大的预测能力。简单来说，您需要考虑功能的当前使用场景，未来的用户场景（后续需求变化的可能性）以及该功能引起的其他问题。需求变化。
作为一个小例子，员工的福利类别（福利城市，支付比率等）和税收类别（减少，税收等）根据员工的性质而不同。这要求人力资源部门维持并建议要求人力资源部门管理福利类别和税收类别的需求，但需要的是福利类型（如五种保险和一种黄金）和税收形式等，这些都属于国家政策的范围。 ，用户可能不支持个人维护。最好知道这种需求在行业中发生的频率。当公司提出奇怪的需求时，您可以提供其他公司的示例，甚至提出更完美的解决方案。
四、了解产品的收费模式
图2B和2C的商业性质也非常不同。 B端产品以其复杂的业务而闻名。与C-end产品不同，它们可以快速烧钱。 B端产品正在慢慢走出前线。长，高成本，而不是复制可以复制。排除个别案件的感受，每个人都在赚钱赚钱。 2C可以先使用圈子用户，赚取流量，然后让你一步一步地付钱。但2B似乎更注重商业性和非常直接的交易行为。你支付多少钱，我给你多少功能？一些初创企业可以拥有客户，因此会有价格，但这种模式非常好，服务既主观又客观。最后，你会发现价格高或低。最好的方法是逐步，动态，基于企业的性质，需求的特征等。
商业模式实际上非常复杂和庞大。收费模式只是其中一个环节，但收费模式将不可避免地影响我们产品的框架。如果按许可证收费，当企业需要购买新模块时，是更新许可授权还是在线升级？如果模块和模块单独收费，是否考虑外部数据接口，是否可以手动导入。当激活多个模块时，每个模块之间的数据如何流动以及交互之间的交互如何？模块内部是否可根据功能组合的数量收费？如果是这样，使用什么方法来限制用户添加多个？组合？还有定制内容，哪些功能可以通过定制团队完成，哪些由产品开发团队接管？系统框架结构将从充电模式到充电模式不等。
以上任何一点都可以延伸很长时间。这可能是一个很长的故事。这是一个简短的总结。我有机会谈论B端产品的其他方面。
祝好运。
