避免过度设计:有所为有所不为

最近在产品的设计流程当中,融入了正儿八经的专职交互设计,反复体验着这种完整团队所带来的优缺点,虽流程完整,但细节困扰。其困扰之一,我感觉应该叫过度设计。
(呃,文章像大长今一样长~~看前做好心理准备吧。)

过度设计,一般是说技术开发中,对于逻辑复杂、技术先进的过度追求,导致了技术框架虽看似华丽却复杂难用。若说到产品功能及交互的过度设计,应该是“过度追求体验完美、需求满足”而导致的“实际体验下降 or 长期产品定位偏离 or 功能没人用”的悲惨结果。

为什么会导致过度设计?

原因1:一味追求体验

所谓大团队、多部门的互联网公司,在开发产品时,设计资源往往是产品部门无法把控的,一枚宝贵的设计师,往往曾经跟过很多产品,总是被派来派去,而不是长期跟进某一个产品。因此,再如何苦口婆心的为团队成员灌输市场情况、产品定位、项目目标,也不可能形成合作过程中的默契感。没有默契,就没有产品归属感,只有流程管控和死板的执行。

如此工作框架下的设计师,其首要目标很难与产品发展保持一致,而是要为自己的设计作品照想,要让这个产品中自己负责的设计部分,被他的主管认可、被主管的主管认可。这合情合理,天经地义。但是,他的主管,却与我们的产品很少有交集。这就是苦逼的开始。

在这个时候,设计师必然希望每一个设计细节都能考虑周全、设计完美,几乎希望摒除一切不好的设计,以在其老大面前证明自己的能力。但是,假如眼前这位设计师,没有眼观六路、耳听八方的强大能力和视野,则极有可能会被这种追求完美的设计思想所拖累,让一些设计细节走了样。

设计师挖空心思,拿出一份自认为近乎完美的作品,并苦口婆心说服所有人相信并执行,即使隐约感觉到不对,但乍看似乎完美无缺。推进到开发或上线测试阶段,真正的问题从走样的“完美设计”当中渗透出来,淋伤的则是产品计划,傻眼了。重新改、重新写代码、推迟发布。

这种过度设计,不止伤害团队和产品,还会浪费时间:

• 挖空心思的追求完美,比常规思路的设计,多耗时3天。
• 产品与设计师一起确认设计细节,在“非预想的设计细节”方面博弈一番,产品说“我没见到过这种设计”“开发和维护成本大,浪费时间啊”,设计说“这种体验确实是更好的”“那个竞品的模式真的很恶心”,多耗时1天,并且徒增设计师、产品的挫折感。
• 开发非系统默认的精致设计细节,多耗时3天。
1周,就这么浪费了。就是这样。

原因2:一味的满足需求

研究用户需求时很容易陷进去,然后被非理性所控制,假如自己没有足够的经验,而身边又没有靠谱的人提醒,就会有一堆本来不是需求的需求,成为开发任务,所以才有了后来滥大街的一句口号“产品减法”。最苦逼的是技术:“辛苦写好的代码,说减就减,TMD的当初都干嘛去了,一群SB!”我往往都随声附和,暗骂一声自己。。

以下两种常见的情况,会导致“过度满足用户需求”的问题:

一是对用户声音缺乏筛选。用户不是产品人员,其在使用产品时,提出的问题、表现出的困惑,一定是偏自我的感性意见。“我不认识这个按钮啥意思!”“我感觉全部展示出来才好看!”“这个功能特别不方便!”

二是对需求研究无法保持理性。“假如自己给自己评论会怎么样”“要告诉用户不能这样做啊,直接砍断不好吧”“用户想这样,然后在那样,然后在这样,就会出现困惑了呢!”“直接把入口铺出来,这样才最方便!”

总之,当在理解用户需求时,如果不能以一种正常、理性的心态推演使用场景,很容易被上面这种问题带到沟里,最终导致过度设计。(身边靠谱的产品人,多是理性起来不是人的射手座~~~呃)

功能以及交互上的过度设计,最终可以导致一系列后果:

1、浪费时间,延误甚至失去市场机会!
2、在过度设计的博弈中自我耗损,伤害士气!
3、过度设计的功能,看似华丽,却无人问津,白搞了!
4、最可怕的问题:过度设计的细节,导致错误引导,培养了错误的用户习惯,并且这一过程,不可逆!

第4个问题,有必要详细描述一下:

• 假如只是一个功能入口,入口A比入口B更加便捷,用户只会记住A,而忘记B。假如产品设计之初,希望用户在途径B时,享受更多的推荐或引导,那么B的这种作用就发挥不出来。而这个时候,再想删掉A,用户会骂死产品。若想修改A,则是动框架,耗费成本。

• 假如是一套用户使用流程,流程A比流程B更加舒适自然,但是如果没有考虑到A和B对于整个用户引导的差异,而草率的选择了A,那么这种用户引导的差异,或许会导致产品定位的偏离。(近期某款雷声很大的新产品,正是犯了此忌。)

如何减少过度设计的发生?只能对症下药。

不要一味的追求体验:

•  一是,让产品设计师更多的向产品靠拢,增加默契感,形成产品归属感,在做事情的时候便可以有效的规避不信任的细节争吵。

•  二是,改变不合理的“产品负责制和确认层级”机制,产品负责的归产品。这样才能在通篇考虑“市场、定位、时机、成本”的时候,做到相互信任和理解。只有让产品横空出世,整个产品组才能真正有所收获,而不只是通过一个设计作品来增强自己的满足感。实实在在的成功最重要。

面对需求,保持理性:

至于产品人,只能多犯错多磨练,让自己靠谱多一些。总之,在产品创意时不失感性,但在面对需求时应该保持理性。幸运的话,进入一个整体靠谱、左右权衡的经验团队,会让自己的成长方向更正确。


最后,奉上一张小图,偶见于某产品的动态首页~参不透。
总之,希望自己做到有所为,有所不为。
@劣松 文章地址:http://www.liesong.me/?p=344

产品管理:用机制降低风险

最近一直在跟的一些项目,过程中出现了一些反复,原因有很多。深入分析一下问题根结,希望以后能避免。

关键词:产品负责制、确认层级机制、产品脊梁、靠谱

问题:

1、项目初期,产品原则已经开会统一、皆大欢喜,但中期却在产品原则上出现分歧。甚至在产品面临上线时,还有人为该产品赋予新的定位。

2、产品设计环节中,在产品需求和定位已确认的情况下,纠结在“不符合需求、偏离定位”的设计细节,僵持不下、浪费时间、拖垮精力。

3、跨部门合作的项目,设计部门提交的工作结果,经常被他们自己的上层或左右推翻重来,即使对产品有利,却伤害整个项目,伤害自己人。

根据这些问题,需要问很多为什么。

为什么初期统一过产品原则,中期却出现原则上的分歧?“发起分歧者”所具备的必要条件是什么?

首先需要问公司:产品负责制,到底有没有明确和落实?其实,产品人员已经也应该,把对产品的长期责任,承担在自己身上。但是公司层面和总监层面如果没有强有力的确认产品负责制的归属,我们这种自我承担的产品负责制,永远不会在关键时刻发挥作用,而只会左顾右盼。

在产品负责制尚不明晰的情况下,即使团队核心成员开会确认了产品原则,也永远不会有一个强有力的角色把产品原则贯彻到每一个阶段,初期产品定位和产品原则的会议确认,是没有力度的,只是表面上的统一而已。

原因很简单,当一切顺风顺水、条条大路通罗马的时候,旅游团众大佬必然跟着美女导游就OK了。当路遇挫折时,导游就算熟悉路途中的险恶,也仍然不是无法把自己伪装成团队的菩萨,左右不了各位大佬的想法。(默契,可以克服这一问题。但在大公司的营盘里面,想培养一个默契而完整的项目团队,一般是可遇不可求的。但默契的产品小组还是有的。)

在以上这种情况下,发起分歧者有什么必要条件?一是长期跟进产品,了解最初的产品原则和定位;二是了解整个团队的工作重心和产品市场情况,而不是只熟悉自己所管部门的情况。可悲的是,熟悉了以上两点的人,往往不会做出不靠谱的决策,而去伤害整个项目。

既然已经确定了产品需求,为什么会出现“不符合需求、偏离定位”的设计细节?为什么会在这种问题上浪费时间?

这种问题出现非常正常,当设计人员没有做充足的竞品分析,也没有充分理解产品的情况下,总会在设计时出现偏差。只要产品人员说明需求和修改原因,说服设计人员回归需求即可。可怕的是“僵持不下”,设计人员坚持己见,认为设计细节是正确的、靠谱的、符合产品需求的,产品人员却无法认同。僵持不下时,应该搁置问题,继续推进项目,而不是在这种问题上纠结一个下午,还把各种用户调研、应用实例搬出来说理。

最终做决定时,如果依旧僵持不下,那么谁对产品长期负责,谁做决定。谁对产品长期负责?回归的上一个问题。

为什么“工作结果”可以推翻重来?谁赋予了提交者“提交的权利”,又是谁赋予了推翻者“推翻的权利”?

首先要问的问题是:是不是根本没有明确“确认层级”的工作流程,或者只是口头明确、表面默契而已?
比如一个设计稿,当然要由直接负责人A确认,没有问题了,再交到下一步去执行。那么这个负责人A需要评估:自己是否能够保证这一个确认结果是最后结果。如果不能保证,那么再提交上一层的负责人,让他确认。但如果上层负责人曾经授权了负责人A的确认权限,就不应该在A已经确认之后,轻率的推翻确认结果。

在这种确认过程中,应该在每一个项目实施之前明确“相应的设计工作,需要有相应的确认层级”,这一点至关重要!“确认层级”都不明晰的情况下,首先应该检讨的不是设计质量没有达到要求,而是为什么会出现这种流程上的漏洞,让不符合设计质量的东西推进到下一步骤。漏洞不堵住,就没有资格反复插手,这样既伤害团队,也拖垮自己。

相反,当指定了项目设计工作的确认层级之后,再出现提交设计稿不合格、推翻设计工作不符合流程的情况,就可以明确的质疑“提交的权利”和“推翻的权利”,是否符合“确认层级”的流程。这个时候,是能力问题的就调整确认层级或更换负责人、是流程问题的就贯彻流程,比大家互相装无辜更加务实。

最后感叹一下,产品经理是妥妥的炮灰,哪个环节出问题,都可以揭出产品规划和项目管理的漏洞和伤疤

一个产品项目,从立项、交互、视觉、开发、测试等各个阶段,总会因为各种问题而反复伤害。尤其是跨部门合作、多环节配合的流程,伤害问题发生的隐患比比皆是。这个过程期间,产品经理的职责,就是想尽办法,避免各种伤害的发生、避免各种伤害打击到核心成员、伤及团队重心。

可悲的是,在大部分环境下,卑微的产品人员不仅无法预估各种隐患问题,对于已经发生的伤害问题也没有足够的防备资源和职权。这个时候,产品经理,就是妥妥的炮灰,众口一铄,灰飞烟灭。最后,产品经理仍然必须站起来,拖着被各种问题所累的核心成员,继续把项目推进下去。

不知道这种情况,在其他公司是否常见。当没有固化的产品负责制和确认层级管理机制的时候,深埋问题的跨部门团队开发产品,然后暴露出一堆问题,一遍又一遍的伤害每一个产品。所以,这种公司总是出现一堆一堆的打折产品,承担着一堆又一堆不给力的数据和市场境况,最后担责到产品人员身上,该调走的调走、该跳槽的跳槽,再招进下一批未知轻重的欣欣向荣者,如此反复、以至无穷。

关键角色位置的靠谱牛人,是产品的脊梁

产品团队,碰到这种复杂的情况,唯一的救命稻草,就是产品各环节的关键位置,有靠谱的关键角色把持,然后这类关键角色需要保持持续的头脑清醒、精神集中,在任何阶段都能回溯最初的产品原则、评估当前的团队重心和高层要求,统一麾下执行者的行动,并说服高层。

从这个角度讲,没有那么多流程管理和部门配合的小团队产品和创业公司产品,要更加安全、更加靠谱。近期组里的一个小众产品,没有大资源投入、没有多部门合作、没有高层压力、没有战略意义,虽然选择了一条难路,但整个产品从设计到运营,让外人看来,显得张弛有度、节奏明确,这就是一个明显的例子。

只要人靠谱,做什么都是靠谱的。如果人本身不靠谱,在任何角色上,都会出问题。至于什么问题:细节不到位、文档及版本控制逻辑不清楚、决策前后矛盾、协调成员配合乏力、工作重心聚焦不正确、沟通不主动……比比皆是。

希望自己靠谱一点。
@劣松 文章链接:http://www.liesong.me/?p=334