产品设计需注意 切忌过度设计

  产品设计是产品生产和营销的非常重要的一方面,在最近在产品的设计流程当中,融入了正儿八经的专职交互设计,反复体验着这种完整团队所带来的优缺点,虽流程完整,但细节困扰。其困扰之一,我感觉应该叫过度设计,实际上,过度设计一般是说技术开发中,对于逻辑复杂、技术先进的过度追求,导致了技术框架虽看似华丽却复杂难用。若说到产品功能及交互的过度设计,应该是“过度追求体验完美、需求满足”而导致的“实际体验下降 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,那么这种用户引导的差异,或许会导致产品定位的偏离。(近期某款雷声很大的新产品,正是犯了此忌。)

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

  不要一味的追求体验:

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

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

  面对需求,保持理性:

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

  最后,奉上一张小图,偶见于某产品的动态首页~参不透。

  总之,希望自己做到有所为,有所不为。

时间: 2024-08-08 12:44:06

产品设计需注意 切忌过度设计的相关文章

如何减少过度设计的发生?为什么会导致过度设计?

文章描述:避免过度设计:有所为有所不为. 最近在产品的设计流程当中,融入了正儿八经的专职交互设计,反复体验着这种完整团队所带来的优缺点,虽流程完整,但细节困扰.其困扰之一,我感觉应该叫过度设计. (呃,文章像大长今一样长~~看前做好心理准备吧.) 过度设计,一般是说技术开发中,对于逻辑复杂.技术先进的过度追求,导致了技术框架虽看似华丽却复杂难用.若说到产品功能及交互的过度设计,应该是"过度追求体验完美.需求满足"而导致的"实际体验下降 or 长期产品定位偏离 or 功能没人用

《需求设计:构建用户想要和需要的产品》——2.2 情境设计

2.2 情境设计 情境设计需要解释IT开发所面对的业务需求.情境设计之中的元素是任务.用户组.数据表及任务之间的消息.本章用4个小节分别讲述这4种元素,然后再用3个小节来讲解任务之间的依赖关系.元素之间的综合以及对情境设计所做的分析.2.2.1 任务笔者在前面说过,业务需要分割成多项任务.那么,什么是任务?如果你在公司逛一圈,并且想象一下:当办公室里的人用IT应用程序收发信息时,有红色光环从头顶冒出来,那你就会发现,这些光环每次出现的时间很短.它们就好比任务.大多数任务的持续时间都很短,一般是几

从产品方案与设计 解析过度设计的判定原则

概念 过度设计,从产品方案与设计上来讲,指盲目满足用户需求,极度追求用户体验,最后导致需求未果,产品可用性下降.主要表现在机械粗鲁地添加功能,造成产品设计路径坏死,功能堆积.复杂.重复和冗余. 说易行难.甲说这是「过度设计」,乙却认为大大方便了用户.一套判定原则显得有必要. 判定原则 设计路径坏死 从天而降(上级要求.用户要求.突发奇想等),不遵循可用性原则,也无推断逻辑,无理由.设计的逻辑路径无法复用,它的「成功」不可复制.最常见的代言词是「方便」.比如,在这加一个按钮方便用户,那么在那加个按

《重构与模式(修订版)》—第1章1.1节过度设计

第1章 本书的写作缘由重构与模式(修订版)软件模式的伟大之处,就在于它们传达了许多有用的设计思想.所以,在学习了大量模式之后,就理应成为非常优秀的软件设计人员,不是吗?当学习.使用了几十个模式后,我也曾这样认为.模式帮助我开发灵活的框架,帮助我构建坚固.可扩展的软件系统.但是几年后,我却发现自己在模式方面的知识和使用模式的方式总是使我在工作中犯过度设计的错误. 设计技术进一步提高之后,我发现自己使用模式的方式逐渐发生了变化:我开始"通过重构实现模式.趋向模式和去除模式(refactoring t

《需求设计:构建用户想要和需要的产品》——2.3 集成设计

2.3 集成设计 集成设计的主要目标是: 把任务划分到各个应用程序与服务之中. 决定数据表与数据库之间的指派关系. 以应用程序之间所传递的消息为视角,来定义集成方面的需求. 对于其他更为详细设计的来说,集成设计确定了这些设计的范围.用户界面设计可以针对每个应用程序或服务分别来做(对于服务来说,其用户指的是另一个程序),数据库设计可以针对每个数据库分别来做.尽管技术设计也可以针对每个应用程序或服务分别来做,但是在大多数的公司里面,我们都可以令多个应用程序与服务共用同一套技术设计.图2-5演示了如何

布丁徐磊:APP需作场景化设计 NFC是电子凭证趋势

徐磊于2001年参与创立北京同方微电子有限公司,历任CTO.副总裁.期间,在RF-ID(射频识别).NFC(近距离无线通讯技术)等领域实现了超过10亿单位产品销售,包括08年北京奥运会全部电子门票项目.2010年4月徐磊加入创新工场,任战略发展部总经理,参与早期点心OS等项目运营及投资.同年11月,徐磊与包炬强等5名创始团队成员共同创立布丁--北京步鼎方舟科技有限公司,着力于拓展移动互联网O2O业务. 日前,徐磊接受了投资界记者的采访,对于创业,他表示:第一,创业团队需要非常关注自己的用户或者客

产品经理不应该专注于设计解决方案而是定义问题和优先级

文章描述:关注问题,而不是解决方案. 前言:本文译自 MindTheProduct 社区里的一篇文章,原名是<Focus on the problem, not the solution>. 去年有位同学在 ProdcutTank 论坛上提了个问题,让我恨不得自己跳到台上回答他.他问:"如果产品经理定义所有的产品,那何来创新与创造力呢?"停!我简直想喊出来:你错了! 很多人新听到"产品经理"的概念,便把我们当作干扰者或说是入侵者.他们以为,我们设计产品.

产品界面视觉上的轻设计

  什么是轻设计?没有具体答案,也不是新鲜定义.轻设计已经被相关设计人士提起并运用有2年左右了,但是轻设计一直到现在仍然被常常提起,这里面有产品设计人员.网页设计师.UI设计师等等. 产品设计的"轻",可以归纳一些词语,简单.流畅.易用.明确等等,大家心里也都有自己的词语.我在这里只想谈一下移动设备上,各种产品界面视觉设计上的"轻设计"(以下皆用"轻设计"代替),轻设计很有意思,并有很强的生命力. 首先归纳一下,轻设计在现在设计中仍然常常提起和应

架构之坑系列1:重构中的过度设计与高可用银弹

这是一个坑系列,会说一些在系统设计.系统架构上的坑,这些都是我想到哪说到哪,有像这篇一样比较宏观的坑,后面的文章也会有到具体技术细节的(比如某个函数,某个系统调用)坑.总之,到处都是坑,这些坑有些是我经历过的,有些是听说的,你也可以留言说说你遇到的坑.   第一部分,我们从重构这个场景来看看系统架构的设计中过度设计这个坑.首先,我们这里说的重构,和<重构:改善既有代码的设计>这本书中的重构不太一样,这是本好书,他主要说的是代码级别的重构,这种重构是需要在编码的时候时时刻刻进行的,更多的是一种编