B端项目组件化思考：流程篇

B端产品更多是通过技术实现互联网信息化管理，对企业流程进行优化升级，从而达到降本增效的目的。而C端比较追求极致的简单好用，在整个产品设计上比较侧重用户的感受，偏向精心打磨页面与交互，尽量少让用户做选择，以保持产品的易用性与流畅性。

3.3.2 设计

在考虑交互方案设计的时候，需要格外注意产品的信息架构设计。这其中菜单结构设计、菜单功能父子级梳理，内容信息布局——上下结构、左右结构、上下（左右）结构又是重中之重。所有这些，必须都是基于业务流程来考虑。

如上图（平台管理员权限图），在不同级别功能权限设置上，需要考虑的是符合用户的操作预期和平台本身的运营成本。

例如KCL项目，商品的控制，最初是考虑商户同样具有操作权限的，但是在后续与业务方沟通之后，发现就其本质来说，平台上售卖的商品资产状态已经归属于平台。之所以会需要商户入驻，主要是为了解决C端用户购买之后，去线下核销的时候，确认资产合法性的。

在交互设计或者界面设计过程中，还有一点比较重要的就是组件化。组件化搭建设计界面对于设计后期维护，对于减轻研发的成本都是有非常大帮助的。

要搭建组件化项目，需要考虑两种情况：一是从0到1的时候，这个时候一开始就确认搭建组件化设计和研发是最为理想化的；二是从1到N的过程中，这个时候，要么一点一点修改前端显示和模块化功能，要么就是集中另外一组人力且有一个牛逼架构师，快速搭建新的平台，后续转移数据。

设计过程中，最好需要考虑CRUD原则（crud是指在做计算处理时的增加(Create)、读取查询(Read)、更新(Update)和删除(Delete)几个单词的首字母简写）和RBAC模型（RBAC，基于角色的权限控制，模型的核心是在用户和权限之间引入了角色的概念，取消了用户和权限的直接关联，改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限），特别是对于后台项目的设计体验有很大帮助。

3.3.3 交互评审

关于交互评审，此处不同团队又有不同情况。

UED团队比较小的，一般都是产品兼职交互方案设计。此时，方案需要在产品部分内部进行内审，这个内审，一般超过两次为佳。不管是内审还是外审，都最好自己设计一个自我审查表，走查一遍，以避免不要的低级错误出现。

对于中大型UED团队，交互方案一般都是用户体验设计师来主导，也是由体验设计师主讲。

3.3.4 测试

这里的测试，与后续技术测试无任何相关性。此处的测试是以交互方案或者界面方案为基础，设置跳转动效逻辑之后，行程与正式功能相差无异的操作体验测试。其目的在于，及时发现方案中不合理或者存在的问题。

3.4 执行：开发、测试、验收

开发技术评审，建议是尽量可以参加的就参加。这也是在KCL项目中，感受颇深的一个体会。

虽然说研发内部评审的时候，更多是讨论技术可行性，以及工时预估等。但是，如果可以及时并根据每个人分到的模块，可以有效控制deadline的风险，以及上线排期和排队审批流程。

特别是产品或交互方案设计的关键流程，要熟知是哪位研发负责。后续沟通中，如果出现问题，也可以及时协调资源进行补救。

技术测试的时候，作为体验设计师或者PM，最好与测试同学就各种细节，和衡量指标进行有效的沟通。不然，彼此之间可能会出现一些小误会。存在依赖关系的API是否已经开放完毕，非关键流程的数据指标没有及时产出，是否转移下一期……问题无法一一言明。

还有一点，需要注意的是技术侧，注重的是功能的可用以及局部和异常处理，对于项目的整体和体验并不会关注。所以，对于交互体验，还是需要体验或PM亲自验收的。

对于产品验收和体验设计验收，正如上文所说，与技术侧关注点不同。重点在于界面视觉元素的布局是否符合用户预期和使用习惯，功能操作是否符合用户的认知，信息获取是否增加了学习成本等。

验收结束，一定要输出一份验收记录。记录当前遗留问题和已完成功能，主要是为后续迭代规划或者移交工作留存记录。

3.5 收尾：发布、数据监控

当各项验收基本无问题（主流程走通=上线标准），App端经常会用到白名单、灰度、A/B test等方法进行小范围试验，然后开始逐步放量，用大量的数据来验证效果。

例如：今日头条非常喜欢搞A/B test，然后通过两个方案的数据对比来决定最终哪种方案。对于Web端的产品，因为没有版本这一层限制与隔离保护，当服务上线时，更需要产品经理做好信息公告、用户反馈的收集工作，在服务迁移时更是如此，才能做好平台与数据的平稳过渡、快速应对。

在KCL项目中，主要是数据迁移和上线放量内测阶段出现问题较多。B端项目和C端项目测试有个很大差异——B端用户，使用你的系统或项目都是循序渐进的，甚至试用半年以上都有。当然，如果品牌背书过硬，这个时间线就会比较短。

数据监测的软件非常多，可以根据团队选取适合的。因为母公司采购原因，后台数据监测经历过易观、数仓、还有集团内部的自研系统。

总体来说，个人觉得易观还好，其他的学习和掌控数据指标方面需要增加一些学习成本。

3.6 收尾：复盘总结、迭代需求

对于复盘总结来说，如果团队工作情况允许的情况下，是非常有必要的。虽然作为B端产品来说，好用、易用不是首要衡量标准，但是如果可以体验更好，对于后续市场的占领也是一个优势。

与C端产品比较大差异的是，对于用户的感受，B端产品最好是可以与用户访谈交流的。因为是否有效提升了其企业内部的管理效率，实际的调研比单纯的诗句更具有说服力（C端产品另说）。

这个阶段，复盘总结和规划迭代的需求是相辅相成的。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!