“是阿航啊”为你分享6篇“非典型性UED思考交互设计”，经本站小编整理后发布，但愿对你的工作、学习、生活带来方便。
篇1：非典型性UED思考交互设计
来杭州快五个月了，自从进入UED，整个人的思路会不由自主地带上U的色彩，这就叫融入吧，不是模式化的做作，而是自然而然的落听，一旦进入角色，就会用U的视角思考周遭。两个月前的Z大学之行感慨颇多，沉淀了许久依然挥之不去，所以能够肯定，那不是一时的思绪游离，可以拿出来 了。
思考一：刚来杭州时去了一次Z大学，发现Z大学的校标与世界著名品牌阿玛尼的LOGO非常相似，当时没有跟他人说起，想着自己怎么这么没文化，这都能掰扯上，这么有名的学府之校标岂能容许我这般意淫。无奈第二次去的时候，Z大学的校标处处可见，又一次冲击了我的眼球，让我不得不再次无法自拔地往阿玛尼上靠。应该是我出身调研行业，关注过奢侈品品牌的LOGO，才会有这种困惑，大多数人未必会在意这个问题，不过我还是想深究一下。
经查证，才了解到1990年12月15日Z大学在校报上公布了校标设计稿的二个方案，经教职工和学生投票，选定了第一稿，并作修改后，于1991年1月31日的校务会议再次审议了修改后的校标。这样正式通过了现在的校标。
当初Z大学校务会议成员确定校标的时候，是否考虑过与阿玛尼LOGO相似这个问题呢？>如果考虑过为什么还要挑战已经辨识度这么高的已经存在的标志呢？>是因为一个是教育机构，一个是奢侈品品牌，领域不同而无所谓？抑或一个代表求是鸟，一个代表老鹰，寓意不同而没关系？还是自信这一标志最能代表Z大学而不能割舍呢？——这些问题没有答案，当时的决议是否讨论过这些问题不得而知。但如此设计，A知道阿玛尼LOGO的人会很快记住Z大学的校标，也会在内心揶揄一下；B不知道阿玛尼LOGO的人，如果对校标有印象，以后见了阿玛尼LOGO，会有种似曾相识的感觉，而有可能错愕于两者的相似；C不知道阿玛尼LOGO的人，以后见了阿玛尼LOGO，又有机会看到Z大学校标，也可能会纠结；D其他。
原谅我这般罗列，我不是故意扩大问题，只是这涉及到标识易识易记与唯一识别的问题。延伸到我们网站LOGO或页面的设计，同样有这样的问题，设计师最痛苦的事是一个自己满意的作品做出来了，却跟别的作品如此相似；最最痛苦的事莫过于，与其相似的作品那么的广为人知，自己却未察觉，嚎~
怎么解决这痛苦，别固步自封，怀抱开放的U心态，广泛涉猎，是解脱的方法，
此事的另一个细节，Z大学在校报公布校标设计稿时，校长办公室委托工会和团委发放了1200份印有两个方案的选票，分别征求教职工和学生的意见。通过比较，大多数师生员工倾向于方案一，即以传统的表现刚健、博击个性的“求是鸟”为主体所构成的校标设计稿。
广泛听取广大师生的建议并采用调研的方法是相当可取的，只是，调查了哪些教职工和学生，操作的方式是怎样的，并不清楚，是否科学不得而知，不做评论。反观我们平时的工作，广泛听取网站用户的意见肯定是出好作品的硬道理。但是，怎样操作才能保证收集到的意见具有科学性、推广性？这就需要U们了解各种调研方法的特点、能解决怎样的问题、如何正确操作和分析等，一旦调研方法出问题，豆腐渣无法炼出钢。
思考二：在Z大学往事休闲吧，翻看毕业纪念册，第一次看到了Z大学的校歌，立马被震了，果然是江南文人之地的大学，校歌都这般古色古香的韵味十足，有文采、有内涵。但旋即不由得担心起来，校歌的推广性怎样？>如果入学之初必有校歌的修炼，那需要多久能完全掌握？>Z大学的学生应该都会唱校歌，时过境迁，有多少能记住歌词？又有多少能完全理解其中的含义？
不必深究人家的家务事，但由此联想到我们网站各项服务的说明文件，如果晦涩难懂，或未从用户角度编辑解说内容，后果肯定不堪设想。同样，从商业化角度看，一个插件、一个按钮、一个排版···········，如果理解起来很生硬，肯定不是好设计，如今的网络世界优胜劣汰的规则，加入了太多用户的使用体验，广大用户用着不爽的，推广性就差；如果想着培养用户的使用习惯，让其加入过多的思考，并不能是商业化好设计的精髓。这就如同一个有实力的唱片歌手，如果他（她）坚持走个性化艺术路线，唱片就卖得不好，而变成商业化风格，迎合普罗大众，唱片就可能卖得好；电影也是如此，好莱坞大片受追捧，票房高，自然有他的道理。作为一个实务性的网站，理想化的好设计与商业化的好设计怎样权衡，我们的用户使用习惯需要如何去培养，这些都需要我们在做产品的时候深入思考。
*以上内容纯属个人YY，只是就事论事，各位别拍我。
本文来自：ued.taobao.com/blog//12/28/ued-think-%e7%94%a8%e6%88%b7%e7%a0%94%e7%a9%b6/
篇2：UED技术层次初探交互设计
抛砖引玉：
我的想法：
视觉规范和交互规范，以用户研究作为基础，比如全站的色调，基本操作的交互等，都取决于对主流客户群心智模型的研究。
前端技术相对独立，在规范的基础上，封装成技术框架供上层调用。这里的框架仅包括基本功能，比如css框架里的reset和grids，js框架里的dom、event等，不含widgets.
再上一层是设计模式库DPL(Design Pattern Library). 大部分模式的形成，需要视觉、交互和前端三种技术的融合。比如淘宝首页的幻灯片卡盘，不仅仅是前端技术的产物，和淘宝的视觉规范与交互设计也密切相关。
DPL是一份文档化的说明，面向的是UED全体设计人员。DPL的背面是技术实现，一般体现在JS框架里，比如YUI的widgets库，jQuery的UI插件库等等，这些封装好的代码组件面向的是程序开发人员，
在DPL之上，可以构建各种应用。比如Yahoo的首页，Google的GMail. 每个公司的DPL各不相同，体现的是一个公司整体的设计观。
DPL负责的是通用模式。具体应用中的特殊模式，还需要直接根据前端框架、视觉规范、交互规范以及用研数据来完成设计和开发。
DPL初期的构建和维护成本很高，但一旦有效运作起来后，团队将获得丰厚的回报。
延伸阅读：
Yahoo! DPL: developer.yahoo.com/ypatterns/
The Elements of a Design Pattern
UI Patterns: ui-patterns.com/patterns
本文出自：lifesinger.org/blog/?p=1416
篇3：关于互联网UED交互设计
最近做Presentation用的稿子，
虽说是Internet，仅限网站而已，不包括软件。我没做过软件，但一直认为，网站的交互实现要比软件麻烦的多，因为客户端的原因。
交付物环节尤其重要，我发现有个误区是必须要XX软件才能做XX。日本人做产品几乎就用PDF, XLS, TXT, HTML四种文档，他们用Excel的水准非常高，因为觉得花钱买了正版，就要把有价值的功能使够，
我们的问题正在于备选项太多，如果自始自终都只有Excel，只有Word，相信大家都能练出来。
公司预装软件全正版，那些太先进和稀奇古怪的东西只能在自己电脑上做。仔细想想，人家节约成本也没什么不对，谁让咱学艺不精呢，十年前的Excel都玩不转。
互联网的用户体验设计过程：internet-ued-process.pdf
来自：blog.rexsong.com/?p=1118
篇4：混乱的支付宝UED交互设计
三天前，支付宝ued上发表了这样一份文章《潜谈产品设计中的可用性和可访问性》，这篇文章突然让我很想抬一杠。
文章举了一个注册页面的例子，说该页面的编码没有考虑到js禁用的情况，会在禁用js的浏览器中引发注册错误，结论是这属于没考虑到用户的”应用场景”。
说实话，我还真的愣了一下，因为的确难以联系到应用场景上去，因为这并不是一个应用场景设计的问题，而是一个标准的软件测试问题。支付宝ued明显混淆了界面设计、交互设计与软件工程的领域内涵。
在传统的、标准的软件工程测试中，有一种方法叫做”黑箱测试”，其目的就是故意通过破坏性数据、制造非标准条件来诱发软件错误。在标准的WEB测试种，也有一种”兼容性测试”和“环境测试”，在支付宝ued的文章中，浏览器不支持js脚本，就属于一种非标准条件测试。同样的，如果浏览器换成Mozilla、Firefox、Chrome…都属于一种标准的浏览器兼容性测试，其方法是创建一个兼容性矩阵，在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。浏览器的安全性设置和JAVA设置本来就是题中应有之意。
而可用性工程中的应用场景设计，隶属于可用性方法中的用户调研方法，定位于交互设计的角色定义阶段，其内容是描述非技术性的、与用户业务和工作场景直接相关的用户资料。在用户场景中，的确可以对用户的电脑做一般性描述，比如配置档次如何、性能如何、主要用途为何，但绝不能细化到电脑中的操作系统中的浏览器中的js的安全性这种级别上，
简单的说，用户应用场景定义的是用户接触界面之前的事情，用户接触界面之后，对应的是交互设计和界面设计，这是在角色定义完成之后的。即便两者有交叉迭代，那也是有先后关系的：用户场景定义为交互设计和界面设计提供输入。
而浏览器的js安全性、操作系统是否中毒、用户输入法是五笔还是拼音….这些统统可以抛给测试。可以是传统的软件工程测试，也可以是原型级的、非原型级的可用性测试。
如果，按照支付宝的这种可用性设计理念搞下去，大批的设计师可以收拾东西走人了，因为它又把体验设计应当尽力撇开的技术因素再度无情的捆绑在了体验设计的战车上。
支付宝ued的这种初级错误，其实已经陷入了自己的悖论中。因为它只考虑了js的兼容性，却没考虑css。如果用户的浏览器两者都不支持，你怎么搞呢？如果支付宝的测试团队任务艰巨，没时间进行兼容性测试，那么我们可以理解。但如果就此把这些内容划归到本不相干的场景设计中来，则完全是因为不理解可用性设计的基本内容和范畴。该文章的特点，在于可以快速吸引一批js、css程序员的注意力，却就此敲了所有体验设计师一记闷棍。更不可思议的是后面竟然还扯出了”语义化”……
不过有一点，支付宝ued说对了，那就是这个问题的确”不是前端开发工程师要去考虑的”。
本文出自：douis.wordpress.com.cn//01/19/92/
篇5：UED你需要的是什么样的结果？交互设计
这个话题很敏感，写这编的时候一半是热血沸腾，一半是冷汗直流，点公开还是隐藏时犹豫了将近两个小时。最近被人评价为越来越奋青。那就着这个评价大胆的奋青一把。本着有位同学说的要死鸟朝上写出来等待讨伐。
大概是吧，全中国开始热炒Web2.0，跟随着这个三个英文字母加带小数点数字的名词雀起，所谓的用户体验也鸡犬升天。交互设计师这个职位成为一个互联网界带着神秘且高贵的职位。一个个的设计师及产品经理开始带着改变人们“生命”的使命，以救世主方式出现。高喊着“以用户为中心的设计”，成立起了中国互联网公司的一个个UED(用户体验设计)。
看上帝笑了！看中国互联网的UED，看中国的交互设计师们，他们不知道怎么去以用户为中心的设计。只知道这是个美妙且高尚的词汇。拿着上帝那要来的上方宝剑耀武扬威。可中国的互联网产品却始终保持着这群人最敏感及最容易跳起来的以商业结果为中心。当这群人们拿着这把剑去和互联网公司的老板说话的时候，才发现原来握在手里的是一只咸鱼。
于是UED们开始想着如何脱颖而出，变着法的去找用户为中心的设计是有商业结果的。于是UED们开始想我们不能老是一直被动着响应产品设计(简称PD)们的需求，100%的精力都放到他们的“商业目标”驱动的项目上，试着以用户为中心的设计思想去做产品。于是产品就铺天盖地的来了，一个个的产品似乎创意都不错，可见鬼的是没有一个能拿到老板们想要的money，于是有人想通了。原来我们一直理解错了。老板嘛，非要有money才信服以用户为中心的设计，多么的矛盾啊。讽刺的开始，讽刺的变化。
看看UED们怎么有这个过程的，故事又开始了。想听下去吗？不想听我也说~！
“某某设计师觉得XX项目有很大的问题，于是做了一个分析想进行改进，结果发现这个产品上的模块居然是不同产品线的，分别不同的PD负责。为了推动我的设计，需要找好几方进行沟通。根本无法估计这样改动会造成什么样的后果，可能直接会损失几亿哪，你怕不怕？”
有人说：“你觉得那个东西很难用？那就对了。我们不是不想改啊？方案都出了好几版了，同样有上面的问题，可是咱没资源呀，沟通资源？你知道要牵涉多少部门吗？改？！算了吧，放着吧同志，于是就一直保持“难用”，
”
还有人说:“哎呀，干嘛这么麻烦，放左边与放右边有什么区别，花2个小时能给我们赚多少钱呀？啊？不能赚钱？败家玩意，一边凉快去。"
“另外一个同学稍稍幸运点，他比较能折腾自己做产品，一直往上沟通直接找负责人。累的吐血的写出了自认为完美的MRD与PRD，所有人都信服的竖起大拇指，这个创意太棒了。不过？这个东西不如和某产品结合的来做吧。直接交给负责这个产品的PD好了。欲哭无泪的结果。 的结果！那我算什么，可怜的母鸡？下完蛋你们拿去做“荷包蛋”吗？我们不是不通情理，不是不懂是非。就是通情理才认为你们都能讲道理，是懂是非才不会奋起拍桌子骂街。问问他们原因吧，没关系我们再通情理点。答复是这个创意不知道能不能带来商业价值，PD们背负着沉重的考核压力，俗称KPI。你有吗，要做也行！你背KPI去做PD吧，别做设计师了！操！没错我没有！操！没错我不是PD！操！那这个创意不要做了！！故事又开始了，想听下去吗？不想听！我照样说，记得香山饭店吗？认识贝聿铭吗？当中方改了香山饭店的设计后，贝老头拍桌子骂街说：以后不要让我给中国设计！”于是有人分析，所有的原因都可以归结为：“资源、组织架构、沟通”问题！原来每个设计师都有悲哀。贝老头的事也是中国设计界的悲哀。或许在这里他们不尊重设计这两个字吧？反问难道互联网的交互设计最终的出路真的是成为PD吗？
看看原来是这样：设计方案存在潜在的风险，投入大产出慢，没有直接的商业价值； 而且开发资源紧张，无法投入，多方沟通不能顺畅推动，七砍八砍手脚全没了，这个创意就变成了尸体标本，因为没有手脚。做是可能做出来了，可是活体变成了标本。难道继续再发起体验设计改版从头再来一遍吗？
看出来了吗？互联网的UED们，你们想要以上什么样的结果？都不要？哈哈那拆到产品组去吧，每个产品下面放些美术资源，放几个交互设计师，听产品经理（PD）的！
所以中国现在的UED们结局有以下这么几种：
1、名为UED实为UI，完全听PD PM的。为他们的KPI奋斗。你的工作是刷墙和漆匠
2、改名叫设计中心，像特种部队只出规范和方案，形同虚设
3、UED与PD合并成为产品设计部，最终发现走的是纯PD路线与第1种差不多
4、拆到产品组
6、转职去PD，放弃设计师的理想
5、痛苦探索中。。。。
本文来自：hd8010213.ourhost.cn/article.asp?id=23
篇6：关于产品的若干思考交互设计
本文将要论述的话题是围绕着如今繁多的互联网产品展开的，笔者将会尽可能的做以精要的说明，从逐点优化的产品优势开始说起，最终聊到卓越产品乃至极致产品所需要具备的要素，
开始正文。
优秀产品靠的是不断完善：
在日常生活中，无论是PC终端还是智能机，几天的时间，用户就会发现需要升级的软件/App有很多。我们就先来聊聊这个。现在的软件厂商们很注重效率，往往隔三岔五地在推出软件的Beta版本，但软件实质性的功能变化一般都不会很大。那么它们这样反复地更新，究竟有什么样的意图，下面几段，我们就来解决这个问题。
一般来说，不断更新版本的软件，从产品，用户，营销手段三个方面来说都有很大的好处。
对产品而言：
用户使用软件时及时发现的bug或者是产品本身不够优化的用户体验，都会及时在下一个版本中得到改良。产品一直在改变，一直在优化，所以说在性能上肯定是不断增益的。
对用户而言：
从用户的角度来说，不断推陈出新的策略似乎使客户端软件会更加的与自己拉近距离，提高一些黏度。只要每更新一次，就增加了用户接触软件并使用它的频率，会逐步培养出用户习惯，用户自然也就会下意识的在需要时记得使用该软件。况且由于软件的不断更新，使得用户对于软件的感觉上则是其功能在不断地增强，软件在不断地完善。每更新一次，在潜意识里面都在告诉用户软件的功能在不断地强化。由此，不断地更新产品，就是在逐渐强化产品在用户大脑中的性能。这就是产品经理们的“诡计”。
对营销手段而言：
从营销的角度上来说呢，由于用户反复接触软件的次数越多，该产品的定位就会越发的鲜明，这就会逐步的提高品牌效应，
随着时间的推延，功能性会与产品本身产生奇妙的联系。比如：安全与360产生对等，聊天与QQ产生对等。产生冥冥中的对等性，这就是软件厂商最希望的结果。
卓越产品需要有“范儿”：
上面本人分析了不断更新产品的若干好处，发现这些方法都是可以起到优化作用的，也可以将产品逐步达到优秀，但是，这样的操作手法真的可以造就卓越产品吗？
我认为，优秀与卓越，中间跨着一道坎，这就存在于产品思维上的缺陷。很显然，上述的种种做法从整体上来看不大符合苹果的风格。逐点优化，和别人拼软件，拼硬件性能，都不是苹果的范儿。苹果一贯是特立独行，坚持在做软硬件一体化，看似封闭的机制却使得公司一度达到了全球市值第一的境况。一味的依照用户的需求去改良，去完善，也许会做出具备很高适宜度与体验度的产品，但是一般来说，却很难做出极致的产品，因为用户的思维只可以使产品更加的好用，至于产品灵魂的缔造与风格的设计，这不是用户所需要考量的范围。用户只是使用者，他们在使用产品时会有总体的感觉，好用还是不好用；也可以细化到一个点上，会考量到哪一点不好用，不符合自己的使用习惯；但是如果指望用户坐下来考量产品如何大幅度创新，这大概是不可能的事情。最好的产品一定是有着一个独一无二的灵魂做为引导，形成的是一个整体上的构思，这与常年累月一步步优化下来的产品，有本质上的区别。
综上两种模式所述，只有创造与积累，才有可能产生所谓的卓越的产品。创造指的就是革新式的变化，积累则指的就是充分优化产品本身。所以说，我在这里并不是在一味地鼓吹产品不需要运营与优化，我想要表达的观点就是市面上的产品越来越多，大家都争着走一条路，开始时确实会很好走，也会得到认可，但是时间一长，当每个产品经理都开始如此行动时，也就接近这条路的末端所在了。
其实，说来说去，卓越的产品最后还是要回归到卓越的产品经理上，而不仅仅是框架式的教条上，教条上的积累永远不会历练出卓越的产品。
来源：yangguo1202投稿，作者Email：yangguo1202 （at） gmail.com
【非典型性UED思考交互设计（精选6篇）】相关文章：
我理解的产品经理岗位职责2023-05-03
产品设计师工作职责2023-02-03
三言两语：美国雅虎首页改版网页设计2023-08-30
UI设计师实习自我鉴定2023-02-17
ui教学计划2023-09-04
ui设计师个人工作总结2022-05-21
UI设计师年度工作总结2023-09-25
教学设计与说明of Section 1 of Unit2023-05-14
ui设计师转正述职报告2022-12-18
ui怎么写2023-05-23