先定个义,本文的工具型产品指的是给特定工作人员在特定工作环境中使用的产品, 比如某公司的 CRM, 比如某客服中心的客服系统等。

由于工作原因,做了很多这类型产品,就不举例的总结一下之前的经验吧。为什么不举例呢,是因为这是我职业生涯的一大杯具,我有一天回头发现,这些东西基本上全都因为商业原因没法展示给他人,哈哈。作为一个交互设计师,基本上我在过去的这些项目里有两种属性:一,我是设计咨询公司的成员,说白了是乙方公司成员;二,我是公司内部技术部门的成员,说白了是支持业务方工作的。

常有产品经理和我抱怨,说业务方不配合,明明是大家一起指定的业务规则,然而业务方根本不和使用者讲明白,反过来怪我们的产品不好用。也有合作伙伴说,这个东西使用者就是这么用的,我们得这么设计。然后呢?我们的产品总是让自己不满意,让使用者也不满意。

我们为什么要设计这些工具型产品

毕竟在过去的很多年里我们都没有设计他们。那什么什么定律告诉我们复杂性是守恒的,用户爽了一定意味着有人没爽。对,过去我们的项目经理和开发说,这些东西能用就行了,要什么好看呢?(当然也没有要好用。)设计这个东西,几乎一定是要增加开发量的。

但是现在不一样了,这些工具使用者的老板希望员工可以提高工作效率,最好还能少用几个员工。我们的职业道德告诉我们要让使用者用的爽一点。大家花钱增加了设计这么个环节就是为了__提高效率和提升使用舒适度__。

业务驱动的设计

了解业务是设计这类产品的第一步。我们去听从客户的讲解,去听从业务方的诉说,因为我们是个门外汉。有时候使用者很有“人人都是产品经理”的特质,他们把想要的都说出来了,我就是要个标签页,要个大表格。然后我们就去做了,设计体现在我们的标签页放的更适合于点击,在信息结构上更加合理,更加美观等等。产品经理把他们的需求组合重排了,我们设计把他们的需求画出来了,或者说科学地画出来了。

我们在每一个环节争分夺秒的挤出了时间,然而产品的体量越小我们的努力越不明显,尽管成本很高。因为我们没能从流程上优化,使用我们产品的前后,用户在做同样的工作。(这里需要例子,农民的镰刀和收割机并不十分符合改善流程的情形)在业务驱动的环境下,我们在设计__Product__。

需求驱动的设计

听完了无穷无尽的诉苦,请问自己:他们为什么做这件事?一定要做这件事吗?一定要这么做吗?__请去挖掘使用者的真实需求,而不仅是了解他们的业务流程。__挖掘到真实需求后,我们应该去探索,有不做这事的办法么?有更简单的流程么?请先设计一个合理的工作流,然后再去设计产品

工作流分析方法

虽然说服务设计不是设计服务,然而特定工作流的工具产品真是太适合使用服务设计的方法了。我们来借鉴服务设计的思路,来讨论工作流程的分析方法。

好的设计来自于扎实的用研,先来看看用研方法。

影子观察法

这个好理解,就是像影子一样跟着观察对象,但是尽量不要去让他感觉到你的存在,悄悄的记录也好,录音也好,拍照也好,把你发现的启发点记录下来。但是这个方法需要注意的是,这个用户很可能是知道你在观察他的,那么他可能会和平时的表现不一样。所以我们才说尽量不要影响他。这种方法能够把你带到问题的现场去,让你了解整个问题发生时的环境。比如说,我们在做某司机工具 App 的时候,我们曾经要求 司机全程开着该 App, 但是后台经常检测不到,问司机说确实开了,结果为什么呢?司机路上收到微信,收到短信等等各种 App, 有的司机一路上好几个 App, 然后把我们的司机 App 挤到后台去了,被系统给杀掉了。所以这件事上责怪司机就错了,你不能不让他用微信啊。

情景访谈

我们的访谈应该走进工作环境,如果可能的话,在趁人家不忙的时候,边工作边问。

这个时候呢,一定要亲切起来,让他感觉你和他是一伙儿的,不要像记者一样一问一答,要把你的问题融入聊天中。让人感觉亲切的办法有很多,比如认可对方的观点,适当的示弱,以及共谋。共谋是个很有效的方法,虽然他最初的适用范围比较窄,但是他其实可以用在很多地方。共谋可以让你迅速的和对方站到同一边去。

情景访谈由于是在情景中,所以特别容易让他们想起一些工作的细节。在办公室咖啡厅可能就没有这样的效果。所以访谈一定要走进工作环境。

了解“和工作无关”的内容

比如用户的家庭背景,财务状况,性格特征。这个其实可以通过上面的途径去了解。这些东西看上去和工作没什么关系,但是确实导致用户在工作中一些行为的原因。

五个为什么

我们常说哪有那么多为什么,但是用研要求我们就是要有这么多为什么。五个为什么的方法就是这样。当你产生一个问题,问了对方以后,请就对方的回答继续问一个为什么,有时候可能怕受访者烦,或者受访者也回答不出来了,那一定要自己思考。一般认为五个为什么之后就问到核心了。

流程梳理的方法:

用户路径地图

那么我们应该建立一个系统的概念,对于一个工具,可能有用户,可能有后端的管理者,甚至是有可能的客户,他们都是系统的一部分。那用户路径地图呢,它反映了,我们的用户和系统的关系。要有这个图呢,首先我们要去找 Touchpoint, 可以翻译成接触点吧。接触点有很多种形式,他可以是人和人的接触,也可以是人和一个 App 的交互,甚至是一种行为。比如说,我们的司机去仓库装货,那他和仓库也是有一个 Touchpoint 的。这些点是需要用研来获取的,从之前讲的用研过程中来获取。我们找到足够的点之后呢,用线把他们连起来,就会看到一个完整的流程,如果这些点太粗略了,我们也可以有一些标注。

用户路径地图可以让我们从整体上发现影响用户体验的因素,找到问题的地方和创新的机会。然后每一个接触点呢,基本上都是一个小项目了,他可以把你的项目串联起来。

用户蓝图

它可以用来分析流程中的一部分,可能是一个接触点,也可能是几个。做这个图,你应该把大家喊到一起,尤其是开发,一起去讨论,这个流程中,前端会发生什么事情,后端会发生什么事情。有的时候接触点不是一个程序,可能是人,那一连串的工作人员会因为这件事情做怎样的事情。你就会发现在一个流程中,每一个操作中,不同的团队他们的想法和反馈。

然后大家发现这两个方法都叫图,但是我们要避免陷入形式主义的深渊。这两个方法的重点不在于你画了个什么东西出来,放在脑子里也可以。他们的重点在于研究过程。

我们的设计应该考虑整体的工作流,而不是单个的产品。用户在工作过程中接触的每 一个机器每一个人,即使不是我们的设计对象,他也和我们息息相关。