交互设计策划书(实用13篇)
策划书是一个团队合作的产物,需要多方面的意见和建议,以充分考虑各方利益和需求。这些范文是策划人员在实践中总结和归纳的经验,具有实用性和参考价值。
![](/static/img/rand_5.jpg)
交互设计岗位职责
3、运用合理的设计方法,评估产品上线后的.效果,并提出用户体验改善计划;。
1、本科及以上学历,工业设计、心理学、计算机等相关专业;。
2、工作经验:3年以上交互工作经验,有app产品案例更佳;。
4、能对产出负责,最好有一定的团队管理能力(优先考虑);。
交互设计岗位职责
4、协助产品和开发人员,保障设计方案高水准还原,推动产品最终落地;。
5、撰写交互规范并持续不断维护、优化规范。
1、统招本科以上学历,交互设计、艺术设计等相关专业;。
3、熟练运用交互设计各种方法,对交互设计理念有深刻的了解和认识;。
4、对用户体验和易用性有敏锐的把握能力;。
5、大型互联网公司、互联网教育领域经验优先。
Android4.0界面设计原则交互设计
下面这些原则是由android用户体验团队创建并用以指导他们设计,来让使用者始终保持兴趣,您可以在您的创意和设计理念中来考虑这些原则。如果没有特定原因,建议您在构思创意和设计理念中考虑这些原则。
吸引我。
用令人惊奇的方式取悦我。
一个漂亮的界面、精心设置的动画,或者定时的声音效果都是令人愉悦的体验。这些都有助于让用户感受到操作过程是简单而毫不费力的。
真实的物体往往比按钮和菜单更有意思。
允许人们直接触摸和操作您的app中的对象。它减少了人们认知的成本,并且让人们获得了更多情感满足。
让我拥有。
人们会喜欢添加一些个性化的风格,因为有助于他们感到宾至如归和控制感。提供有意义的、漂亮的默认值,并且也可以考虑提供好玩的、可选的自定义,但不要干扰主任务。
了解我。
随着时间来学习人们的偏好。与其一遍又一遍的询问用户来做出相同的选择,倒不如让用户更简单的使用上次的选择。
让我的生活更简单。
保持简单。
使用简单的词汇和短语。如果一个句子很长,人们通常会跳过。
图片或文本更快传递信息。
考虑用图片来表达创意。它们会获得用户的注意,并且能比文本更有效。
为我判断,但让我有最终发言权。
尽量猜测和行动,而不是总询问。太多的选项和判断会让用户不爽。假使你搞错了,允许“撤销”。
只显示我需要的。
如果人们一次看到太多东西,会不堪重负,
把任务和信息拆分成易消化小块内容。隐藏当前不必要的选项,并且告诉他们如何继续。
我应该总是知道我在哪儿。
给人信心,让他们知道自己所在。让你的app的不同位置区分明显,使用过渡动画来诠释不同界面的关系。对于正在进行的任务过程提供及时的反馈。
别弄丢我的东西。
保存用户花时间创建的内容,并且允许人们在任何时候访问。记住人们在不同手机、平板和电脑间的设置、个人风格和创造。这会使得升级是一件极其容易的事情。
如果他们长得一样,那么操作应该也是一样。
通过显著的视觉差异,来帮助人们辨别他们功能上的差异。避免使用看起来相似但操作却不同的模式切换。
如非重要,别打断我。
就像一个好的个人助理,帮助人们屏蔽不重要的技术细节。人们需要集中注意力,除非遇上严重的或者时间敏感的问题,打断会使得用户沮丧。
让我惊叹。
给我到处都可以使用的技巧。
当人们自己解决问题的时候,他们会感觉更棒。利用人们在其他app中的视觉风格和肢体记忆,让用户学习您的app更容易。比如,轻扫手势会是导航的快捷方式。
不是我的错。
温柔的促使人们改正他们的错误。他们在使用的时候希望觉得自己是聪明。如果出错了,给他们恢复的指引,但是别给予太多的技术细节。如果您可以在后台修复问题会更好。
给予鼓励。
把复杂任务拆分成较小的步骤,来让它更容易完成。在用户操作的时候给予反馈,即使是一个微弱的发光。
帮我完成繁重的部分。
帮助新手用户做他们以为做不了的事情,让他们感觉自己像专家一样。比如,通过结合多种照片效果的快捷操作,只须几步就可以将业余的照片打造出惊人的效果。
让重要的事情完成的更快。
不是所有的操作都是平等的。决定你的app中哪些是最重要的,然后让他们更容易发现和更快的使用,就像拍照界面上的快门键或音乐播放器上的暂停键。
童年那些有创举的交互交互设计
如果在每个80后的心中有份深藏的记忆,43款经典的任天堂红白机带给我们的是永远的感动,童年是痴迷于超级马里奥(mario)、俄罗斯方块、冒险岛、沙罗曼蛇、绿色兵团单纯的岁月……那样的故事情节那样的画面甚至每个关卡给我们带来的惊喜,在我们不懂用户体验不懂交互的童年时代,却跟随着宫本茂和他的马里奥快速走进了一切以用户为中心的科技时代。
谈到用户体验谈到交互设计上有创举的公司,我们首先想到的无论是苹果还是亚马逊,微软、facebook……甚至迪斯尼这样的公司也可能会榜上有名,这些公司不仅仅是因为它们能让用户彼此交互,更重要的是通过全新的沟通工具尝试了新的对话方式。例如iphone在人机交互设计方面带给用户的是“信息就在指尖”,苹果公司带给我们的惊喜耳熟能详,从八十年代macintosh计算机,定义了至今无人能够超越的图形用户界面(gui)到创新性的ipod系列音乐播放器和itunes在线音乐商店引发的数字音乐革命,任天堂则是被遗忘的角落。事实上,被称作马里奥之父任天堂的传奇设计师宫本茂,在交互设计领域做出了不可磨灭的贡献,我们今天很多习以为常的产品设计都是从任天堂开始的,并最终成为了行业惯例。
做有剧情的游戏。
八十年代初期的pc游戏大多停留在一味追求高分的阶段,没有故事情节,只有多彩的画面,早期的游戏多处在非常低下的硬件水平,所有的游戏用户之间拼的就是高分,这很大一部分限制了游戏的发展,没有文化底蕴,题材单一,同时也导致了用户粘度低,容易视觉疲劳,不能够可持续的update,同时很大一部分也限制在自己的领域里,无法拓展一些周边的产业,比如漫画,电视剧,玩偶,人文传说都不能很好的结合并且发展,也限制了游戏本身的发展。
是否还记得小霸王学习机里的这款经典游戏:玛丽医生()。
这是一款在fc平台上发行的电视游戏,是在俄罗斯方块的基础上,增加了一些想象力,使之变为一款新游戏,游戏的目的只有一个:丢掷相应颜色的药片消灭虫子。初玩这个游戏的时候觉得很新奇,但随着关卡的深入,虫子的增多,单一的投掷而越显的游戏的乏味。这也反映了那个年代游戏产业的一个通病。
另一个例子是80年namco的一款《pac-man》(国内称“吃豆人”)。
80年代是游戏行业的一个重要转折点,任天堂游戏也因为宫本茂的加入和当时一部非常有影响力的电影《金刚》发生了质的改变。宫本茂在电影《金刚》中得到启发,认为游戏也可以是有情节的,有情节的游戏才能增加趣味性,提高用户的粘度。1981年任天堂著名的《大金刚》(donkeykong)诞生,宫本茂设计的是一个英雄救美女的故事,这也是街机历史上最为成功的游戏之一。
而此后,英雄救美的情节,也以多种多样的形式在任天堂之后的各种游戏系列中频繁出现。比如:
《影子传说》(legendofkage)故事一开始,公主kiri就被邪恶忍者绑架,这时,主角影从一片树林后跳了出来,前去营救公主。这是一部极具电影感的游戏。
包括后面会提到的《塞尔达传说》(thelegendofzelda),
永远的《塞尔达传说》。
宫本茂说,市面上不一定只能有那种需要按图索骥,让人耗神费心的游戏。我们希望可以看到新型态的游戏用不同的面貌和消费者见面。我们不该只想着利用新科技做为未来发展游戏的筹码,真正该做的工作是开发可以吸引到更多民众的游戏。好比任天堂就是一个让五岁到九十五岁的民众都着迷的好例子。
尽管《大金刚》第一次给游戏加入了故事情节,但是在表现形式上,它和当时那些以获得高分为唯一目的的游戏依然没有太大的区别。《大金刚》的空前成功使任天堂和宫本茂意识到,未来的游戏,应当拥有更丰满的剧情,讲述更加引人入胜的故事。《塞尔达传说》沿用了英雄救美的故事情节,这款游戏融合了动作、冒险、解谜、角色扮演,还包含了少量的平台跳跃,潜入,竞速等等的元素,并融入了三个伟大的交互创举。
1.饱满的故事情节。
《塞尔达传说》系列不存在“经验”和“升级”这个概念,在这款系列游戏中让用户告别了之前不停地刷高分上排行榜为目的的老套中,他呈现在用户面前的是一个个饱满的故事情节,这使得用户在游戏中感受趣味性和和新的交互体验。
2.保存进度,读取存档。
在之前的游戏设计中,并没有设计保存进度这一功能,以至于用户为了刷高分,通宵达旦的沉浸在游戏中,一旦中断,必须重新来过。《塞尔达传说》的一伟大交互创举是能够在使用电池的主记忆体中储存游戏进度,这也是用户一直期盼和渴求的。记得小的时候游戏玩到正high的时候被妈妈叫去睡觉,每次都会很生气的说,这个死掉就去睡,好不容易玩到这关。任天堂这一历史性的创新,让用户眼前一亮,也让游戏开发商们可以大胆放心无限制的去设计游戏情节,而不必再担心游戏的漫长用户无法一次性玩完。此外,最初的设计中存档就是直接保存在游戏卡里而不绑定主机的,因此用户们可以方便地把自己的游戏进度随身携带,不管身处何方,只要掏出游戏卡插上任意一台主机就能继续玩下去。写到这里的时候,突然很想对任天堂道一声感谢,他倾听到了用户的心声,知道他们最需要的东西是什么,并针对这一方向无限制的创新。
3.actionroleplayinggame(arpg)动作角色扮演类游戏。
从游戏发展来看,最初是先有rpg(role-playinggame),arpg是从rpg发展出来的分支。《塞尔达传说》开创了允许用户自定义角色的姓名,这样用户可以切身的把自己带入到游戏情节中,倘若我们把rpg的三大特性定为:故事性、艺术性、交互性,那么arpg恰恰是在交互性上取得了巨大的创新。在这方面,arpg吸收了动作游戏的特长,将激烈的打斗场面融入其中,使得节奏大大加快,更容易也更直接地调动了用户的参与欲望。
总之,《塞尔达传说》是游戏界的里程碑,arpg的鼻祖,包括之后发布的《塞尔达传说-时之笛》首先引入了三维游戏lockon系统,完美解决了以往三维游戏的视角问题,lockon系统在现在几乎任何一款三维游戏身上都能看到。因此,这可谓是三维游戏进步的一次大革命。在《塞尔达传说》身上数不清的创意,这么一款游戏性极高的游戏是其他游戏所无法相比的。
结束语。
从游戏剧情到读取存档,以及后来的十字方向键到体感控制,任天堂在游戏行业的用户体验和交互设计领域长期扮演着开拓者的角色。他关注全年龄段的休闲娱乐,把用户锁定在5-99岁的人群,无论是白领女性还是老年用户,都是任天堂希望的用户群体,也因为这样的游戏用户定位创造了wii和nds的销售奇迹。任天堂不断尝试新的游戏交互设计,并且用最低的成本来呈现,把交互方式融合到游戏体验中。最后感谢任天堂陪我们度过了难忘的童年时光。
情感与设计交互设计
市面上现有的主流手机操作系统有一些优秀的体验,比如android从顶部下滑出的通知中心,palm的contextmenu从屏幕下部的感应区呼出。nokian9就更为纯粹,把justswipe——从侧面滑动切换手机态视为核心的设计理念。仔细看还挺邪门儿的,从顶部向下,从底部向上,从侧面向内——它们是如此热衷于边缘,以至于当我们想再这么做的时候,发现四周都被它们用光了:)。
为什么是边缘?我想到两个原因,第一个记忆成本,第二个fitts定律。
画了三张图,试着每张图停留5秒钟,记住黑点的位置:
事实上可以将黑点理解为界面中需要定位的信息,随机摆放的情况下,5秒钟的时间很可能一个也记录不下。
下一张,仍然是5秒钟的时间。
同样是5秒钟的时间,结果确有所不同。原因就在于本来一个黑点对应两个信息(x,y),但再这张图中,其中一个信息被大大简化了,以至大体能记下一两个点的位置。当我们真的用到边缘的时候,情况还更简单一些,比如下一张图,同样是5秒钟时间。
显而易见的一个结论是边缘的记忆成本要低一些,道理也很简单,如果黑点在屏幕内,每个点有两个维度的信息,x,y,而在屏幕边缘时,因为边缘只有四个,很容易区分,以至这个维度的信息几乎可以忽略,这样自然更容易定位了。
套用到fitts定律上,目标点的位置实际上是边缘的一些像素及边缘之外的全部面积,这个目标点就足够大了,以至fitts定律因为一个分母的增大而使得界面的效率提高。如下图。
另外还有一些我曾经做过的设计作为案例,比如下面的解锁界面,上边为概念稿,下边是我们再产品正式开发前改进的稿件,这个设计可以在现在市面上的腾讯定制的手机上可能到。
右图中的小字为“拖动图标到屏幕边缘解锁”。这个设计充分利用了屏幕的四个边缘,出去可以从fitts定律解释的效率提高外,同时有的优点包括:可以盲解锁(解锁键在屏幕正中,感应区域也较大,容易定位),进而可以不用看到屏幕既可完成解锁甚至还可以进入到你想要的应用(屏幕四周对应四个常用界面),也就是说在你从口袋里拿出它的这个过程,从解锁到选择应用一并完成了。
当然,不论什么设计都不是完美无缺的,比如这个设计也受到一些挑战,诸如:“为什么有四个入口,一个不是挺好,移动端设计力求一个页面完成一个功能,不用这么复杂”。这点我不认同,也涉及到另外一个有关交互密度的话题。移动端的设计虽然力求功能简洁明了,但不能一概而论。100个功能不可能安排100个页面来完成,交互密度需要和用户熟悉程度相关。画了下面的图标,但只是感觉而已,未经论证:
在nokia工作的时候,一个设计师说起他们的调研结果:用户每天在手机屏幕停留的时间,大约60%-70%以上在主屏幕(homescreen)上,这一结论好像那个直接导致了我们看到nokian97刚上市时那个繁华的过了头的主页面,先不论这个设计的好坏,数据上是比较客观的(3年前的数据)。对于用户非常熟悉的界面,我们虽然不必像n97的主页面一样排满功能,但在功能,内容布局中将密度提高一些是可以接受的,这样有利于用户有效的提高操作效率。也一并解释上述设计中四个入口的问题。
摩托罗拉在去年年末推出了一款新的手机,界面上和我们之前的设计非常相近,并非想说moto抄袭,应该只是个偶然,因为腾讯也经常要面对抄袭的指责,可能大家都是中国人,习惯这个词了,但是设计上并没有那么多抄袭可言。好的想法是可以碰撞的。总的来说这并不是一个很烂的设计。
关于边缘及交互密度,在桌面软件中有很多应用,mac,win7系统中有很多相关的优秀体验。最近我们在qq的概念稿中也有充分的体现,短时间内不便放设计稿上来,终究它能带来一些不错的体验,值得实践一下。
情感与设计交互设计
最近,总是在想思考自己的目标,ux(ue)的发展,却总听到有人提到概念设计,给用户传递情感,让用户爱上自己的品牌。我不尽汗颜,在一个团队里,如果设计流程和质量还无法保证高效、顺畅、一致,纯属空谈。换句话说,活才勉勉强强做完。开会的时候,不是想如何提高质量、效率。而是空谈什么概念设计、传递情感,就只能说说而已。
在我的记忆里,我总是听到那些提概念设计、传递情感的人,言必提苹果公司。确实苹果公司设计上的成功有目共睹。但是不知道,那些空谈概念设计和传递情感的人有没有读过苹果公司10多年前写得。
文档里说明了小到一个icon该怎么设计设计的时候应该注意什么。没有在团队里确立一个相对统一的标准。团队里的设计师一个人一个风格就连一个按钮的样式和文案都没统一也没有专门的设计文档说明和记录设计思路天天靠开会来沟通上线了也没有人持续根据上线后的数据(就看上线后一周)。还空谈什么概念设计、传递情感……笑谈吧。
本文来自:/。
UCD团队:交互设计师和产品经理交互设计
最近在读《启示录》,里边提到了一些人员分工的情况,结合我自已的经验,整理如下(当然每个公司会有不同),其中不妥或还可以优化的地方,请赐教:
补充一些点:
1.如何作到高效?
*所有人员无论是哪个部门的,都应该对产品的认识是一致的;
*产品的每一阶段的目标必须清楚;
*避免大多的文档,使用高保真的原型;
*一个人担当多个职位,可以减少没有必要的沟通(这不一定是好事,看情况);
*每个人的职责必须明确;
*敏捷开发;
2.如何保证产品在开发过程中功能的加减?
*如果有新功能可以放在下一个版本中评估;
3.高保真原型的好处是什么?
*节省时间,文档几乎没有人会仔细去读,而且还会花产品经理和开发人员大量的时间;
*提前作用户测试,提前验证产品的靠谱性,降低产品上线后的风险;
4.产品计划要作到多细?
*每天列一项基本就差不多了,主要是能了解每日的进度;
*不用写的太细,重要的几个节点卡死,平时多和开发人员嘴上沟通就可以了;
5.产品经理和项目经理的区别是什么?
*产品经理:核心工作是抓用户需求、设计产品;
*项目经理:确定产品能按计划开发出来;
6.开发人员知道产品背景有什么好处?
*目标清楚,不用闷头干活,不必纠结于没有必须纠结的地方;
*可以提供更好的解决方案,必须开发人员是最了解技术的;
*最好让开发人员、设计师、运维都分一部分产品的指标(当然这是题外话);
7.开发的时间如何评估?
UCD团队:交互设计师和产品经理交互设计
我不这么认为。首先卖个关子,“矛盾论”里有句话:矛盾是普遍存在的。矛盾的同一性是有条件,相对的;矛盾的斗争性是无条件的绝对的。有条件的相对的同一性和无条件的绝对的斗争性相结合,构成了一切事物的发展运动。
本质上,他俩是“各怀鬼胎”的矛盾共同体。同一性就是他俩都想在各自的范围内把产品做到最好。
呵呵,非也。矛盾听起来不是好词,却是事物不断发展进步的核心。一致的赞同反而阻碍了产品的进步。产品经理提出的某个需求,在交互设计师眼中有时候是对用户的严重侵犯。交互设计师流畅易用的界面或许损失了产品的巨大广告效益。两者在不断的试验,讨论中融合,使得产品不断发展,弥合两者间的矛盾。1+1》1让产品即能满足企业的商业目的,又会赢得市场用户的好评,声名远播。
当然,这也需要产品经理和交互设计师在互信,相互理解,有效沟通才能实现。所以,职场上,痛苦的产品经理人和交互设计师,不要一直纠结在为什么他不理解我的狭隘思绪里,恰巧是这种牵扯才让你不会执意片面的观点一根筋,他人的质疑往往是进步的更大动力,它让你不断思考如何改变,使产品变得更好。
思考:如何提高交互设计水平交互设计
这让我想起来自己在项目里也大力推行过交互说明文档(在下文中,简称为drd),格式倒没什么限制,交互设计师自己写到界面上也行,单独文档成文也行,总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来,降低项目里的沟通成本和风险。今天整理电脑,翻出以前的ppt,分享之。
这将涉及到几个问题:
一.什么是交互说明文档(drd)?
所谓drd即是用来承载交互说明,并交付给前端、测试以及开发工程师参考的文档。
在项目中,交互设计师的主要产出物可能依次是:sitemap,pageflow,wireframes。有的大型项目前期,交互设计师有可能还会产出用户需求分析文档(与pd产出的市场需求文档不一样的是,urd更多侧重于对目标用户的需求分析)。
drd则很少有人专门撰写。如果需要对交互设计进行说明,聪明的交互设计师往往会直接标注在线框图里,或者在项目中不断和前端工程师和开发工程师口口相传,反复验收,不断迭代修改来确保所有的交互设计意图最终得以呈现。
二.为什么要写?
drd非项目必需环节,一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档,项目也会继续,但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话,项目的质量也会受到影响。所以写与不写,交互设计师需要做把握,时间被统一包含在“线框图”环节内——如果你要写,请在评估时预留1-2天的时间。
那么,结合我过去的经历,谈一下此文档的必要性。
下图是一个产品开发项目基本的流程。
敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的frd已经全部敲定,交互设计师再开始去画线框图,固然会减少沟通成本和返工风险,但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些,他甚至会在frd里连原始的demo也一并绘制出来了,功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在frd里直接要求每页条目40条,超过40条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和……所以,我们希望是和产品经理同时开始工作,在术业有专攻的时候相互补充。
同样,开发工程师也希望及早介入需求,在frd并未确认的时候就了解需求,进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单(这个清单,大部分叫做uc,即usecase),当这份清单由工程师需求分析师——在过去,这个角色被叫简称为ra,但是目前已经取消此专门的职位,而是由开发工程师代表担纲此环节工作,为了便于描述,在此文里,我仍然将做这件事情的人称为ra——交付给具体的执行工程师后,执行工程师基本上可以当作一条条的checklist开始高效工作,而不必再思考商业逻辑和需求。同样,测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试,这也是基于uc和frd去撰写的。
所以,开发需求分析是个很重要的环节。那ra是如何来完成需求分析工作的呢?
前期介入,对pd进行开发需求评估支持;
参与每次的frd评审会;
详细审阅frd文档并不断与pd确认。
对于做这件事情的人来说,足够详尽的frd是非常重要的。所以一份frd虽然是pd产出,但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递,却存在很多问题。除了线框图,没有“详尽的说明性的文档”告诉他们。比如:
一方面,交互设计师对产品经理说:这块由我们来考虑,你的文档不必包含设计上的说明,这随时会调整的。
另一方面,线框图的评审有时会让ra参与,有时却没有叫他们。即使叫上了他们,他们也会发现交互设计的需求变化要比frd变化快。另外,他们会认为uc不必写太多关于交互设计的需求。
在某个大型项目结束后,作为交互设计师,我进行了一些调研,听听这相关人员是怎么表述问题的:
开发部门的需求分析师:
页面交互的需求容易漏掉,因为uc里面不可能写太多交互方面的东西。
希望ued能够在提交htmldemo给ra时,能同时给出一份页面元素描述文档,需要介绍htmldemo中的文案、链接以及相关的图片尺寸或显示字符个数。现在ra在这方面花费的时间比较多,经常要和ued去确认这些内容。
产品经理:
前期ra和pd沟通过程中,有很多交互点点不能够明确,比如“默认显示多少属性值”,“标题显示多少字符”等。在以往的需求和项目中,对待这些问题我们都是想到一点补一点的到frd文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。pd为了可控性的需求,往往会“越俎代庖”,直接在frd注明这种需求(对于交互设计师来讲,却又导致没有发挥余地)。
走访了一些交互设计师后,他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑:
交互认为很平常的设计需求,如果不表达出来,还是容易被前端和开发忽略掉。我经历的一个项目,前端从头到尾更换了三个人,每次我都要重复去讲解下设计需求,讲得口干舌燥。而且做好后,还需要去验收。
drd做为参考手册,一定程度上避免不吻合的问题发生。
即使有问题发生,也可以作为界面验收时的checklist。将“我对a说,我对b说,a对b说”,转变为“a和b共同参考同一份文档”,减少沟通成本及信息不对称。
全程影响用户体验(一直到测试,都需要参照设计文档)。
可是以下问题都可以通过一份drd来解决吗?
三.写什么不写什么?
要明确文档的定位,从写什么与不写什么开始,划清drd以及frd的边界。
1.不写视觉规范规格标注。
这些说明与功能实现没有太大关系,主要是为前端做html的时候参考的。一般视觉设计师会在psd里标注清楚。如图:
2.不写功能实现逻辑。
电脑资料。
那么文档写什么呢?
举例子说明下:
1.字符限制。
提高空间利用率,有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的drd需要传达清楚:1,是否要做限制?2,如果做限制的话,多少字出现截断?截断后是显示为省略号还是不显示?这个汉语设计相对简单,如果英文单词的话,因为是按字符,每个字符的宽度不一致,需要预估,另外还需要注明是整词截断还是词间截断。
2.链接具体化。
很多网站都有对搜索结果的筛选设计(refinesearch),比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。
类目和属性的不同如何处理。
属性以及每条属性显示的属性值的条目是否有显示上的限制?
要确保这些你设想中的复杂的交互逻辑能够被理解被呈现,除了一页页的线框图,你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互,有的指向你安排的并非pd安排的某个中间页面(pageflow是交互设计师的职责)。
3.交互细节说明。
相信我,我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图,我会研究用axure制作各种动态效果,达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时,页面上其他区域也发生相应的变化。可是,axure不是全能的。即使能够表达出来,线框图交付出去,也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解,在事后再三检查并敦促修改。
但是当我尝试用下图对这块小小且复杂的区域进行详细说明后,事情变得简单多了。所以我用节省的时间去写了这份ppt.
又如,你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕,标注出与他工作相关的重点,存档并在遇到问题,找不到你人时随时参考。
5.表单的校验。
这也是一项不怎么有创意的事情,但是你若不事先想清楚,在项目过程中有点麻烦。写文档看似枯燥乏味,反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写drd的时候发现存在重大的纰漏,然后及时优化的。
6.浏览器的兼容性要求。
你们的产品兼容所有浏览器简直是梦想,但是有时出于效率的要求,我们必须战略性放弃某些浏览器,比如ie6.:d。这个决定谁来做?是前端工程师还是产品经理?还是你——交互设计师?我认为决定权在交互设计师这里,但是他必须和产品经理达成一致,并与前端确认。你要求兼容的浏览器越多,标准越高,前端的工作量就会越大,测试的工作量甚至也会翻倍。
四.什么时间交付呢?
heidi的建议:尽可能与你的线框图同时交付,如果你先交付出线框图,在撰写drd的时候,极大可能会发现问题或产生优化的想法。但是往往写drd至少需要1-2天的时间,你不可能让所有下游等着你的工作。所以:
你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计,这和交互细节关系不大。
先交付出已经确定的线框图给前端,然后在1-2天drd后,若有改动,与前端当面一一确认并一起交付。
五.如何写drd?
1.选择最有效率的工具。
我的经验是这个工具最好能够提供清晰的目录导航结构,而且易标注。word确实是个写文档的好工具,不管你信不信,反正我是信了。
2.建立固定的目录结构。
下图仅供参考。
具体里面的细节,就不一一罗嗦了。
六.重要的原则。
准备写drd的朋友,请认识清楚此文档真正要解决的问题是什么?如果是解决沟通偏差、需求遗漏、沟通成本高的问题,你在项目里没有出现过这种问题,各合作方也反馈良好,那么这个文档就无需写。如果是解决对设计需求进行存档,便于后续人员改版时查看的问题,则又是另外一回事(经验证明,过去的drd确实能够在改版时起到一定的帮助,在我离开原项目很久后,新的设计师还找我要过相应项目的文档,了解过去的设计逻辑)。
不是为了写文档而写文档(而是为了解决问题)。
适合于项目、合作方(大项目有大文档,小需求有灵巧的解决方案)。
工具不是问题(易传播,易标注,成目录即可)。
模版不是问题,大家看明白就可。
完美的文档无法取代面对面的沟通(评审会和讨论不会因为文档而减少)。
需要在实践中不断改进。
七.谁来写?
我建议由交互设计师发起,但是由前端工程师进行修订,再传递给开发工程师。
有很多需求,交互设计师只要求实现即可,但是他可能并不在乎是前端实现还是后端实现。前端工程师对drd进行把关和修订,能够将设计语言转化为工程师能够看懂的语言,且能够划定与开发的实现边界。
八.与其他产出物的关系。
项目中交付物对应不同的使用角色,如下图所示:
但是有个问题是,虽然drd的目标受众有开发和测试,但是让开发工程师同时参考那么多文档是不现实的,所以仍然是开发工程师的接口人,也就是事实上的ra需求分析作为需求整合传递的角色,将商业需求和设计需求,传达给具体的执行开发工程师与测试工程师:
谈交互设计需注意的规范与创新交互设计
产品规范的应用对象,分为设计师、工程师两类人。对设计师来说主要是“协调”工作,使交付物统一;对工程师来说主要是“配合”工作,使开发效率提高。
1.规范的时机。
我倾向于在概念设计的低保原型之后,也就是说得先有第一批可开发的页面。我反复强调的原因,概念上不管做产品还是平台,核心都是由一个个页面组成的网站,有效规范只针对于最终产出。
很多朋友提到边设计边整理规范,这是对设计工作的总结。我的看法,产品设计与开发是整套系统工程,所以更进一步,应该边开发边整理规范,让规范与开发同步,互相契合更新。也就是说,每次迭代之后,都应该升级规范。
对工程师而言,上手来一份事无巨细的规范,读完要花两天,熟练要花十天,在庖丁解牛的开发过程中,简直就是噩梦。于是还没等走完这个过程,早因想痛打设计师而消极怠工了。这也正是不建议使用现成规范的原因,第一国情不同,第二时机不对。
2.规范的程度。
经常听到种声音“规范对开发工程师的约束力太弱。”我认为并非问题根源,因为规范的目标不是约束。产品规范对工程师的唯一好处就是快,越快越简便完成任务,工程师才越可能认可。打算让工程师把工作重心偏移到界面体验来完全不现实,因为各自的工作职责不同。
规范最大的作用,在于方便分享,减轻沟通压力。规范越翔实,越容易体现专业的大家风范,也就越凸显设计价值,对拿了钱就走人的设计师来说很受用。高瞻远瞩只是看上去很美,不具有可控的操作性,强制执行的后患无穷。
3.规范的内容。
概念文档,固化产品架构和业务大流程。便于设计师快速了解全局结构和流程,同时有助于工程师搭建程序结构,以及数据库逻辑。但是得注意,满脑子函数的工程师们,普遍对信息架构、交互设计不敏感。
页面设计,固化界面布局和表现。用于设计师协作完成原型设计,同时起到指导工程师修改页面的作用,尤其是页面结构、样式定义、信息块标注。忙于功能的工程师们,对界面的仔细程度往往也不如设计师。
模块控件,固化功能落实和操作小交互。既便于设计师新增、修改界面,也便于工程师嵌程序和调整。最好是做成各种精确的module或者pattern,做到有据可依有档可查。尤其是对状态描述,能省不少解释的口舌,也便于小范围升级和做版本管理,做到工作流程中的don’tmakeengineerthink。
4.规范的执行。
规范的监督成本,全部建立在规范本身的有效性之上,也就是说,对产品和团队有足够可控的了解,是提高执行效率的基础,并非设计单方面合理就行。
在项目时间受限制的情况下,工程师解决问题一定有优先级,功能高于界面不仅合理,而且完全应该这么做。我观察到的矛盾,绝大多数都因为产品方提要求的时机不合理所致。
如果没有时间压力,也没有任务压力,工程师仍然不遵守设计规范,那是工作态度问题,应该尝试与工程师团队沟通解决,或者把协调级别再调高。多注意沟通,互相调整工作方式,任何小矛盾和不契合都可能因时间而被放大。多尝试改变自己,这也是种挑战,除非有权利选择同事。
模块化开发中,工程师最怕因为乱引起的麻烦,而不是技术难度,因为难度可以妥协解决。作为设计师,多学习技术并亲自实践,除了能精确把控节奏,所获得的经验也将成倍增长。
来自:/blog/?p=478。
思考:如何提高交互设计水平交互设计
多点积累,善于反思。尽量每个月都有写给自己看的设计总结。
算了一下,做了几年的交互设计稿,如果把日常做的设计想法和思路进行累计,那数字也一定不小了!
如果可以重新思考过去的设计,把新的想法和改进的思路实践到新的交互设计中,那新的设计一定更加完善。过去并不一定是对的,也许推翻过去自己做的东西并不是很难。
做前多思考,分析要透彻。
自己是个急性子,但是设计不能马虎。不要轻易的开始绘制交互稿。做前多思考,研究分析产品方向和策略也很重要。一开始就想到“弹出还是内嵌?”,很容易被绑死到细节中。(不是说细节不重要,不冲突哦~)。
交互设计也要规划,确立清楚自己的设计思路。
曾经给自己找了很多借口,“时间好紧…”“这就是一个小需求”…。
这些借口,都让我在设计开始的时候显得十分紧迫,容易忽略或者轻视设计前的规划,还不了解自己到底打算用什么方式或者自己的设计目的还不明确,就急于下手去做,回头才发现很多漏掉的细节。
所以,交互也需要前期的规划。
在了解需求和已有设计的前提下,确立清楚自己要改善什么,自己的设计要目标是什么。不妨给自己一个计划表。
交互设计也要计划,一上去都扑到细节上,往往失败的几率会比较大。可以考虑先把问题分类,从整体上作划分,分清重要程度和级别。按部就班也许会更加完善。
业内知识的补充,能帮助自己提高。
这两年,居然忙到忽略了行业的各类知识、概念、方法等内容。发现最近一年qq上“技术组”基本没有添加过好友,自己的“小贝挖消息”也夭折了。记得以前一个朋友说过,怎么什么网站都发现有“西贝”…才发觉现在自己真的不够主动获取资讯了。
交互是需要一个不断获取新鲜能量,不断革新,跟上潮流的行业。资讯或者业内朋友的经验和工作流程也是需要不断交流,这样,也是一种使得自己更加完善,不断提高的途径。
如果需要,就多点时间把逻辑画一下。
交互设计的过程需要更加逻辑性,有的时候再忙也画一下流程图,对逻辑和产品内容都是进一步的理解。口说百遍后遗漏场景的几率还是很大,画出来流程才能更加清晰的认识。
记录缺点和改进的方法,会促使自己更加清晰的认识现状~。
思考还在继续,先写到这里。
本文来自:/?p=478。
支付宝交互设计中的一个小问题交互设计
凡客的这个例子中,搜索建议“时尚斜拉链”高亮显示,这个时候点击“搜索”,提交的关键字是输入框中的“s”还是“时尚斜拉链”呢?答案是“时尚斜拉链”。
再看看百度,当搜索建议中的“sina微博”高亮(鼠标悬停)时,点击“百度一下”,提交的关键字是输入框中的“s”,而不是高亮的“sina微博”。
到底哪种方式更好一些呢?我个人是这么认为的:
就搜索组件来说,主体应该是搜索框和搜索按钮,搜索建议只是一个附加的工具,甚至可以没有。
因此不管搜索建议状态如何,“搜索”按钮(或按“enter”键)提交的应该是搜索框中的内容,这样才不容易产生歧义。
问题二:是否要高亮显示第一条搜索建议?
看了很多相关产品,比如google、淘宝、百度、凡客等,它们的搜索都没有高亮显示第一条搜索建议。
但是也还有少数产品的搜索,是默认选中第一条搜索建议的。这样会有什么问题呢?
如果提交的是搜索建议,那按照前面说的方法,把输入框中的内容替换成第一条搜索建议是行不通的,毕竟这个不是用户自己选的,那么这个歧义就很难解决了;另外,倘若用户再手动选择其他的搜索建议,搜索框中的内容也不适合再被替换成相应的搜索建议了,因为这样就会和初始状态不一致(初始状态下搜索框中的内容和默认选中的搜索建议很可能是不一致的)。
如果提交的不是搜索建议,那么这里高亮显示它又有多大的意义呢?
总结:
若触发搜索操作后提交的是高亮的搜索建议,则搜索框中的内容应该被替换成相应的内容。
在搜索建议中不要高亮显示第一条内容。
Android4.0界面设计原则交互设计
豆瓣电台听了41000多首歌,猜中喜欢的概率不算高,但通过电台发现了很多歌曲,这也体现推荐系统要平衡多样性和精准度,不像我之前吐槽的那样,依赖于播放已喜欢的歌曲,有了精准度,但是多样化不够。比较同类产品虾米,以播放热门歌曲为主,选择的成本较大,推荐长尾歌曲的力度较低。
对于内容的喜欢是会随着时间和心情改变的,早期我会倾向于热门内容,在手机端听红心频道时会选择某些歌曲不再播放,最近红心频道听烦了,私人兆赫中推荐的歌曲比较相似,换个口味改听爵士或其他用户编辑的专辑。
电台在不断增加频道(也就是兆赫)、”专家用户“制作的专辑和风格,谨慎地为用户提供多维度的推荐,而风格中歌曲也是根据用户的选择生成。
个人以为食神摇摇的推荐理由文案还够好,对于这样以推荐为核心的产品,文案的视觉不够突出。
在电台出现之前,豆瓣已经有了音乐评分等用户反馈,用户提交更多的反馈,系统才有可能算出用户的喜欢。反馈可以是喜欢,也可以是商品的购买或、页面停留时间和视频的观看时长。一方面界面需要分析用户行为,另一方面界面本身要有利于用户反馈。手机版大众点评的界面中提交反馈的操作成本很高,需要评分和写几十字的评语,很不利用系统的推荐,所以界面中信息量较大,不利于快速选择。
推荐系统需要内容品质一致,否则用户反馈和内容对应关系不一致。早些时间豆瓣电台中有演唱会版本的歌曲,声音非常噪杂,最近没有再出现过,可能淘汰了低质量内容或者内容获得推荐的概率已经大幅降低。内容质量、呈现方式、界面布局和交互都可能影响用户的选择。
推荐系统的可以提高粘度和提升关键系指标,交互上可以减少操作成本,比如降低用户搜索、查找步骤和界面之间的跳转次数,界面架构中可利用推荐来避免产品的同质化。