登录 |

分类“UCD”的存档

« 较旧文章 较新文章 »

在这个场景中,你发现了哪些需求?

1、产品设计过程中,我们会经常像编剧一样,尝试模拟用户的各种使用场景,以此来发现需求、验证设计。我们叫这种方法为“情景设计”。

2、一般,情景设计是我们在用户访谈和需求分析的基础上,围绕产品思想,撰写出来的“剧本”。设计师在尽最大可能做着合理的“编剧”,并试图让“剧本”可以对产品设计有用。

3、比如,我曾经设计过的这个《老郭采购记》

4、注意,剧本必须有这么两个基础:人物、使用环境。

5、实际上,在互联网产品设计时,我们经常可以,让设计源于网络用于网络。
比如,我们可以通过关注网友在论坛的帖子、博客,发现需求。
无论是角色设计还是情景设计,这样做都可以让设计更加真实,有效。

6、这里,发现了一个典型的订机票的场景:订张飞机票真是麻烦快照

7、通过这个场景,你发现了什么需求和问题?
如果,你是银行负责互联网方面的产品设计者,这个场景让你得到了什么?
如果,你是订机票的旅行公司,这个场景让你得到了什么?

如果,你是支付宝的产品设计师,这个场景让你得到了什么?

8、详细回复,建议发到这个话题:http://ucdchina.com/topic/56

关注各网站的布局调整

1、前不久,friendfeed.com把主导航从上面,移到了右侧。现在,又改到了左侧。

2、现在,twitter.com把页签(相当于二级导航)从主内容区的上面,移到了右侧(同时下面还有辅助信息)。

3、除了friendfeed和twitter,还有不少2.0网站都在做着这样的,把导航拿到侧边的布局尝试。

4、放在左边和放在右边主要考虑的是眼睛,而非鼠标。但,这都不重要,重要的是,从占高度变成了占宽度。
我认为这跟宽频越来越多有关。当然,我相信他们在相互借鉴。

5、facebook.com也在不停的做着各种布局尝试。不同的是,facebook把本来在左边的东西,不停的尝试拿到上面或下面,用各种花样和方式。
为什么?在给广告留空间?似乎不是的。

6、自从Yahoo收了flickr.com以后,flickr就像被人点了穴,设计上一直停止不前。
前几天,flickr加强了一些SNS的功能,同时也在布局上作了调整。

7、不同网站,不同用户习惯,不同复杂程度的类目,都不能套用同样的布局。
这些网站最近做的,一些界面布局上的调整,值得研究、分析、学习。

.
关闭评论,想讨论,发到这里:http://ucdchina.com/topic/46

Design IT.(2),关于好设计

对于什么是好设计,一万个人那里至少有一万零一个答案。每个人都有自己的答案,有的人还不止一个答案。

老师说,一定要在设计里灌注自己的思想,有了自己的思想你的设计才有灵魂,才能是好的设计。
工作后我发现,“如果一个设计只有设计者的思想,那么这个设计简直跟大便一样”。大便之后你会感觉到爽,别人却会被臭到;只有设计者自我思想的设计,设计者爽了,别人会很别扭、难受。这个别人包括老板、同事,特别是用户。…

在设计公司的时候,老板说,设计一定要好看,一定要让客户喜欢,客户不喜欢你的设计等于零。赚不到钱的设计不是好设计。
后来我发现,凡是客户满意的设计最后到了市场上,通常都是被用户臭骂的。因为那些挺着啤酒肚的客户,品味总是低于他的用户。

在证券公司的时候,老大说,设计一定要合理,严谨,不能出半点差错,功能要强,页面上需要的操作都得合理的出现。
后来,我们的产品使用者,如果不经过一周的培训,根本不会用我们的稽核监控系统。因为这个系统很强大,很完善。

当我们发现功能越来越多,产品架构越来越复杂。页面内容区越来越小,辅助导航区越来越大,所有人都没有办法了。老大不舍得精简,也不能精简,因为那些东西“多少都有用”。我们更不敢做精简,因为老大说了算,我们不能乱想。
后 来,老外顾问告诉我们:“少,就是多”。设计不需要你把所有的功能都摆在他面前,而是先满足他们的基本,挖掘深入需求,“当然想要时,找一下,能找到”, 这就足够了。比如,网站首页的帮助信息区域,哪怕放在页面最底,只要用户需要他一样可以找到;就算你放在首屏正中间,用户不需要一样看不到。

我恍然大悟,“原来好设计就是把不重要的都隐藏起来,需要的时候能找到就行”。于是,我开始在做设计的时候,尝试依据“用户的使用轨迹”来设计。那个时候我们还根本不知道什么叫“角色”、更不知道什么“场景设计”。
这个“进步”让我成了“高级设计师”,因为老大发现我的设计总是比别人更直接明了,不繁复。而且,我还总是能站在“用户使用”的角度,向他提出关于产品规划上的思路建议,很多被采纳。

自己带团队做项目后,我发现“把不重要的都隐藏起来”这招,根本不灵。我遇到了几个重大的问题:
1、需求分析的越细致,越耽误时间。 而且后面需求的变更或者整合,总是会牵扯到大局。
2、我的时间、人力根本不够完成那些详细的近乎完美的强大功能需求。

慢慢的我总结到:“少,就是多”,不只是要“表现”的少。
那些我站在“用户使用”角度,挖掘出来的很得意的需求,其实根本不值得做。“在条件有限的情况下,设计就是如何更好的满足大部分人的大部分需求”。
同时,随着web2.0的出现,产品的迭代越来越快,“把多余的都去掉”这种思想在互联网领域越来越受追捧。

随着以“简洁”、“Ajax”两个词为基本特征的“2.0式设计”出现以后,又出现了一个变态的现象:我们在不停的追求“这个细节能不能在交互上更人性化一点”、“这个跳转窗口能不能去掉,用弹出层如何”,… 我们很多所谓的“交互设计师”偏离了人机交互的本质,被同伴称之为“搞点花样的家伙”,甚至经常因为花样太多而被排挤。因为,花样总是要耽误时间的。

如是,终于在某一天,拿着一堆“很眩交互效果”去展示被否定后,我总结出了今天我对“好设计”的观点:
好设计首先要明白“解决什么问题”,然后分析“用什么解决”,然后设计“具体怎么解决”,最后在条件允许的情况下思考“这个解决办法是不是可以更好”。

总之,好设计就是用最低的交互成本帮助用户解决问题,并获取商业利益。和什么交互方式无关,和是否眩目更无关。

.

.

PS: 《Design IT.》接下来的两篇是,“Design IT. (3),看不懂数据”、“Design IT. (4),团队和决策 ”。
(《Design IT.》系列关闭评论,请在你自己的博客用“文章”回复,或者将你的文章发布到UCD大社区里。咱们可以把这些文章都聚合成话题)

微软,你睡醒了吗?

Google再次给了我惊喜。(http://google.com/chrome)

1、速度,快得让我有点不适应;

2、兼容,使用Webkit内核,标准支持好,前端人员这次没有骂娘;

3、细节创新,如果你只用一个浏览器,无论是哪个浏览器。你都会觉得创新的细节点很多很多。其实也不是什么创新,很多都是别的浏览器有了的亮点,他吸纳了而已,主要是大胆的做了很多减法;

4、简洁。几乎能去掉的都去掉了

5、很符合体验设计的规则:有用、能用、好用,创新…

6、更多设计上的体验我不再多谢,请关注这个话题的更新:关于Google Chrome 和它的设计
.

ps:不过,保持了google一贯的毛病,小问题很多。
再ps:支付宝什么时候可以在IE之外用呢? 唉…
还ps:腾讯会不会拉上Google去南山法院打官司?

1块钱的小包能赚多少钱?

1、旁边座位某设计师在某B2C网站意外发现了一个很好看的小包,促销价1块钱。
注册用户、填写详细资料、联系方式后才能下单,每人只能买一件。
小包刚送到,大家都来看,挺酷。除了包还有会员卡、爱心卡。

2、快递费10快钱。 这个包总价值11元。

3、初步估计小包的进价不到1元,快递费该B2C网站应该只需支付4至5元。
事实上,该网站这笔1块钱的生意至少赚了5块钱。

4、该设计师通过这笔生意已经成了该网站的用户。并同时让5位以上同事,都知道了这个网站,印象深刻。

5、B2C网站平均每新用户的推广成本在10块钱左右。
事实上,该网站这笔1块钱的生意至少赚了15块钱。

6、B2C网站平均到达每目标客户的推广成本在1快钱左右。
事实上,该网站这笔1块钱的生意至少赚了20块钱。

7、也许,还能把这笔生意赚到的钱,计算的更加详细。

Design IT. (1),迭代的设计

从大的发展来看,
网站就是一块试验田,一块在错误中成长、在错误中变强变大的试验田。这决定了互联网产品的成长路线,一定是一个反复修正和迭代的曲线。
很多,多年前的产计,当时未能取得成功,有的还一败涂地。拿到今天,稍加包装就成了最热门最合适的设计。究其原因,我认为大多数都属于“时机问题”,当初那些产品设计,面临的很多环境并不成熟。究其错误,我认为大多数都属于过于“激进”,在互联网这个世界,如果你要从一开始就做彻彻底底的去创新,基本没有成功的可能。
回顾互联网历史,我们不难发现,几乎所有成功的产品都是一个不断在演变的产品。包括yahoo、google、myspace、facebook、taobao、QQ等等,乃至MS。

回到产品设计本身,
早期“阶段性”的流程方式给我们产品开发和设计,带来了无尽的“返工”和低质量设计。往往前一个“阶段”的细节失误,就能导致后一个阶段的彻底垮工。
特别是我们从目录网站走到内容网站,又走到了今天的社区,网站本身的跌代性和反复修改变得越来越快。“阶段性”的流程方式无法“多团队同时协作”,导致的低效率,越来越凸显。

于是我们开始针对“产品更新快”、“迭代频繁”、“多团队协作”,等特性需求而改进的一些产品设计流程。这样的流程从大体上可以分成三个要点:按阶段发展相互依赖 + 表现层和底层相对分离 + 循环渐进反复迭代

可以尝试用这样的一张草图来表现这种“流程”:

1、产品团队是核心。
产品团队发起项目,做前期的整体调研和评估,确定产品的定位、方向,以及大的产品概念设计。
在这个基础上将所面向的用户群进行大致划分,对不同用户群体的需求进行概要分析和总结。
最后产出:产品的整体框架,重要需求点的业务逻辑。

2、表现层和底层相对分离。
对于研发来说,产品的产出物都是数据。产品架构就是他的底层数据结构,业务逻辑就是他的数据逻辑。(研发我只懂皮毛,具体内容不一定完全正确)
对于设计来说,之前对于用户群的划分、对于需求的分析将演变成未来网站的内容设计;产品架构将演变成网站的信息架构(栏目、布局、导航等),业务逻辑是未来交互设计的依据。
最后,研发的前端的接口和设计的前端开发相结合。

3、这样做最大的好处在于:
业务发展到一定时候,当底层需要升级或者改进,表现层可以不用变化;
如果表现层的设计需要“改版”,底层可以不用变化;
只有当产品方向有变,或者业务逻辑发生变化,才会牵扯到底层和表现层同时变化。

4、按阶段发展相互依赖。
单看产品+研发,或单看产品+设计,每一个从上至下的过程都必须具备先后的阶段性,上一个的过程决定了下一个过程的大致范围,下一个过程影响并补充了上一个过程的详细内容。
比如,没有大的产品框架就没有具体的信息架构,在具体的信息架构设计过程中,又会修正并补充整体的产品框架。
再比如,没有需求分析,就不能有具体的内容设计,在具体的内容设计过程中,又会细化需求并有可能合并或者拆分已经修改需求。

5、循环渐进反复迭代。
这一点和第四点有很大的关系,理解这一点可以先看一下Jesse James Garrett 在《THE ELEMENTSOF USER EXPERIENCE》一书中(这是一本每个产品设计者都应该阅读的入门好书,中文叫《用户体验的要素》,由Angela翻译,因为我很讨厌这个书名里莫名其妙多了一个“的”字,所以以后我只会引用英文书名。),关于“迭代”的解释:

JJG在把体验分成了战略、范围、结构、框架、表现五个层面。我认为这五个层在细化的过程中,已不很适合如今的互联网产品设计,而且内容过于粗略,属于概念性质的东西,很难应用到操作层面。但,他在这里讲述这五个层在具体应用中的迭代关系,可以应用现在的设计中。

Angela是这样翻译的:“你应该计划好你的项目,让任何一个层面中的工作都不能在其下层面的工作完成之前结束。… 在我们知道基本形状之前,不能为房屋加上屋顶。… 要求每个层面的工作在下一个层面可以开始之前完成,会导致你和你的用户都不满意的结果。… 一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成”。

拿到这里会有一点小变动,应该这么说:不能完整结束了这个阶段的工作,才开始下个阶段;在下个阶段该结束的时候,完成这个阶段这个阶段的工作。(这也是为了我在前面给“完整”“整体”“大致”等关键词加粗的原因)
比如,不要把需求整理的非常详细以后再去内容设计,只要在内容设计该结束的时候完成需求整理;不要在开始信息架构设计的时候完全确定内容设计,只要在信息架构该确定的时候完成内容设计。也就是说“需求整理在信息架构开始的时候完成即可”。

(当然,这种做法一个更大的问题会出现:文档维护比以往阶段性的方式更繁复。 这一点,后面会详细谈到。 )

不可分割的“用户调研”
细心的人可能已经看出,上面的设计并没有加入“用户”的内容。没错,上面的图只是在说“设计”,并没有提到用户调研。
用户调研应该贯穿于设计的任何一个环节,在整个设计过程中既起到“引导”的作用,又起到“校验”的功效。加入了对用户的研究以后,整个“迭代的设计过程”才会变得完整和丰满。

事实上这边文章应该属于“迭代设计”的一半内容,在以往的培训中我会加入用户调研部分进去(比如,这张图白板左边是上面的内容,右边就是用户调研加入进去之后的“产品设计”过程。右边的一半内容都是用户调研)。这篇文章就不细说了,《Design IT.》 系列正式完成的时候再补充进去。

.

.

PS:
《Design IT.》将是一个很长期,很完整的系列。从设计方法,到产品市场、到具体的设计,到最后的测试和产品类的线上运营。
欢迎有兴趣的朋友对每篇文章进行指正和补充。(为了保证更高质量的评论,我将关闭这个系列文章的评论。请在你自己的博客用“文章”回复,或者将你的文章发布到UCD大社区里。咱们可以把这些文章都聚合成话题)

me.com注册时的字符长度

上图来自me.com的注册界面。

关于输入框的字符长度问题,me.com是这样设计的:
1、提示了最多32个字符。超过32后,你会发现输入不进去
2、在选择月份的时候,月份后面给了阿拉伯数字,便于识别
3、任何一个动作你都能得到反馈,任何一个状态你都能看到提示
.
如此细致的体验,你能做到么?
我开始相信apple能做好me.com,能够做好互联网应用。

提问:
假设,字符长度没有最短限制。是不是可以:不给最多可以输入多少字符的提示,只在他输入超过限制的时候才报错,告诉他不能超过32个字符。?(虽然这有点违反人机交互的告知原则)

« 较旧文章 较新文章 »