设计

己亥的反思

. 7 min read . Written by seki

很感谢单位没有要求我做年终总结,总结并不是没有必要,而是在我看来,“报喜不报忧-感谢-畅想未来”这样的套路是一件效率极低的自省方式——只保留了按部就班成功的经历,最值得回顾的踩坑过程却完全被忽略。

避免为炫技而满足“兴奋型需求”

这一反思源于Dashboard产品0-1阶段中的某个临时性需求——当时需求方要我在页面中加入“流水信息”模块,显然,这类信息很适合使用“时间轴”形式呈现,然而当时我们所依赖的组件库尚未提供这一模块,于是,在与各方讨论后,我们决定开始造这个轮子。

除去事件文本、时间等基本信息外,该产品的流水还有一个特点——大多具有明确的事件属性,结合Dashboard需简化文本的基本原则,我决定为时间轴模块加上icon,增强其可读性。

https://experience.sap.com/fiori-design-web/wp-content/uploads/sites/5/2016/11/Interaction-Search-1.png

画稿→对接→标注→交付,一切都那么顺利,直到前端同学问:“这个icon对应的信息从哪里获取?”我才幡然醒悟——如果在时间轴中加入事件属性,必须要求后台人员在录入时配合,而这将会导致数据结构的改变,至少,这会影响一部分用户预期的工作内容,而在一个0-1阶段产品中,这是不可接受的,更何况,当前开发面临着紧张的交付时限。

好在我有提供默认icon,于是我告知前端——“先全部使用默认,为后续迭代铺路即可。”勉强回避了重新改稿的命运。


数日后,我接触到了kano模型的概念,才意识到之前的失误是如何诞生的。

简单来说,kano将用户需求按优先级排成了五类——基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求,显然,“时间轴式的流水”是基本型需求,而“带icon的时间轴”出乎用户预期之外,算是兴奋型需求。

“兴奋型需求”是正面的,但它有一个前提“当用户对产品没有更多明确需求时”,这种情况下如果做出兴奋型设计,用户满意度会显著提升,换句话说,兴奋型需求是高级的锦上添花。

而我参与的产品中,用户存在“浏览者”和隐藏的“操作者”两种类型,如果只讨好表面用户,满足他们的兴奋点,会反过来成为隐性用户的“反向型需求”,产生附加工作。


人们希望枯燥的工作不那么平淡无奇,期望通过他人的认可产生精神上的满足,作为设计师,最大的满足莫过于做出天马行空的设计。这些创新点甚至还能在将来的晋级、求职面试中秀肌肉,阐述自己在产品中设计过怎样的"Aha moment"。上面的故事,就是这样的一个自我满足过程。

可怕的是,这种“兴奋型需求”甚至能感染协作中的其他成员,毕竟,对于甲方、上司、PM来说,这同样是一个兴奋点,而这种兴奋会让人盲目。

例如,当我在与需求方技术PD阐述“用icon代表流水属性”这一设计点时,对方表现得十分赞同,并提议:“我们在后台录入时加入属性就可以”,却同样忽略了实际落地时会造成的麻烦。在被需求方认可后,设计师更会变得飘飘然,从而进一步低估了项目顺利落地的工作,让设计点成为新的大坑。

此外,兴奋型需求会让设计师和团队过分关注“设计点”,而产品体验是一个完整的过程,是“线(flow)”不是“点”。

正确的做法是把设计点作为需求提出,并且,这些需求还需要进一步发掘、验证。另外,满足兴奋型需求的设计几乎不会出现在0-1阶段的toB项目之中。

或许将来,我能像交互老手般一眼看破产品设计点,但现在必须远离自我满足。

杜绝团队KOL的存在

让我们来回顾一种场景,它几乎出现在每个人的学生时代:教师在台上讲课,而台下互动者寥寥,一般来说,只有那么几个用工刻苦的学生或者学委进行互动、提问。总之,你会发现不论是讲课还是活动,带头发言的永远是那么几个人,而其他人很少有发言,过去,我也往往是沉默的大多数中的一员。

教师很苦恼,如果学生不互动,他无法了解自己的教学进度是快或慢,如果全班不论成绩好坏都能积极参与互动,至少教师可以把握全班平均水平,然而现实是参与互动的往往是成绩佼佼者,这反而会影响教师对教学质量的判断。

沉默者也很苦恼,因为他们的脑子里有无数个疑问,但却不敢提问——一方面,自己并非始终集中着注意力,如果提问的知识点已被讲过,或是提问过于肤浅,这无疑都会很窘迫,于是,沉默者们低下头继续沉默。

对于那些活跃学生而言,这也未必是一件好事,自己对知识的查漏补缺终究有限,如果他人的提问内容自己已经了解,那就当作复习一遍,无伤大雅,而如果有问到自己不熟悉的内容,那就再好不过。总之,无人互动的课堂,对任何人都不是好事。

“沉默的大多数”是人类社会的一种普遍现象,它并不仅存在于课堂,也出现在职场中。

对于体验团队而言,这种现象往往是危险的,因为做体验设计非常需要发散思维。

有的人喜欢在团队中“建立威信”,让自己的思路不被挑战、不受质疑,这样的人在工作中会更有话语权,更能够决定产品方向,我将这种现象称为“团队KOL”——他们未必是产品经理或是leader,只是搅浑了原本平等发言的团队氛围。

这并不是“外科手术式团队”,而是单纯的一言堂,其他成员成为沉默大多数,堵上了原本发散思维的道路。

在过去一年中,我几乎成为过团队KOL,也目睹过团队KOL的形成,或许很多时候仅凭一己之力无法改变整个团队的氛围,毕竟,如上文所说,保持沉默是人类的普遍行为。

此外,并不能仅限于避免“自己成为团队KOL”,或许将来我会成为leader,改变团队成为我的第一要务,那时又会有很多有趣的尝试,例如改良版的头脑风暴——要求每个人将发言内容写在纸上,避免互相干扰。