实践提炼:面对大型B端项目,产品设计该如何展开?

25 评论 44350 浏览 326 收藏 9 分钟

作者根据自己的工作经验,总结了一些面对大型B端项目时可用的设计思路,希望可以给大家的工作带来一些帮助。

ERP系统是典型的To B产品,拥有体量大、功能杂、专业强等特点。前段时间接触了如此庞大系统中三个子系统的改版工作,从手足无措到冷静思考,在无数磕磕绊绊中总结了一些面对大型B端项目时可用的设计思路。

因为项目复杂,此篇是整体设计思路的提炼及方法论的提出,具体的案例及方法论阐述后续会有更多文章来和大家共同探讨。

完整思路如下:

一、明确项目背景:了解各方改版动机及期望

除了基本的5W1H,改版项目在了解项目背景时能获取更多信息:现版本的反馈是什么?各个角色期望达到的目标是什么?

ERP项目中,客户不等于用户,所以多方的动机和期望我们都需要去了解,并以此推导产品设计方向。且因为满足客户需求应优先于提升用户体验,
所以对于多角色需求的亦需要权衡取舍。

了解了项目的基本情况后,开始进行需求的加工。

二、需求调研:不同的角色有不同需求

调研包括了需求加工的前三个部分:收集—挖掘—整理。

我们需要从轻易可得的用户反馈、使用体验,深度挖掘产品不易见的、更根本的问题,最终汇总整理出完整的需求表。

如何选择有针对性的需求调研方法,我们通过三步骤来确定:你想知道的—谁最了解—选用方法。

针对型收集,即是找对人问对事。这样在调研时,每一种方法的目的都很明确,关注点各有不同,既能得到较全面的信息,又不会在调研时迷失方向。

三、设计输出:以设计目标为导向的解构—重构

设计输出包括了需求加工的后三个部分:消化—改良—评审。

在已获得的需求中,首先提取出需求关键词并明确需求对象,一步一步推导出设计目标并得出接下来的设计策略。

在明确设计目标及策略后,开始通过“解构—重构—评估”对产品进行合理再设计。

1.解构:重在详细全面梳理功能模块,由浅入深理解功能定义。

在C端产品中,设计师同时也能是用户,所以对于功能的理解相对容易。但B端产品的用户往往是专业人员,产品是为实现某些业务服务的,我们可能从未接触过其中的业务逻辑。所以一个合理的理解模型,能够帮助设计师透彻理解复杂业务逻辑。

又由于ERP的难点在于业务逻辑及功能的多角色的互动,我们将以这两个为突破点,进行解构。

这种模型我把它叫做拔萝卜式理解,由专业词汇开始,到凝练出业务目标结束,中间是由表及里、由浅及深地探索过程。

在梳理复杂业务流程时,仅凭东拼西凑的信息,可能会有信息遗漏的情况。此时依据想获取的信息,适当的选用一些工具,可以提高我们的效率并保证一定程度上完整性。关于如何选择适宜的工具,以后会再和大家探讨~

2.重构:以设计目标为导向,由小到大,由内而外重构产品。

将所有涉及到的功能平铺陈列,讨论功能的合理性,再进行重组、删减。

不同的功能下相同的功能模块需要在逻辑及形式上保持统一,这也就意味我们在设计过程中建立适宜的规范更为重要了。

3.评审:以设计目标为评估标准,注重专家评审结果。

同时在方案输出过程中,要定时进行方案评估。因为产品较强的专业性,在内部评审过交互问题后,还需要专家评审,此时的关注点应在业务逻辑的正确流畅,功能的完整精简,所以此时不可图方便,需要仔细地走查每一个功能,从定义到实现流程,是否符合行业习惯且满足了专业要求。

四、原型测试:让数据说话。

大体量产品反复修改的成本较高,所以保持尽可能小的改动可能性很重要。虽然方案已输出,但如何能说明我们改版是有效的?原型测试中的数据也许能给我们这样的底气。

在一次测试中完成对所有要点的测试显然是不切实际的,要使测试的意义最大化,我们要始终带着明确的目的性去制定我们的测试规划。有目的的设定任务,随之选定相关参数,确定测试对象。在测试过程中,注意观察,认真记录。

测试结束后,数据整理和展现,可以让我们更清晰直观地看出测试结果及问题所在。例如我们在测试中得到了如下结果,可以初步判断我们的设计在使用上是有可行的。

到这一步基本完成原型交付,但项目后期也需要持续推进。可能会不停有反馈及问题出现,随时修改,保持更新。

五、最后

ERP系统的复杂程度远不是一篇文章所能承载,其中有很多值得思考的点,本篇仅作为大框架的概述,后期希望还能有机会和大家一起探讨To B项目中需求调研适用的方法、如何在情境下选择适用的设计工具等更实践性的问题。

 

作者:三水采田,微信公众号:三水与设计

本文由 @三水采田 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 受益匪浅,感谢楼主分享

    来自广东 回复
  2. ERP,通俗来讲就是人财物的管理,全程围绕“财”~“物”这两个环节,进行数据的流通转换,穿插进对应的人来完成中间环节产生的一系列成本费用,最后得出多个维度的报表。
    通常来说有两种类型,一种是商用,一种是内部管理的,其中商用的又分定制型的和通用版的,内部管理则是和专用的一样,作者这里提及的是PM的设计的思路,每一个行业,每一个公司对应的管理方案和管理需求都是不一样的,这就需要更多的看清需求的本质,这样才能设计出通用的软件,不过这个erp的设计,大框架上的设计没问题了,剩下的就是进行细节的处理了,那个环节也是磨死人的节奏,还有中间人员的进出,感觉设计一个erp(从需求到上线),不下于打一场持久战,少则1年,多则几年十几年都会有。

    来自广东 回复
  3. 您好,想问一下从项目开始到设计完成,一共花费了多少时间?分别是怎么安排的呢?

    来自浙江 回复
  4. 我也想问图是使用什么工具画出来的?

    来自北京 回复
    1. keynote

      来自北京 回复
  5. 赞一个楼主总结得清晰明了的方法论。能否加个微信或QQ交流下?

    来自山东 回复
  6. 很棒!请问下,图是使用什么工具画出来的?

    来自北京 回复
    1. 用的keynote哈

      来自北京 回复
  7. 感谢楼主的方法论,我也要加微信(注明:我是妹子 😈 )

    来自四川 回复
  8. 个人公众号 三水与设计,没找到那? 难得有人聊TOB之ERP

    来自四川 回复
  9. 1、ERP体系庞大到你忙人摸象, 2、单个系统模块功能纵向的深度,以及横向“三流信息”与其他模块数据,单据流转链式嵌入紧密,上下游系统模块互为一体,才可输出每个节点,及最后成果。

    来自四川 回复
    1. 是的,之前只是接触改版项目,最近做新系统时对您所说两点也深有感触。如果方便的话,要不我添加您?

      来自北京 回复
    2. 私信下,

      来自四川 回复
    3. 好的,,

      来自四川 回复
    4. 老司机回答的很有深度,虽然我没有做过ERP系统,但是做的其他系统也有如此体会。

      来自四川 回复
    5. 我现在也在做erp软件的改版,现在已经深刻体会到你说的第一点了

      来自上海 回复
    6. 实践的体会,共勉,在路上就好

      来自四川 回复
  10. 赞一个楼主总结得清晰明了的方法论。能否加个微信或QQ交流下?

    来自四川 回复
    1. 好的啊~方便的话我加您?也可以关注个人公众号 三水与设计,发送的我都会看到~😊

      来自北京 回复
    2. 我也要微信,楼主

      来自福建 回复
    3. 嗯嗯 不好意思啊刚看见 已经在公众号上发给你了~嘻嘻

      来自北京 回复
    4. 楼主,微信?加一下

      来自北京 回复
  11. 学习了。期待更多分享

    来自陕西 回复
    1. 嗯嗯 感谢阅读 也期待能和大家多些讨论,共同进步~ 🙄

      来自北京 回复