如何将访谈融入设计

关于访谈技巧的书有很多,一般是为了收集需求、了解用户,属于用户研究。在做个人项目、实习的时候也尝试、参与过访谈。但是在津津乐道书中提及的一两个小技巧的时候,却对如何将访谈结果应用到设计上感到困惑,似乎访谈和设计部分仍是分离的。

在本科课程中基本不需要我们进行访谈,需求都已经设定好。在需求课上,只有为了写文档让小组之间进行需求的交换时有过「类访谈」的沟通。基于组员们捏造的产品需求在沟通上也常常前后矛盾,无法模拟真实场景。后来做了个人项目,没有找准目标用户,被程序员同行以尖锐的问题和不断的离题所打击,所以就一心想找到所谓的「访谈宝典」,认为掌握了访谈技巧就可以窥探到用户的真实需求、所见所想了。在实习的时候,作为记录员参与了用研同事主持的访谈,了解了行业内的访谈流程。其中,「访谈技巧」似乎更多地运用在了前期的准备与后期的总结上。

在这些过程中,对我而言,访谈似乎一直作为一件脱离设计的事情而存在着。为什么要访谈呢?我可能会回答为了获取用户需求、更好地了解用户(正如第一段所说)。实际上可能是因为在交互设计的流程中,访谈被强调、被需要。一些作品集中,访谈就这样被展示在 Persona、原型之前,作为一个步骤存在。

前几个月导师受某公司邀请,去协助他们的设计部门重新设计现有产品,我也跟着去了。产品主要用于公司内外部沟通、跟踪工作进程。在重新设计时,前后经过了用户行为观察、Persona、用户情境故事、用户访谈,最后根据这些材料产出交互原型。这也是我写这篇文章的原因:第一次清晰地看见访谈是如何融入设计。

在经过一系列的行为观察、Persona 构建等常规做法后,我们终于看到了原有产品的界面和架构、流程,这时才了解到这款产品有多复杂。原有产品没有经历过常规的设计过程,连产品内名词都由老板确定,拗口又难以记忆。之后伴随着对不同用户角色的访谈,我们深入发现了原有设计中的几个问题:

  1. 以老板为导向,首先考虑老板的需求,并以此为出发点展开。没有考虑真正使用系统的用户——他们是怎么想的,他们一般有哪些行为与操作,使用习惯如何。
  2. 由于第一点,老板提出了他所想的,没有确认「所说即所想」,就为了方便老板查看进度,把所有功能都堆砌在一个页面,层级关系复杂、混乱。
  3. 在参照竞品时,直接使用了常见的结构,没有考虑不同角色的需求。

在访谈过程中,根据划分的不同角色邀请了对应的1~2位用户。询问了日常事务,在使用中满意的部分以及为什么,还有期望、遇到的问题,等等。当访谈结束,所有调研得到的资料都摆在桌上时,所要做的就是将结果融入设计了。

其实从访谈的结果中,我们不难发现,真实用户的所需所想与面向老板、空想设计时构建的有很大不同,其中管理层用户与执行层用户所关心的又不尽相同。如果只是维持原有结构,即常规结构,的话,将会很难切合不同用户的需求。所以在重新设计之后,推翻了之前的层级结构,按照不同用户关心的部分进行展示。

神奇的是,在重新设计后,我们开始进一步反思老板提出的需求。发现老板提出的想看到、想了解的部分,未必是他真实想看到的。如果说之前的系统是一张铺开的地图,现在则是归档了的地方志。访谈的结果融入设计后,得以将系统进一步拆分,降低了复杂程度、学习成本。

想到 Alan Cooper 在 UXPA 上的演讲,不要停止对设计的质疑与反思。

当访谈缺席,没有掌握真实用户的时候,设计方案难以站稳。而有了访谈,通过一定的经验与结果分析,让每一处设计都有了依据,能够在被询问「为什么」时给出解释。