稻草推荐的文章|
Web-based Product Design Process - Spiral Model.pdf 做互联网设计最重要是为了运营，蓝图和文档好比做作业打草稿、画画先描白，经验丰富可以考虑先省下这步骤。因为如果不表现在具体web-based原型上，蓝图、文档再好也无法快速切入开发流程，做为有大局观的Producer应该尽快意识到这点。 UED团队合作与开发流程优化是以前在雅虎做产品同事写的，雅虎团队的产品工程师们技术好，而且有来自美国团队的协作经验传承，做前端编程一直是他们的强项。但传统瀑布模型进程必然要面对“前松后紧”问题，根源在于设计、技术团队要互相等。因此，如果规避必须从观念上做出调整：快速产出、快速迭代，也就是软件工程里的Agile and Iterative Development。 以前我也常抱怨做互联网设计没谱，一是资源紧、二是变化快。项目周期和人手似乎永远都无法满足，来自内部考虑不周、外部竞争压力双方的需求变更频繁。其实这就是互联网设计的常态，接下来提到的方法，分为三个大步骤，版本仅供参考。 Alpha.快速完成核心功能开发这里“蓝图”只是个代名词，也许只有些蓝图片段，或规划片段。曾经我们在老板办公室开会，根据头脑风暴结果、会议记录直接做原型。这么说可能有点一觉回到解放前的感觉，事实如此，第一步很关键，但质量不重要。 因为开始就期望得到完善想法是不可能的。比如，你开会描述个东西，让同事提意见，可能大家什么都说不出来。但只要你动手做出具体原型，同事亲自测试体验之后，意见噼里啪啦一大堆就来了。在这层意义上，绝大多数原型是炮灰也应该。 最初工作用自己最熟悉、最快速的手法完成，别让开发团队等。当然，这部分代码质量将直接影响以后的迭代工作量，根据时间灵活安排。不要考虑的过于复杂，总结起来有三点：
每个业务都会有核心功能，也就是用户的核心需求，基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块，意思就是逐步提炼，找准关键点下手，这样才能搭好框架。也许经过几次迭代后，这部分工作已经是个可以跑起来的低保真产品，颇具alpha版本规模。 Beta.迭代完成固化需求功能开发搭框架不要下手太狠，别自以为经验丰富把盘子搞大。因为刚才说了，互联网产品灵活最重要，虽然需求变化是经常的事，但我们要把风险控制在最低点。接下来在已有框架内，用同心圆放大的模式，按优先级实现辅助功能迭代，直至需求固化。 与此同时，产品设计团队除了对低保真原型的继续支持，还应并行完善和提炼高保真原型，并且着手对产品规范中复用模块的持续化整理，主要分为三部分：
也就是说，在包括beta版本以及之前，重中之重是实现功能需求层的良好用户体验。可访问性、兼容性、可用性、标准化、搜索引擎友好这些具体指标不要过早引入到应用开发中，让它们都在高保真原型的迭代内准备就绪。 比如可用性，做低保原型时尽量用最容易的方式解决问题，不要过早追求“用户体验”玩花样。大量的js互动效果和ajax异步加载会给原型维护、迭代测试带来大麻烦。 再比如标准化，良好结构的web页面，很受应用开发工程师欢迎，样式表则无伤大雅。因此我们可以多花功夫先处理html结构，节省时间让css样式表与功能开发并行迭代优化。 Release.模块化迭代提升用户体验至此如果一切顺利的话，应用程序已经模块化并测试通过，设计规范也已经模块化、并有针对性的给出了高保真原型界面标准。用户体验的具体指标，已经在高保真原型的迭代中测试通过。 经验丰富的Producer可能都了解，成熟网站真正模块化后的内容其实不多，无非头、尾、导航、页签、表格、列表、搜索等等。传统方法流程的没有把操作体验与功能体验割裂开来，以至于来回折腾，反复做了大量工作才让产品模块化。根据设计规范迭代提升用户体验有两步：
永远记住不可能一步到位，花本钱的创意设计要用保守方案，用户体验是奢侈的。对多数应用开发工程师来说，使用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子，加上css马上就能风光起来，并且还不影响已经开发出来的程序，有点不可思议。 其他敏捷设计思路同样来自前辈们总结过的软件工程思想，只不过换在了设计支持角度。真正的敏捷设计必然与开发绑在一起，只在产品阶段的砍掉文档、砍掉步骤、砍掉管理对全局影响不明显。 对产品团队来说，应该不断利用等待空闲调整规划，用任务分解、故事板等专业手法出文档优化结构。敏捷设计关键不在技术有多高深莫测，而是动作要跟得上节奏，前后衔接得当，才可能把时间一点点抠出来。不墨守陈规，把专业方法打散使用，融会贯通于每个思考点。 UCD翻译小组的同学们已将Boxes and Arrows的这篇Prototyping with XHTML译成中文，操作细节和心得很丰富，关于快速迭代总结的相当好。类似方法我们也已实践近两年，并且主导执行过两款大型产品，核心思想超过90%重合，以上补充了部分本地化快速产出经验。 原文说“只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写xhtml。”事实上即使计算机背景的同学，没有两三年功力，要实现兼顾前后的无缝协作都很困难，搞不好还会返工增加工作量。但长远来看，这样的训练很有意义，用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。
团队成员越少，沟通效率越高；每人承担越多，整体风险越低。这是行云流水的产品、技术并行迭代的优势体现。总之，除对瀑布模型进程深刻认识，方法流程得靠团队的内力来推动。 from 稻草|自然.而然(V4uu.com) by simx.leizi@gmail.com(稻草) 2008-11-19 17:33 2008-11-17 虾米网beta版本上线了， 一个新的里程碑． 本来想说的挺多的，关于自己，关于虾米． 忽然发现一下子词穷了… 对于产品，对于设计的理解， 我一直都把她看成是自己的孩子， 我们允许她犯这样或那样的小错误 但在大的原则上不能够犯错误 现在的虾米就是这个孩子，她还不完美，她还着种种的问题， 虾米希望与用户共同成长，让用户都参与到对虾米的设计当中来， 因为虾米是为你们服务的，你们才是虾米真正的主人 我们都一样希望这个"孩子"能够茁壮成长:) 也许有人说我太理想化了，我相信你也一定看到本文的标题了 理想与现实，如果你不去做，那50%永远都是理想！ 关于虾米，关于音乐，我们需要做的还有很多很多． 随手画了张图， 也许这张图不太好懂，但我不是在讲概念，我也BS别人只讲概念．．  看完这张图片再去看看这里 也许会更容易理解一些 虾米一直要做的是将音乐这件简单而又纯粹的事做的更好，更细致. Better and better Love music,save music Ps: 又是许久不写blog了，得还给自己那么一些时间了:) 把拖欠自己的一些事情完成哈  这是支付宝UED团队的招聘。工作地点在杭州。 交互设计师： 文案创意：（参考资料） 前端开发： 联系：baiya@alipay.com
“如何来吸引更多才华横溢的人才？” 这个世界每天都在进行着太多变革。很多时候，我们都努力让自己用理性和数据来说明问题。 可是我们发现背后还有股无息的力量，理性和数据无法丈量。 商量了一下，我们决定讲个故事给大家。 描述在UED的真实生活，把每天经历平淡而有趣的生活拼凑起来，发现大家真诚的面孔背后有太多独特的品质熠熠发光。 这，是我们最大的财富。 于是，我们只用了四个工作之余的时间来完成了这个故事，让每个朋友了解这里的真实生活。 却也正是在这样平淡的故事中，回答了开头的问题。 故事依然在进行中，淘宝UED留好了位子给你… 最后，附上这则小广告的致谢名单，让我们默数他们。 “策划&编剧&文案&视频后期”：在天 “主演”：小马 “监制&统筹”：语凝 “艺术指导”：宗羲 现场分享：飞飞 文案翻译：晓荷 手绘插画：健刚 Flash技术：天行 前端开发：明城 from 思践语丝·思践 by 思践 2008-11-20 13:32
虾米网的路还很长，需要各位朋友一起来帮助。 写blog，最大的好处就是可以有很多神交的朋友，思践是其中的一个。 现在想想，之所以最后会选择偏居杭州，杭州兄弟们让我感受到的对互联网的激情、对创业的激情，是其中很重要的原因。孙权、思践、Fenng、KIMI、小兵… 07年底，我也曾试图在电子音乐这个领域创业，企图尝试“车载音乐”的市场创新。最后评估的结果是：没有很好的商业模式。遂放弃。导致我几乎对于所有的音乐网站，都持怀疑态度，一是因为商业模式和版权问题，二是因为可复制性。 那天，思践很激动、很投入的，给我讲他们正在内测的“虾米网”，听起来有些悬，但很有趣。后来跟Fenng一起又去虾米转了转，和他们的CEO南瓜聊了聊，拿走了一盘“杭州人民爱晚风”。有想法和斗志、有斗争经验、对事情充满热爱，是我对他们最深刻的感觉。再后来，虾米赞助了两期杭州“UCD书友会”。 对于虾米网，我一直有一种期待，一直忍着不去看他们内测的产品，等待着Bate的正式上线…
1、不要指望一开始种植的时候每棵花都是很完美、很漂亮，更不要指望他们可以马上很完整的摆放到一起。等你把整个产品修剪并拼装完成的时候，机会已经没有了，或者最开始的部分已经又长出了杂乱枝桠。 前天，虾米Bate版正式上线。 “高品质音乐”，是我看到的最核心特征，这也和我们当初评估的其中一个重要结论吻合：“音乐网站要想成功，必须做质量。推荐的质量、音乐的质量，真正能最终黏住用户的音乐网站，一定不会是那些压缩过的低质杂音”。而且，从目前的音乐内容来看，这个团队里那些专业做音乐的人体现了很好的价值，内容本身也是高质量的不可复制的。 虾米很小，但做的事情却很多，盘子很大。整体来看，这是一个比较新颖的模式，游戏规则、玩法都和传统那些音乐网站有所不同，涉及的领域和产品形态较广。音乐发布和下载、社区、P2P、电台、虾币体系… 也许每一条路都是正确的，都是迟早的必备服务。但，此时此刻作为一个新网站，把这些服务都打包放到一起同时推出，多少让人有些担心。 也许虾米的大理想，和完整的产品计划远不止我们现在看到的这些。但现在的东西实际上也已经足够多了，一下子端出来这么多的东西，对于用户的接受程度、新产品的维护难度、持续的运营和更新能力、后期的平衡调整能力都是一个不小的挑战。 我们需要高品质的音乐。祝福小虾米一路走好。 from 千鳥志 by 千鸟 2008-11-11 00:26
很多时候，往往以为自己理解了概念，却只有等再理解下个概念之后，才明白以前认识还不够。我们都是在某个点出发，逐渐放大试图了解全局，然后才可能正确认识自己的位置，并找到适合自己的突破口。 长久被专业名词困扰和误导，我知道它们肯定是一体的，但如何分类、组织、建立联系，让整个框架立体化，合理解释似乎并不是那么容易。基于自己现阶段知识结构，以及同行们反馈的各种观点，重点介绍新突破。
组织理念并分层思想信仰——以用户为中心的设计 接受来自IBM的概念定义启发，依次分为思想、目标、指标三大逻辑层面。关键在于指标问题上，我认为web-based产品因为客户端多样性原因，远不止可用性这一项，经过补充排序结果如下：可访问性、兼容性、可用性、标准化、搜索引擎友好。 可以看到可访问性、兼容性、标准化、搜索引擎友好都是web-based产品独有的，这也是做web比做soft麻烦的根本原因。相对来说，我处理可访问性、兼容性、标准化、搜索引擎友好，比可用性更得心应手，这与我的背景、经验和兴趣有关。因此我不会去做soft-based的事情，并且完全有理由相信，可用性不是最重要的指标。 理念只是贯穿全局的方针原则，并不具有实操的指导意义。虽然理念都有独立中心思想，但操作层面有交集，所以容易引起各种争论。在做事角度，任何理念角度深入下去，都可能不同程度见到效果。但要把事情做到极致，需要平衡各项指标。 组织流程和方法概念阶段——网站目标、用户需求、功能规格、内容说明 曾在纵深协作方式中提出扁平结构协作初步设想，减少沟通环节避免理解缺失，用灵活性来适应互联网的快速产出和快速迭代，整个流程就分概念、设计、制作三大阶段。《用户体验的要素》所提的战略、范围、结构、框架、表现五层对理解帮助很大，但不适合走操作流程。 同时，书中观点对应提出来的各专业方法，我认为还缺少对web-based原型工作的支持，因此容易造成与开发之间的断层。这部分俗称“前端开发”工作一直都处在前后不搭的尴尬地位，补充两个关键点，第一属于产品设计范畴，第二还有原型制作、前端编程两个层级。 组织角色和交付物产品经理——蓝图 曾在模拟高效团队中提出标配三人团队的初步设想，也是Google的行事作风。 交付物部分值得商榷，按照《Communicating Design》的总结有需求、设计、策略三类，但我认为有两大问题，第一把所有产出都叫documents欠妥，第二缺少对web-based产出的指导。按属性分为蓝图、文档、原型三类比较恰当，把蓝图从文档中独立出来，原型则是必要补充。 去年曾提出过使用页面线框图提速设计流程，也不止一次公开分享其成果，核心指导思想是提高灵活和可控性，用web的方式做web-based产品设计。最近更有Prototyping with XHTML作者称之为“一个伟大的方式从xhtml原型开始。”
关联理念、流程和交付物思想信仰——概念阶段——蓝图 理念都是前人花时间花精力总结出来的、带有哲学观点的清晰表达，是做知识传承的重要参考。肯定都是虚的，实际的东西没资格叫理念。理念只可能“引导”做事，而无法指导，易学难懂也最无趣。但为避免混淆，和更有针对性的解决问题，还得努力搞清楚。 典型如标准化，针对前端开发提出了一系列颠覆性思路，但目前互联网还是个市场占有率确定标准的时代。从操作层面看，四年前我认为太过理想化，现在依然保持此观点。 各层级概念应该对应到做事流程，并有阶段性的产出。在结合流程、交付物后，从这条纵向线索中很容易看清“以用户为中心的设计、用户体验、可用性”之间的区别。同理，迭代也应尽量保证在各阶段内完成。上线后的产品，再去试图更改概念阶段的游戏规则，基本等于推倒重来。 关联交付物、角色和方法蓝图——产品经理——网站目标、用户需求、功能规格、内容说明 曾在用户体验的误解中提出角色对应方法初步设想，我非常不赞同专业“用户体验团队”的协作方式，难道产品经理们做事不考虑用户体验么？还是说把用户体验先留着，等某些人来做？显然不可能，因为方法一旦脱离具体业务就成了学术论证，方法不可能创造结果，只可能加速完成。 根据专业方法制定角色，或走设计流程，我觉得都不可取。做互联网设计，应该学会身兼数职。况且所谓的专业方法其实就那么点东西，上手很简单，现在全球知识共享又几乎没门槛，学会做事太容易了。在人才培养角度，懂方法再熟练业务的难度，肯定要超过懂业务再学方法。 最好的Producer，有人可以带领大家做的更好，没人自己也能抗下来。 —————————— Ver1.1 为更细致体现专业性，对专业方法做出调整，继承《用户体验的要素》所做总结。  from 团队博客 - 以用户为中心的设计 by JunChen 2008-11-11 13:16 11月话题： 音乐功能和音乐网站 广州，广州市天河区科韵路16号广州信息港E栋 网易大厦一楼，请注意地点变更， 成都，天府大道北段1480号高新区软件孵化园十一号楼天府软件工作室2301，请注意地点变更， 杭州，淘咖啡，上城区南山路186号(柳浪闻莺对面) （地图），请注意地点变更， 北京，西直门附近奇遇花园（地图）， 上海，龙华路2577号，5号楼，BlogBus办公室（地图）， 南京，洪武北路55号新街口置地广场8层江苏都市网，请注意地点变更， 深圳，问道旅行馆南山店（详情）， 书友会详细信息：http://ucdchina.com/ 特别感谢江苏都市网，赞助南京书友会的场地。 转载请注明出自UCDChina.com，谢谢。 相关文章
想延续之前“设计师和美工”的话题模式，UI（用户界面）和IxD（交互设计）这两个非常相似的角色名词也一直让我迷惑了很久，明明在做用户界面的设计师，却被称为交互设计师，也就是交互设计做的其实是界面的信息结构设计或者高保真界面，或者交互设计师不清楚自己的工作范围应该涉及多少，哪些事情应该是自己的职责范围。 当然title怎么叫会根据公司或者团队的组织需求而不同，叫什么也许真的不重要，不过了解一下称谓的渊源应该还是有意义的。 普遍被接受的是，UI和IxD是两个互有交集的概念，前者需要考虑的范围要更广一些，也就是UI会包容IxD，或者说至少需要得到IxD的支持，IxD可以在没有UI的情况下先行设计，但UI就必须依据IxD来组织界面的操作流和页面需要表现的信息结构。
(Mac 1.0, 1984) 以上图苹果界面为例，设计最终呈现的包含了交互设计的集合（菜单，按钮，窗口操作）、形象化的图像按钮、窗口以及界面信息的排布方式。整体看到就是一个类似皮肤的界面样式，这也导致界面设计带有一定的局限性：如果需要表现各个操作的潜在表现，比如按钮在窗口中拖到的操作结构，就不得不借助交互规范来描述完成了。 通过这个例子，可以看出做UI设计的时候，会同时需要考虑到视觉设计，交互设计，信息设计,或其他更多因素。
所以从上面可以理解为，IxD则是从UI衍生出来的一个独立领域，主要专注于是如何让用户与产品在特定任务情景下的交互操作更有效、有用、有趣，这可能会涉及对启发式理论，控制论，人机工程学，规划理论等的具体应用，甚至在更多不同领域中将音频、视觉或空间等多媒体的综合运用在一起，比如声音识别交互，手势交互，触摸交互等。也许这也是为什么在欧洲的部分学校已经把ID从工业设计中脱离了出来，成为了一个独立的专业。
在网上找到上面这个类似想法的图片，也就是交互设计主要会考虑下面三个问题：
希望上面整理的这些信息能帮我们更好的理解以上两个角色的不同，在工作中把精力更多地专注于该做的事情上。如有不同想法，欢迎大家一起讨论。 参考内容：
人肉搜索引擎是人的胜利吗？是的，并且是人所创造的技术的胜利。 梦想是裁员无法阻止的，是金融风暴无法撼动的，是我们饿到半夜三点依然澎湃的指尖敲击——如果，梦想真的存在的话。 前端会议就是这样一件并不出众，但是让工程师们在一起讨论所有这些事情的聚会。 关于D2
详细介绍：http://www.d2forum.org/about/ 本届主题：“前沿技术和前端协作” 日程安排时间：2008年11月29日（星期六） 上午：嘉宾演讲 9:30 – 12:00 09:30 - 10:40 《Flash Player 10》 马鉴(Adobe) 下午：自由论坛 13:30 – 18:00 13:30 - 14:40 《IE8 as future platform》 待定(Mirosoft) 注意：以上安排可能会根据具体情况进行一些补充与修改。 关于嘉宾马鉴 (Zerlot Ma, 七月) 史珉 (Aspirin) 许湛 (Justin) 李戎 (小麦) 郑叶飞 (怿飞,圆心) |
|
||||||
| 上一页 1 2 3 4 5 6 7 8 9 10 ..62 下一页 |
