目标与执行｜B端产品设计过程中注意事项

好久没写文章了。趁着周末，反思下最近工作中的得失。

一、项目与产品

传统的B端产品遇到的一个很大问题就是如何产品化？

首先大家都希望做产品，既能够满足不同客户的需求，又可以降低维护成本。不过在B端产品领域，由于每家客户都有自己的组织结构、管理模式，希望用一款产品打天下确实比较困难，因此定制化成为了B端产品的一大特色。

记得2012年左右，当时做过一款电力产品，部门领导就希望实现产品化。但是各个电力公司的工作流程和管理方式或多或少都有自己特有的方式，最终还是按照一个个项目执行落地，导致开发运维团队要维护多个版本，带来了各种附加成本。

最近因为一个项目，发起了一个产品设计（暂时这么称呼）。在设计执行过程中同样面临着一个问题，到底是按照项目现场客户具体要求来设计，还是直接考虑未来更多的客户需求，按照产品化的形态覆盖更多的用户场景呢？

这个或许没有明确的定论，不同的产品体系或者公司会有不同的运作方式。不过在设计执行过程中，明显感觉到这对产品需求范围和设计决策有着很大的影响。

在我看来，首先以项目的形式去执行更为合理。因为面向项目场景可以聚焦在当前客户范围内，需求、场景、业务流程比较清晰，更有利于设计决策和落地，并且可以验证产品的价值。

以产品的视角去执行，对于0-1阶段的产品，功能范围可能会被过度放大，产品设计就会变得极其复杂。

二、战略层的重要性

体验设计师的工作主要是在框架层和表现层，对战略层的感知不强。但是作为产品设计师或者产品经理，整天在跟“需求”打交道，就会发现战略层极其重要。

最近的项目产品，虽然有其他的项目产品作为基线版本，但是整体节奏仍然比较紧张，尤其是在方案设计阶段存在不少的分歧。根本原因就是是产品战略层不清晰，没有搞清楚“产品到底要帮助用户解决什么问题，用户需要怎样的产品”。

战略层的模糊必然会导致产品范围层的功能容易飘忽不定，每次需求评审都会冒出一些新的需求方向。但是由于对用户场景和需求理解不深，这些需求做不做、怎么做、做到什么程度，所有人心中都没有定论。

在具体方案设计时，产品设计师没有搞清楚用户场景和需求，只能通过“个人理解”和“推测”执行，有些需求只是“我觉得”，从而导致产品走偏，落地开发时存在一些设计漏洞和逻辑问题。

三、多人协同

在工作中，产品线通常是相对独立的，一个产品经理负责一条产品线。但是复杂的B端系统包含了多个子系统，之间会存在业务流程的串联和数据交互，需要多个产品经理协作完成整个产品设计。

这时候就需要有一个牵头负责人，在项目设计开始前，能够站在全局视角下，统筹掌控整体的业务流程，保证参与其中的产品经理能够达成共识。否则产品经理容易各自为战，串联部分容易被忽略，最终在落地执行时，会发现业务流程上出现不一致或者相互矛盾，甚至是场景的缺失。

四、总结

根本上来说，想要做好产品，需要真正地接触客户，了解用户需求和场景。单凭产品设计师个人认知或者自上而下的视角，理解产品和需求会有很大的局限性，从而导致产品设计出现较大的风险。

产品经理不仅仅要知道“做什么”，更应该要知道“不做什么”。越来越觉得这句话真的非常有道理。

毕竟资源是有限的，将有限的资源准确地用在对客户/用户有价值的需求上，才能最大化地凸显产品价值，才能带来产品的成功。

作者

子牧先生，公众号：子牧UXD（HelloDesign）。产品体验设计师。8年互联网行业经验，擅长体验设计思维、设计方法论、交互设计研究。

版权声明

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