实践提炼：复杂 To B 产品的设计思路

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

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

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

完整思路如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、最后

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

作者：三水采田，微信公众号：三水与设计

关键字：产品经理, 产品设计, 设计

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！