“用户”已经成为一个负载词(loaded word)。我们总是把自己的信念、诠释、和情感一股脑附加在“用户”和他们的需求上。在几个团队待过之后,我开始意识到一个普遍存在的问题:并不是所有的利益相关者和团队成员对“用户”一词的理解都是一样的。这就是为什么在内部拥有一套用户角色集合可以很好地解决语言沟通上的问题。 然而,用户角色的问题在于它只是把单个特定的用户场景展现出来,在研究一系列连续的用户场景时,它并不是最好的工具。 矩阵图的方法透过不同场景的视角,帮助我们研究已知的、未知的用户行为和动机。我已经用这种方法做了下面的事: 创建关键受众角色 理解或验证价值主张 确定优先研究的领域和产品功能——确定我们已知的信息和缺乏的数据 找出哪些功能是非常重要的 它的本质是一个用来理解用户模式的结构化头脑风暴工具。它最好的地方在于可以很容易的“解压”(unpack)那些不同利益相关者对用户做出的假设。 第一步:画出矩阵图 我已经在多次与顾客以及工作坊参与者的交流中用到这种思考方法,对我来说3×3矩阵是最有效的。可能是因为它可以给我提供足够多的样本,而且不会过于精确——因此可以避免出现分析麻痹症。
第二步:确定重要的坐标轴 接下来需要确定我们设计的系统中可以包含哪些不同的用户(矩阵格子中所代表的不同用户群)。 我们看一个为跑步者设计的潜在社交应用。本地跑步的用户可以发布跑步路线,游客可以通过应用找到这条路线。 我们可以假想一下虚拟竞争因素。一个跑步的用户在之前某个时间发了一条跑步时间的信息,你看到后想在同样的路线上打破他的记录。亦或是当你到达一个新城市后想找个路线小跑一下领略这个城市的风光。试想一下我们需要满足用户的哪种行为属性才能能吸引用户使用这个应用? 我倾向于选择“反对”(opposing)属性。你可能不同意我的观点,然后列出如下属性和对应的用户场景。 探索(explorative) “我想通过跑步找一种感受这座城市的新途径。” 竞争(competitive) “我想和别人赛跑或者我想自我超越。” 频繁(frequent) “我经常跑步,每周几次甚至每天一次。” 偶尔(occasional) “我每周跑一次,或者更少。” 你的坐标轴可能会是这样: 感兴趣(curious) ↔ 在使用(engaged) 社交(social) ↔ 个人(individual) 探索(explorative) ↔ 竞争(competitive) 频繁(frequent) ↔ 偶尔(occasional) 游客(visitor) ↔ 本地人(local) 对于正在从事的项目,你可能知道一点当前的用户的信息,也可能什么都不知道。和我们一起为这款社交应用出点子的团队属于一个运动鞋公司,而且全部由跑步运动员组成,他们经常往来于在各地参加马拉松比赛。这个团队在之前做过一些研究,并且获得一些从新手到高级跑者各个级别人群的相关信息,同时也对使用过他们曾开发过的一款web应用的人群有些见解。 在你用此方法做练习的时候,要谨记哪些是你已知晓的用户信息,哪些是你假定的。从上面列出的坐标轴中选择两条你最感兴趣的,或者你认为值得深入探讨的。如果你刚接触这种方法,可能在抉择上有点麻烦;这时最好的做法是立刻选择两条,看看会发生什么。如果这个方向行不通,那就换一个坐标,继续尝试。
第三步:确定关键问题 我把这个步骤比作“神奇的8球”(“magic 8 ball”)。通常我会这样开始问问题,“这些用户可能想要做什么?”或者更简单的问题,如“他们想要什么?”第二个问题包含了用户想要什么和他们可能想做什么两点。你也可以这样问:“用户会感觉如何?”作为强化练习。当你想问题的时候,把想到的随手记录下来,后面会用得到。在这个例子中,我们的问题是“他们可以做什么?”或者从用户的角度,“用这个软件,我可以做什么?”
第四步:把表格填写完整 尽你最大的努力把矩阵填写完整。如果你已经在研究中有了一些见解,你可以标记出哪些是你确定的以及哪些是你认为正确但没有证据支持的。一般情况下,当你把第一个矩阵填完之后会弄明白下面两件事:你已经知道关于用户的哪些信息?接下来需要做哪些方面的研究?
第五步:迭代 当你完成上面的矩阵之后,把它放在一边,然后再画一个表格。你可以做下面的一到两件事: 1、 从你列出的问题中再选一个,如“这些用户想从我们这里得到什么?”或, 2、 保持问题不变,把其中一个坐标轴换成别的。 画完表格之后从上往下填写矩阵表格,切记这一步这是一个头脑风暴的过程。快速记录稍后可以完善的想法比浪费时间更重要,所以每次迭代都不要用太久。 当你已经竭尽所能完成本次迭代后,请重复以下步骤:再选一个问题,或换另一个坐标轴。 这一步,你们的团队成员最好在选择问题和坐标上观点保持一致。 完善和重复。你会发现,在短短一个小时的时间内就能完成很多矩阵图,即使刚开始的时候进度会很慢。 分析&主要观点 完成上述工作之后就该着手寻找“模式”(patterns)了。我们看一下可能会出现的情况: 假设(assumption)VS.知识(knowledge) (责任编辑:admin) |