复杂需求如何理解

  在设计领域,人们总是喜欢简单,尽量做到视觉与极简的最佳结合。不可否认的是,这是大势,可以想象一个现实生活中本该够烦躁的人是多么不愿意复杂的东西。很多案例,google是推崇简单的,简单的界面加上优秀的反应速度,这让世界上大多数人都爱上了它。但是这简单的表面下面却是蕴含着复杂的算法代码,这并不影响你的使用,因为你需要的仅仅是这棵大树的果实,而不是树根。综上,google并非极致的简单,只不过把简单全部给了你罢了。

  复杂需求留给用户挖掘

  这是QQ音乐,至少你能够看出这正在播放歌曲,而此时你的目的就是需要一款可以播放歌曲的用具,需求很简单,所以你只要:

  找搜索框填歌名→确定回车→双击听歌→享受

  很简单,这简直和所有的音乐播放器一样,对于仅仅想听歌的同学来说,这就可以很好的满足他了,虽然可能会对下面的广告不是很满意。

  忽然有一天你买了高端的索尼mp3播放器,配置了森海的高端入耳式耳机,你很愉快的来下载歌曲,却发现只能下载普通品质的歌曲,这对于你的高端播放器和高端耳机很不公平。QQ音乐很无耻的告诉你,想要高端?QQ绿钻可以帮助你,尽管这时候你怀念酷狗,但是为了尽快下载于是上淘宝买了个绿钻,这对于你也就几块钱的事。

  搜索歌曲→确定回车→试听→点击下载→选择高品质→导入移动设备

  因此我了解到了绿钻和高品质,还有可以导入移动设备,甚至可以导入itunes,用完之后想想尽管这些流程繁琐了些,但还是蛮简单的。

  故事我不讲下去了,对于需求低的用户永远也不会去想到用那些功能,最近情人节,QQ音乐劝你去点歌,可惜点歌也要绿钻。真伤心,尽管我还没有。

  理解了么?对于有需求的用户,复杂往往是必须的,但是这些复杂对于当前的需求来说往往是简单的。人们会因为需求而忽略稍微的复杂,需求和复杂是成正比的,而复杂度在人的眼光中与当前目的也是成正比的。

  你不必刻意去寻求简单,简单是留给正处于需求环境的用户,真正好的设计不是极致的简单,而是将简单置放到用户使用过程中。

  复杂信息与简单信息

  信息永远是产品的至关重点,只有内容才能粘合用户。所以在设计的时候,交互设计师们往往会对信息的排布以及单页面信息量的多少作出或多或少的要求。

  对于手机页面而言,过密的信息量造成的直接后果是用户寻找不到自己想要的,操作上也十分容易出错误。也是将内容过分简单的放置么?一个单独页面也就几条信息,这样更容易造成用户的操作迷失,信息量的缺少让用户不得不一页一页寻找。

  所谓复杂信息的需求是指在除去不必要因素的条件下保留较高质量的信息量,但不影响操作。简单信息并不是去减少必要的信息与内容,而是砍掉不必要的设计与流程,从而让信息内容的浏览更加符合需求。

  Edward Tufte提出了两种解决方案:

  同一空间毗邻陈列(Adjacent in space)——也就是同屏陈列所有内容。这么做复杂与否取决于信息和功能的多少——比如飞机座舱就把所有的仪表盘和重要的数据全部呈现了出来,这样驾驶员就能非常直接的检索到信息并迅速作出决定。毗邻陈列提供了更直观的操作方式,加速了交互行为。

  沿时间线陈列(Stacked in time)——同前者相反,这种方法把功能分割进不同的页面里,这么做能减少用户误操作的次数,同时便于在不同的操作环节隐藏不必要的信息。更多的页面同样也代表了更多的用户体验/品牌体验。沿时间线陈列不要求用户作出迅速的决定。

  直接的表面复杂需求

  人们真正需要的是简单么?作为设计师,简约当然是首要选择。但是如今的世界,不得不承认的是,往往复杂的产品代表的是高性能高品质,间而代表了该用户的生活地位。

  为什么人们往往更追求复杂的怀表而不是很喜欢简单的电子表呢?因为这代表了他们的地位,满足了他们的外在需求。如同上一章的第二个问题中说的,所谓“夸耀效用原理”。

  当然也不能完全这么说,如after effects对于普通用户来说很难,但是那些却是必须的,因为它面向的用户是真正愿意使用它的人,这就好比飞机座椅上必须有那么复杂的设备,尽管你不需要,当然你不需要去理解。
  (来源:寒山投稿)

时间: 2014-08-01

复杂需求如何理解的相关文章

维护需求与新增需求的理解

一般来说,维护需求的项目时间都是比较紧急的,维护嘛,用户等着上线用的啊,其实在这里,我们对维护需求和新增需求的定义都不太清晰. 怎么理解呢?我个人的理解: 维护需求,是指用户提出在系统使用过程中的问题以及整合目前用户觉得需要改进系统的一些功能的需求文档. 新增需求,就是指用户在不满足当前系统使用功能的前提下提出一些不包含之前的需求文档内的新增的功能而形成的需求文档,它没有包含用户继续解决的用户bug. 因此,我个人从定义上区分,维护需求多数只是针对用户问题去修复并验证bug,当然也有掺入一些用户

互联网产品经理实现产品需求而不是用户需求

文章描述:产品经理的四点思考:不该简单满足用户需求. 文档"> 本文根据自己做产品的经验,提炼出4点思考分享给大家 淘宝鬼脚七 一淘搜索.淘宝搜索产品负责人(文德) 产品经理是个很奇怪的岗位,好像大多数人都能做,因为每个人对某个产品都有自己的看法,都能提出一些意见和想法,甚至能设计实现原理:也好像大多数人都做不好产品经理,因为互联网上成千上万个产品,大部分是垃圾,没几个产品是用户真心觉得很不错的. 我做产品经理,还不到两年,以前十来年一直在做技术.之前做技术的时候,我很看不上产品经理.当时

探讨Tumblr的理解:轻博客服务的价值

文章描述:浅析轻博客(类Tumblr)服务的价值. 一.Tumblr简介 Tumblr正式成立于2007年,自成立以来,其一直保持着非常良好的发展势头,而国内自点点网,盛大推他纷纷推出类tumblr服务以来,这个被称之为轻博客的领域收到了越来越多人的关注,本文尝试和大家一起来探讨轻博客服务的价值.欢迎大家通过微博@web20share和我一起来探讨 1.Tumblr简要发展历史: 2007年 Tumblr正式创立. 2008年12月 获得由Union Square Ventures 和Spark

互联网产品需求管理:产品管理流程

  对于互联网公司而言,产品需求管理是产品研发的核心环节,产品需求的正确与否直接影响产品开发周期.产品开发成本.产品运营成本,甚至直接决定了产品市场竞争力.根据统计:产品开发中40%-60%的问题都是在需求阶段埋下的"祸根" ,在测试阶段及运营阶段发现需求阶段植入的问题,解决的代价是需求阶段发现问题的68-200倍.      关于需求管理的故事很多,列举一些常见问题: 某天老板问起:我很久以前提过一个需求,提过以后就没下文了.产品经理无辜地说:有提过吗,是给我提的吗? 某个销售谈起:

设计需要满足用户更需要分析需求

产品开发的前期,需求方,产品经理,策划以及相关的设计师和开发人员都会对一个产品的远景提出很多的设想,作为交互设计师,我们总是希望我们的 用户获得更好的体验,试着让他们喜欢我们的网站,应用程序和启动界面.设计的原型要一再考究鉴定,确实要这样设计,用户可以接受吗?用户会按照我们的意图 去操作?我们需要不停的假设与验证,不停的优化完善我们的设计,同样你的客户也会提出很多代表用户的假设性的需求,我们是更应该满足他们还是设法说服他们 呢?这样的例子很多,同样我们需要考虑很多方面: 1.产品需求期达成共识

交互设计初体验:多参与需求的沟通

9月初,我来到新浪微博UDC部门交互设计岗位实习.在接近四个月的学习时间里,我对交互设计行业有了深一步的了解,认识到了交互设计师的一些具体职责.鉴于之前接受的知识大多来自书本或网络上的文章,在校期间参与项目的机会并不多,因此,我对此次实习做了一些总结:一方面,希望鞭策自己,在以后的工作中有所进步;另一方面,也希望能帮助刚步入交互设计行业的同学更快的适应工作,更好地学习交互设计. 个人认为,对于刚步入交互设计行业的设计师而言,在工作和学习过程中行之有效的方法可分为以下四个部分: 第一部分:了解自己

代码检视等于需求评审吗?

代码检视相信大家都非常熟悉,质量管理体系是非常重视代码检视的.然而随着软件工程技术的快速发展,代码检视的作用似乎也不再局限于只是走查一些代码层面的缺陷. 越频繁的代码检视,越有助于质量管理,越有助于需求管理! 从华为出来的QM 武老师,现在就职于腾讯,从事质量管理工作.她曾经在Tid大会上发表过在腾讯推广的"代码检视",谷歌.facebook常用的"提交前线上检视".武老师追求的是通过技术骨干检视代码,严格控制交付进入集成环节.同时武老师也在追求快交付,规定每次交付

《用户至上:用户研究方法与实践》研究之前:先理解目标用户

研究之前:先理解目标用户 2.1 概述 当着手开展一个新项目时,你的第一要务通常是了解产品(如果已经存在)及其涉及的领域和目标用户.在项目初期尽可能多地理顺现有产品和其领域知识.竞争对手和客户至关重要,这会使你不必花费时间来创建已有的知识.你可以从一系列渠道获得这些重要的信息:试用自己的产品,聆听客户反馈,社会情感分析,日志文件和网络分析,与市场部门交流,竞品分析,或是从极客用户或合作伙伴获得反馈.此外,你需要评估现阶段对于用户的理解,并开始创建用户画像.这些信息将帮助你选择合适的用户研究方法来

软件开发的非功能性需求变更

需求变更本应是客户的权力,如果确是需要变更,当然要满足客户需要.但问题是不能让变更权力滥用,把一些无关痛痒的非功能性需求变更宠惯养成堂而皇之的变更.对于非功能性需求客户总会有新的想法,项目好像总没有办法终结.以前当出现这种情况时,我总觉得很沮丧,觉得自己非常不幸,怎样会碰上这样的客户.可在读了<设计模式精解(Design Patterns Explained)>一书的一段话后,我恍然大悟,这不是我的错,世界原来就是这样子的啊,永远不变的就是变化. 令人烦恼的非功能性需求变更 在软件开发中,大家