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

本文作者对一个B端项目进行了复盘,着重从liú程角度对项目进行chāi解,阐述其中需要注意的地方。

入行以来,侧重点都是偏向前端即所谓的C端,较少触及X项目,细细数来不过三四个而已。最近再次从0到1完成了一个X项目,感触颇多。

借总结复盘之机,分享一些自己的体会。不管是liú于表面也好,或是对你帮助自然更jiā,一同共勉前行。

目录:

  1. 项目背景
  2. 项目生命周期
  3. 阶段chāi解分述
  4. 总结分析

一、项目背景

产品定位:满足内部孵化项目X管理、统计分析需qiú,代号为PGDX管理系统。

目标用户:母X的品质合作商、已经合作的渠道商、孵化项目的运营人员。

痛点:重要的用户数据、交易数据、商品数据部署在第三方平台,且分布分散,无fǎ形成有效的管理和统计分析。

产品目标:X线上、可视化平台进而降低cāo作门槛、合作X,减少核心资源的投入和依赖,从而有效提升平台的渠道商入驻率和商品的质量。最终,形成平台性的影响力和品牌效应。

二、项目生命周期

(可X放大)

如上图所示,X项目产品的liú程与前端项目相比而言,有些节点还是存在差异的。

一般而言,可以分为六个阶段:

  1. 启动:产品需qiú挖掘;
  2. 启动:功能需qiú挖掘;
  3. 执行:规划、立项、评审;
  4. 执行:需qiú、设计、评审、测试;
  5. 执行:开发、测试、验收;
  6. 收尾:发布、数据监控;
  7. 收尾:复盘总结、迭代需qiú。

(可X放大)

三、阶段chāi解分述

3.1 启动:产品需qiú挖掘

(可X放大)

产品需qiú挖掘,如果从岗位划分来说是产品经理的职责范畴。可是作为体验设计师,你如果不参与这个过程,在某种程度上,后续在理解X深度上是有可能存在偏差的。

所以,建议相关用户体验设计师在产品需qiú初立,即加入讨论。当然,这个恐怕需要结合不同X,不同合作团队来看哈,有些产品不一定乐意体验设计师提前介入。

3.1.1 目标用户分析

B端项目组件化思考-liú程篇

不管是B端产品,还是C端产品,都离不开客X用户。

KCL项目的用户X,其实有些不同。如上图所示,分为三大X:所在内部孵化平台运营人员、入驻渠道商及渠道商下属的门店相关人员。不同X又涉及不同的利益相关者,这就需要在进行目标用户分析的时候,注意不同用户需qiú问题的收集,并设置不同的登记编号。

3.1.2 用户目标分析

B端项目组件化思考-liú程篇

改版或者旧版架构关系如上图所示,平台对于X商下属的门店没有影响和X力,门店出现X差评或者用户投诉的时候,只可以X门店的上层X商进行处理,这种情况极大的影响了平台品牌传播。

因而,项目平台希望新版X项目可以加强对于商品、门店、商户的影响和X力,避免因为入驻商户或门店的X,影响到平台自身的品牌建设。

B端项目组件化思考-liú程篇

改版用户目标

3.2 启动:功能需qiú挖掘

B端项目组件化思考-liú程篇

功能需qiú挖掘的核心,在于需qiú的管理和排序管理。

当然,对于明确目标用户同样重要。目标用户客X,是筛选需qiú层级的标准因素之一。

因为与C端不同,B端的决策者、X者、使用者通常不会是同一波人,并且价值优先级为决策层>管理层>执行层。故在泉衡决策产品时,不仅需要从多层级来进行综合平衡,需要更加关注对决策层和管理层的价值。决策层,可能是X方的boss们,也可能是上级主管层。

而我们获取需qiú的方式,一般主要分为X需qiú、技术需qiú和功能迭代优化需qiú。X需qiú又分为内部需qiú和外部需qiú。例如所在KCL项目来说,我们除内部KCLX场景的需qiú,还有母X分配过来的需qiú。

技术需qiú的基数一般比较小,这种需qiú主要存在于外部需qiú情况下会产生技术类需qiú,一般都是由X需qiú产生技术类需qiú。各种需qiú汇集成需qiú池,对于需qiú的优先级排序就显得极为重要。

3.3 执行:规划、立项、评审

B端项目组件化思考-liú程篇

其实这个阶段,我暂时未参与。上图中关于立项的细节,主要是X一高级产品朋友获知。

关于规划立项这个,据说一些大厂有的是由产品来推动,有的是由高级体验来推动立项。立项X后,需要负责人协调各个部门资源去推动立项的细节,上线之后的指标会直接影响最终的考核。

话题跑远了,关于立项这个环节,依不同X和项目团队自定,非必要环节。但每次发起需qiú时,也需要明确产品的价值,如何去衡量收益,是否与项目、X目标有关联,是否一致。

这个对于接下来的需qiú排序和交互方案设计,有着重要的参考依据价值。

3.3 执行:需qiú、设计、评审、测试

B端项目组件化思考-liú程篇

3.3.1 需qiú评审

由上一个阶段筛选初步需qiú优先级之后,需要进行需qiú评审。

需qiú评审的参与方,一般包hánX方、产品经理、用户体验设计师、视觉设计师(非必须)、研发(此阶段可不参加)。之后,依据确立当前版本的迭代规划,开始交互方案设计。

至于界面设计,需要看X项目的实际情况,KCL项目来说,因为并未采用比较知名的设计语言框架。所以,需界面设计师介入。如果采用了例如antdesign设计组件的时候,界面设计师一般不需要介入的。

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

3.3.2 设计

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

B端项目组件化思考-liú程篇

如上图(平台管理员泉限图),在不同级别功能泉限设置上,需要考虑的是符合用户的cāo作预期和平台本身的运营成本。

例如KCL项目,商品的X,最初是考虑商户同样具有cāo作泉限的,但是在后续与X方沟通之后,发现就其本质来说,平台上shòumài的商品资产状态已经归属于平台。之所以会需要商户入驻,主要是为了解决C端用户X之后,去线下核销的时候,确认资产合fǎ性的。

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

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

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

3.3.3 交互评审

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

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

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

3.3.4 测试

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

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

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

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

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

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

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

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

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

3.5 收尾:发布、数据监控

B端项目组件化思考-liú程篇

当各项验收基本无问题(主liú程走通=上线标准),App端经常会用到X、灰度、A/B test等方fǎ进行小范围试验,然后开始逐步放量,用大量的数据来验证效果。

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

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

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

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

3.6 收尾:复盘总结、迭代需qiú

B端项目组件化思考-liú程篇

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

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

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

迭代需qiú的规划,其实就是一个新的项目liú程的开始。这点对于不同团队有不同的后续,有的做完从0到1之后,是规划下一版本(小版本两周一迭代,大版本一个月一迭代,遵循MVP);有的团队,却是需要移交后续团队去运营,接下来是新的项目的从0到1liú程。

四、总结分析

这六个过程,从思维层来说,仅仅是自己从实际项目中考虑总结的一点个人看fǎ。

对于PM或者体验设计来说,重点在于启动和收尾,把控好这两个阶段,对于项目来说起码成功三分之一了,中间主要看的是团队资源和实力。

从界面层来说,还有一个非常重要的点,就是组件化的规范。掌握好组件的X,对构建交互方案、与开发对接和沟通会有想不到的收获。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 B端项目组件化思考:流程篇 https://www.xiongfawang.com/3885.html

常见问题

相关文章

B端项目组件化思考:流程篇-海报

分享本文封面