为了设计而设计
- - 幻风阁|kent.zhu'sBlog我有个习惯，每天晚上睡前会搜罗一遍最新的App用用. 最开始的时候ios的App还相对比较朴实，强调功能的实用性，后来不知何故吹起一阵ios的App必须足够精美的怪风. 于是乎，各类App纷纷上演换装游戏，一个比一个做的精美，即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……. 上周末跟Tony和Angela在下厨房喝茶闲聊，我说目前的移动产品设计可以分为2类，一类是做给用户用的，一类是做给设计师们欣赏与收藏的.
过度设计：有所为有所不为
标签：
设计
| 发表时间：2011-08-22 12:46 | 作者：劣松 Guan
出处：http://ucdchina.com/rss/all
最近在产品的设计流程当中，融入了正儿八经的专职交互设计，反复体验着这种完整团队所带来的优缺点，虽流程完整，但细节困扰。其困扰之一，我感觉应该叫过度设计。
过度设计，一般是说技术开发中，对于逻辑复杂、技术先进的过度追求，导致了技术框架虽看似华丽却复杂难用。若说到产品功能及交互的过度设计，应该是“过度追求体验完美、需求满足”而导致的“实际体验下降 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，那么这种用户引导的差异，或许会导致产品定位的偏离。（近期某款雷声很大的新产品，正是犯了此忌。）
如何减少过度设计的发生？只能对症下药。
不要一味的追求体验：
• 一是，让产品设计师更多的向产品靠拢，增加默契感，形成产品归属感，在做事情的时候便可以有效的规避不信任的细节争吵。
• 二是，改变不合理的“产品负责制和确认层级”机制，产品负责的归产品。这样才能在通篇考虑“市场、定位、时机、成本”的时候，做到相互信任和理解。只有让产品横空出世，整个产品组才能真正有所收获，而不只是通过一个设计作品来增强自己的满足感。实实在在的成功最重要。
面对需求，保持理性：
至于产品人，只能多犯错多磨练，让自己靠谱多一些。总之，在产品创意时不失感性，但在面对需求时应该保持理性。幸运的话，进入一个整体靠谱、左右权衡的经验团队，会让自己的成长方向更正确。
最后，奉上一张小图，偶见于某产品的动态首页~参不透。
总之，希望自己能做到有所为，有所不为吧。
相关 [设计] 推荐：
杯盖设计
- Yu - 创意设计-有趣、时尚、另类的创意微向上的设计，在倒水完毕的时候可以让水滴顺着杯盖回流到杯子中，而不会随意的滴下来. 虽然是细小的设计，但是考虑的却是生活的便利.
再设计Redesign
- Mark - 腾讯CDC 一个网站的核心是它的功能和内容，而设计则决定了这些功能、内容如何被组织和展现出来. 对已成功的网站进行再设计——重新构造它的组织和展现形式是具有挑战性的. 偏偏有设计师喜欢迎难而上，尝试对facebook、google这些著名网站进行概念设计. 他们通常有两条思路，一是对现有问题挖掘然后改进，二是提出完全创新的想法.
简约设计
- - 淘宝网通用产品团队博客写下这个标题，那么首先得要明确什么叫简约. 简约就是让用户操作简单，让用户更快的达到自己的目的. 一个产品在于解决一个需求，如何让用户最好的完成需求就成为一个产品经理首先得要解决的问题. 那么在日常工作中，我们又有什么可以做的呢. 在《简约至上》里面有四种策略，但是有的东西太高级了，在平时的工作未必能够用得上，所以我自己来提炼一下，看看日常工作中能够遇到并且可以解决问题的方法.
再设计Redesign
- 小趴 八足趴 八足 ramener - 互联网的那点事...一个网站的核心是它的功能和内容，而设计则决定了这些功能、内容如何被组织和展现出来. 对已成功的网站进行再设计——重新构造它的组织和展现形式是具有挑战性的. 偏偏有设计师喜欢迎难而上，尝试对facebook、google这些著名网站进行概念设计. 他们通常有两条思路，一是对现有问题挖掘然后改进，二是提出完全创新的想法.
HBase表设计
- - 互联网 - ITeye博客默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据， 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按 照 region分区情况，在集群内做数据的负载均衡.
ODS设计
- - 开源软件 - ITeye博客在一般的数据仓库应用系统中，根据系统体系结构的不同，数据仓库设计的内容和范围不尽相同，并且设计方法也不尽相同，下面的两幅图示分别表示带有ODS的 数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构. 本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同，并且重点介绍带有 ODS的体系结构中数据仓库的设计方法.
HBase Schema 设计
- - IT瘾-devHBase 与传统关系数据库（例如MySQL，PostgreSQL，Oracle等）在架构的设计以及为应用程序提供的功能方面有很大的不同. HBase 权衡了其中一些功能，以实现更好的可扩展性以及更灵活的模式. 与关系数据库相比，HBase 表的设计有很大的不同. 下面将通过解释数据模型向您介绍 HBase 表设计的基础知识，并通过一个例子深入探讨 HBase 表的设计.
HBase RowKey 设计
- - IT瘾-dev1.1 RowKey对查询的影响. HBase中 RowKey 用来唯一标识一行记录. 在 HBase 中检索数据有以下三种方式：. 通过 get 方式，指定 RowKey 获取唯一一条记录. 通过 scan 方式，设置 startRow 和 endRow 参数进行范围匹配. 全表扫描，即直接扫描整张表中所有行记录.