所有文章 - UCD大社区

关于“要不要做调研”

白鸦 — 2012-01-31 20:47:59

说在前面：以下说的“调研”主要指用户调研。用户调研的方法有很多种，下文所提到的并非只是“问卷”和“数据分析”，还包括访谈、焦点小组、可用性测试、等等。（推荐UCDChina上一个很早的话题：用户研究的一些方法）。ps，以下观点基本仅指“互联网”领域，请勿拿“我们挖煤的时候这么干就不行”来说它是胡扯。

—

乔帮主虽然走了，但他的故事在被更广泛的流传，他利用媒体的能力依然在影响着这个世界。曾经和曾经，在媒体问及苹果产品的调研时他分别说过这样的话：

1、人们不知道想要什么，直到你把它摆在他们面前。
2、贝尔在发明电话之前有做过任何调研吗？

于是，越来越多的懒人们终于有了”神”的庇护，堂而皇之的开始“不调研，只拍脑袋”；越来越多的“果粉”也开始了对“不做调研”的盲目崇拜。他们还在不断的嘲笑和鄙视那些去做“调研”的人，鼓吹“创新不需要调研”。

上周苹果对部分iPad用户发送了调研问卷，很多人在微博上嘲笑说：乔帮主走了他们不得不做调研了… 每当看到有同事转发这些言论信息，我都得很谨慎自己的跟他们谈一谈“看法”：

1、乔布斯说这话有两个语境。一个是在MAC刚刚发布的早早期，一个是在他玩弄媒体的时候。离开了这样的语境这话大多数时候并不能适用。

2、在反问完“发明电话之前有做过任何调研吗？”的两三年后，乔布斯离开苹果创建了NeXT，初期的简单定位是给高校研究室提供电脑。他的团队去做了很多的反复的调研，他自己也非常喜欢和主动的去做这些事情。（读过《乔布斯传》的果粉们可以温习一下NeXT那一章，里面有写）

3、通常苹果公司在他产品的第二代开始就会对用户发放问卷进行相关调研（第一代产品的调研往往只能通过第三方去做，或者自己通过现有产品的调研去做，所以我们感觉不到；而且那个时候也并没有可靠的样本群）。据说他们每年对于市场数据的研究和外部市场的用户调研都非常重视也非常频繁，而且他们对于苹果的品牌调研也是相当的频繁和认真。忘记在哪里看到过苹果找尼尔森做第三方调研的相关资料；有兴趣的果粉也可以自己去搜索一下苹果N年来的相关调研问卷，很多。

4、说了这么多，但我其实并不是一个对“调研”的依赖者和迷信者。虽然我非常相信“真实有效的”数据调研的作用，但“真实有效”这三个字往往意味着“高成本”和“耗时长”。

特别是对于互联网产品，虽然他比较容易找到数据，但也更容易因为数据的过多也被垃圾数据干扰和迷惑，分析过程出现偏差和出现“为了证明自己的观点而拼凑数据”的情况非常正常，多数人都难以避免，包括那么经验丰富的家伙们。而且，对我们眼前的这样一个环境，往往你能轻松拿到的数据都是不会是真实的…

5、往往在产品的早早期，我更愿意相信在一定数据支持下的“领导人的嗅觉”。因为，多数互联网产品很难等得了严谨的漫长的调研过程，而且往往要想通过调研去得到“真实有效”的结果，比让“领导人拍对脑袋”的可能性更小。所以，我经常会说：“信你们这帮人随便捞来几个数据而推算的结论，还不如信我或者信咱们其中某人个人的嗅觉”。

总之，在产品的早早期，我的观点是：一帮人看假数据或者假装看数据来“拍脑袋”，还不如让一个平时更懂用户的人（在一定的数据支持下）去拍脑袋。其他人靠直觉选择“信他”就够了。

6、到了早期，一定的用户调研是完全有必要的，因为这个时候可以比较明确的知道要什么信息，“垃圾数据”也就少了，推断结论也就相对靠谱一下了。不过，这时我更相信“测试”的结果，还是那个观点：“怎么做都是错的，只有是面对用户的时候才可能不会错。而且还得是一定量的真实用户”。早期的互联网产品，拳头轻轻过去，听到叫疼了再猛踹一脚比较好。因为“需求预测”错误的可能性是99%，所以控制早期的试错成本是必须的。

总之，在产品的早期，我认为最有效的方法是：用最低成本，尽可能的真空环境（雷军的说法），最快的速度去做用户需求测试，需求有就发力，没有就得掉头重找。

7、到了产品的发展期和优化期，用户群已经培养出来，需求方向已经明确。该做的就是：让用户推着产品走。这个时候，没有比“用户调研”更管用的方法了。（所以，往往我们会习惯性的在早期圈好“种子用户群”，让他们给提供更直接有效的帮助和意见）

其实，没有一个科学的方法是错误的。其实，也没有一个方法是万能的。我更相信：不否定一切也不肯定一切，灵活应用，适时而变。更更相信：搞清楚了谁是我的用户，是一切调研、创新、设计、拍脑袋的前提。

源地址：http://uicom.net/blog/?p=912

苹果产品开发的绝密工作流程

Abner Tsang — 2012-01-30 22:00:54

长期以来苹果产品开发流程在很多方面都笼罩着一层神秘的面纱，而在Adam Lashinsky新发行的《Inside Apple: How America’s Most Admired–and Secretive–Company Really Works》一书中对这些流程有所涉及。这本书同时谈论了苹果公司各个不同的方面，包括其理念、招聘流程以及传说中的秘密等等。

苹果始终坚持同一产品开发流程，这也是其多年魅力不减的原因所在。在接下来的这些要点中，有些可能是我们已在其它地方见过的，而有些却是新的。以下为任何苹果产品在开发时都需遵从的框架：

设计驱动产品

在苹果，设计师就是上帝，所有的产品都需符合他们的要求。这一点可能在其他公司恰好相反。与其他公司中设计依附于生产部门不同的是，财务和生产部门都要满足以Jony Ive为首的设计部门的要求。

苹果的设计师就单纯的只管设计，无需与财务部门打交道或考虑成本问题，也不用考虑设计所使用材料在生产时怎样使用。苹果所有产品都孕育自工业设计工作室。它们在那里诞生时，仅有包括Jonathan Ive在内的少数苹果员工能接触到。

构建公司内部的“start-up”

在新产品得到确认后，整个团队的成员都会被组织起来签订保密协议，有时甚至可能从物理上进行隔离。为了给负责这个敏感新项目的团队腾出空间，部分办公区域会被封锁或警戒。这就在公司内部有效的建立起一个仅由执行团队负责的“start-up”，并使其从整个公司的组织结构中独立出来。

执行苹果新产品进程（ANPP，Apple New Product Process）

一旦开始产品设计，ANPP便进入执行阶段。这是一个详细描述新产品开发进程中每一步的执行文档。虽不是独创的苹果理念，但首次应用到企业却是在苹果进行Macintosh开发时。它详细筹划了开发的各个阶段，例如，谁负责完成；各自在每个阶段负责什么内容，以及在什么时候完成等。

每周一次产品评估

公司高层会在每周一仔细检查进入开发流程的每个产品。因为苹果在任何时候都只有少数产品在生产，所以这是可以做到的。不会让任何一个评估延后到下次。这意味着产品的关键性决定没有一个会在超过两周的时间内做出。

EPM绝对控制生产

在产品生产时，需要一个工程项目经理（EPM，Engineering Program Manager）和一个全球采购经理（GSM，Global Supply Manager）负责管理，直至完成。前者在产品生产过程中拥有绝对的控制权。因其权力很大，所以也被称为“EPM黑帮”。这两个职位一般都由公司高层担任，且其大部分时间都是在监督中国工厂的生产流程。采购经理和项目经理会相互合作，也会经常因决择“什么最适合产品”，而备感压力。

反复设计、生产和测试

事实证明，在苹果制作好产品原型后，将再次进行设计，然后再将其投入生产。这也解释了为什么有时在我们看到一些泄漏版本的产品后，却始终不见其发布。而这个过程大概会持续4-6周。

EPM会带着测试版设备返回总部接受测试和评估，然后再返回工厂监督下一个产品。这意味着很多版本的产品实际都已经“完成”，只不过是部分的原型。这是一种极其昂贵的新产品开发方式，但在苹果这就是标准模式。

独立的包装设计区域

在营销大楼里还有一片完全专注于设备包装设计的区域，其安全性与专注新产品和设计的专用区域相当。在某新款iPod发布前的一段时间，曾经有一员工在数月里每天花费数小时打开了数百个包装原型，以此提炼打开包装这一过程的用户体验。

绝密的产品发布计划

产品发布行动计划被称作“the Rules of the Road”。这是一个高度机密的文档，上面列出了产品从开发到最终发布过程中所有的重大阶段目标，且每一个阶段目标都注释有主管该目标达成的直接负责人（DRI，Directly Responsible Individual）。丢失或泄漏这个文件的人将被立即解雇。

如你所见，苹果为了追求产品的卓越，经常会做一些增加成本和降低效率的决定。也有许多公司做事太过复杂，或过于墨守成规，并试图把苹果的流程完全照搬。尽管如此，苹果的责任制方案仍可简单地归纳为：致力于好的产品才是第一位。当然这也是造就苹果十余年财富神话的原因。

上述产品开发流程仅是Lashinsky书中的部分，想了解更多的话可以考虑仔细阅读一下这本书。

Via TNW

除非注明，本站文章均为原创或编译，转载请注明：文章来自36氪

源地址：http://www.36kr.com/p/79208.html

注意力与交互设计

Aaron — 2012-01-30 21:45:24

以人为本的设计，不能不考虑普通人在一般任务执行中的耐受力问题。因为人的精力有限，再强大的需求，无力去完成也是枉然。精力的有效转化率，是衡量交互设计品质的重点。

1.公式
精力一般由脑力和体力构成。针对互联网产品，脑力居前（非生产类网站的体力消耗很低）。而脑力的组成又分为注意力、理解力和记忆力。本文将尝试以注意力为例分析交互设计的特点和注意事项。
注意力本身可以集中、分散和转移。集中一般出于明确的需求、潜在的兴趣；分散则由于信息干扰和不可控的时间；转移一般发生在需求探索阶段。
以网站信息结构内的各元素为单位，加上每个页面的所有视觉元素，可以得到网站总的注意力“项”。用户就是利用这些项去满足自己的需求，交互设计则是这些项的描绘者、组织者。如果假设注意力有限，那么每个项分享到的注意力应该是固定值。加上因为个体差异，兴趣和需求的等级不同，便得到了以下公式

注意力转化率计算公式

其中除了“需求强度”以外，“兴趣浓度”、“时间长度”和“可视项数量”三个值，交互设计都可对其产生影响。
2.兴趣浓度
用户在网络上的操作习惯和交互预期，有自己独特的心智模型，有时与现实生活中是不同的。比如现实中我们对图片的要求只是看，挂在墙上或拿在手上。而互联网首先是一个超链接整合平台，其次才是一个展示平台。所以上边的图片除了看，还被赋予链接的预期。人们对它的期待变得更加丰富。因此，赋予图片更多交互内涵可以直接提升用户的兴趣值。
对兴趣的两个典型设计思想是，图胜于表，表胜于文，还有拟物化设计，包括拟物的文案。可以说对象越具体，人们就越觉得安全和亲切。而亲切有礼的，符合物理定律的，对操作及时反馈的，满足情感需求的设计，都可以为兴趣加分。反之亦然。

不可用状态不是好的设计，尤其当激活它的条件比较多时

正是基于人们对图形化的向往，视觉设计才会对交互设计产生不可低估的影响。个人认为交互设计中凡是与兴趣相关的部分，视觉都应该成为重要的参考因素。比如控件的颜色，文案的排版，链接的展示方式等等。
3.时间长度
互联网交互设计和日常用品交互设计的一个重要区别，还在于两者的时间观念。现实中，时间是重要成本，经常影响人的决策和情绪。网络环境中，体力和人际负担被充分弱化，时间大部分只是个人脑力成本。如果需求和兴趣衔接的好，时间甚至可以忽略。
不说游戏这种极端的例子，以平常产品的加载时间为例，如果以兴趣为导向处理得当（进度条和微型漏斗等时间计算工具属于此列，而预加载则属于需求衔接），用户也不会产生太大抱怨。涉及到搜索、寻找、浏览等注意力分散的情况，用户几乎只关心项而不关心时间。
需要注意的是，流程性比较强的任务，开始和结束都要有明确的提示，以防止注意力溢出，造成不必要的精力损耗。

任务完成提示可以防止精力损耗

4.可视项数量
一般来说，交互设计的重头工作是项设计。如确定信息结构、元素词典、视觉形式等。为什么说可视项数量越大，注意力越小呢？这是由认知特点决定的。选项越多，步骤越长，人越需要耗费理解力。理解力带给人的压力比较大，需要求助于向内的注意力，把注意力的任务属性，转向逻辑属性，造成交互能力降低。加上对注意力转移所使用时间的预期，对鼠标和键盘操作的苛求（体力），人们普遍反感冗长的表单，页面跳转等情况。于是便出现了“响应式展开”、“弹出泡”、“弹窗”、“标签”等交互形式。

项的组织和展示方式是大课题

除了可以利用好的组织方式来“减少”可视项数量，元素词典、视觉形式也可以影响兴趣，利用兴趣来提升注意力。以元素词典为例，作用主要发挥在关键词上。如“推荐给你听”和“我们一起听”中的“一起”，“你可能会喜欢”和“朋友们也喜欢”中的“朋友”之类。阿拉伯数字的注意力明显高于中文数字。“删除全部”的反应速度也要快于“清空”。如果不考虑使用环境，“删除张三的微博”和“删除微博”，那个效果好？
5.总结
交互设计作为一门过程科学，需要一定的时间和精力损耗。从互联网领域看来，因为排除了体力因素，注意力变得尤为重要。以注意力转化率为契机，我们可以把交互设计向用户体验设计推进一步。
注意力和理解力的结果是记忆力，关于记忆力对交互设计的影响，下次再交流。

源地址：http://uedc.163.com/8898.html

敏捷开发思想谈（二）

song — 2012-01-28 13:35:38

敏捷开发思想谈（一） http://ucdchina.com/snap/11431

版本持续统一的意志

为什么需要版本

验证乐趣

我们的设计在我们的脑海里，很可能和在别人脑海里得到的认识是不一样的。

或许大家都能有幸得到统一的认识，但是做出来实际体验的时候又不一定能够符合我们的预期。

就算符合了我们的预期，也许我们玩的时候会发现一些新的点子可以很容易的加入到游戏，并且大幅度的提高游戏性。

所以，多个迭代版本的目的，首先就是为了：验证我们的功能是否符合我们的设计预期。因为:

l 没有实际玩到之前，永远不要相信自己的设计是OK的。

我想强调的是，这里的设计预期不仅仅涉及到我们的功能，事实上作为游戏开发，功能开发永远只占其中的一小部分，还有大部分的时间我们需要用来调整，优化，修改，以达到我们的真实预期。

换一种说法，这里的预期除了功能以外，还有我们对它的感受，也就是这个功能到底好不好玩。而我们关注的重点，也是在好不好玩上。如果只是关注于功能是否完善，那么我们的版本就还离成品有一大段路要走。

所以迭代版本应该是计划功能均可玩，并且没有会阻止我们体验所有需要体验内容的BUG的游戏版本。它是我们评判一切的依据，因为一切功能，一切资源，一切玩法，在进入版本可以被我们体验之前，都存在不确定性，只有最后经过版本的体验，这一切的不确定性才能消除。

持续集成

其次，敏捷开发的要求是快速迭代。但是这里的快速迭代其实远比大家想象的还要快速。或许大家觉得正确的快速迭代就是每一个周期，或2周，或一个月就需要一个版本出来。迭代速度比起传统开发确实快了许多，版本也多了许多。但是事实上的快速迭代远比一个周期要短的多。理想的快速迭代，应该是：

l 每个功能，每个改动完成之后都有一个版本能够立即对功能进行验证，进行体验。

让我们对游戏的改变把握得更直接和高效。让大部分对游戏方向的修正都发生在开发当中而不仅仅发生在周期的开头或者末尾。原因就如我所说，每一个功能从完成，到有乐趣，都需要有一个打磨的过程。在打磨之前，很有可能这个功能根本没有乐趣。所以实际上，我们一周要开发一个功能，很可能我们前4天就需要把功能开发完毕，周四出一个版本进行体验。然后周五针对周四的反馈进行一些BUG修正和反馈修改。之后乐趣才出的来。

是的，如果是理想情况的话，每一个功能无论大小都应该是这样的一个流程。哪怕是一个只有半天开发周期的功能，我们在3个小时开发后也需要出一个版本对功能进行验证，并提出反馈改进（如果有的话）。之后优化到大家觉得这个功能合格或者有存在的价值之后，我们才会继续下一个功能。

这样的过程当然过于理想化，每一个功能我们都可以几乎无限的优化下去。所以我们也需要对优化的程度进行取舍。这样取舍的标准还是最终会基于我们开发者自己的个人能力和标准上。更重要的是，我们需要建立每一个功能和变动都需要一个版本进行验证的意识。进而才能追求我们的版本质量和效率。

冲刺的艺术

效率

敏捷开发绝对不是牺牲效率追求品质的开发模式。

相反，在每一个迭代当中：

l 效率才是需要追求的第一位。

唯有在尽可能快地发布版本之后，我们才能根据版本的反馈，进行修正。进而得到更好的版本质量。大部分时候，我们需要的仅仅是以最快的速度得到我们需要的原型。验证我们的设计。为此我们需要尽可能的追求效率。

那么，如何得到我们需要的效率？

范围

首先，永远不要做多余的事情。一旦目标明确，那么我们的目标就是所有我们要做的，在目标范围内的质量优化，必要的代码改善，必要的体验优化，都是可以做的。但是离开了我们目标范围的事情，一件都不要做。

这里的范围，则是一个度量。而这个度量的划分，则又一次，需要依据我们这些人来判断。它需要我们深刻的理解到，我们制定这些目标的意义，我们要实现的究竟是什么，我们应该优化到什么程度？

我们有多少时间，那么我们就只能设计到什么程度，做到什么程度。而更多的次要的需求，我们有时间再考虑，更多的兼容性想法我们可以想，前提是我们这个版本还有时间。我们需要画一条基准线，在有限的时间里，我们能做多少内容，该做哪些内容？一切行动都需要以我们的目标为准则。当然，我们还需要考虑量产和下个阶段的准备工作等等（然则，这些其实如果规划的好，应该可以算作这个周期内的目标之一）。但这些都需要服从于当前版本的开发。全力开发我们需要的内容。

因此我们需要避免过度设计，过度开发，以及过度优化。我们需要将效率作为我们开发的准则。

人员

永远只涉及必要的人。为什么我们要进行小组化开发？因为人员牵扯一旦扩大，唯一的结果就是效率降低。各种意见难以统一，管理变得困难，计划难以统筹，任务分配变得困难等等。所以最佳的小组规模应该在7人前后。

仅仅如此么？当然不是，我们不但要确定小组规模并且将小组开发与外界的干扰屏蔽开。我们还要确定我们项目开发的流程中，每一个步骤所要参与的人员，哪些是真正必须的，哪些是不必参加的。确定人员的职责范围，首先他们需要专心于负责的部分，之后才涉及力所能及的部分。

在这里，需要解释的一点就是，敏捷开发并不是所有的决定和步骤都要大家来参与，以增进组员责任心和归属感的。为了最大化效率，我们永远只让必要的人来做必要的事情。比如故事分解为任务，只需要小组成员，和相应的主程主美主策。比如故事本身的优先级划分，只需要核心组成员（更加通常的情况是只有PO）参与即可，小组成员没有必要参与。再来，版本体验会，我们需要的是真正的指导性的意见和重要的人的声音，如果需要专门组织一个会来听小组成员对版本的反馈，我觉得那小组成员平时就不知道是干什么去了。我们需要在组织每一场会议的时候都考虑到，是不是每一个到会议的人都是必须到的，因为我们找他来开会的时间，都本来应该是他开发和工作的时间，而那才是我们的重点。

高效会议

最后，我们需要有一个清醒的认识，过多的会议永远都是高效率的开发的大敌。一个会议10个人，一小时，意味着我们会损失10个人时的工作时间。而实际上一周的工作中，我们一个人时都是损失不起的。当然，这并不是意味着我们不要开会。而是我们需要意识到我们的会议究竟是否有必要，如果有，那么会议效率是否足够？我们是否有足够的会议准备和计划，能够保证我们会议的效率？还有我们是否有相应的会议章程，会议时限？这些都是我们需要考虑的，用以高效化会议，减少时间浪费的重要方法。

所以，当我们思考效率的时候，不妨真的来看看我们现在的开发，分析一下一周的工作中，究竟开发的时间有多少？其他的时间又有多少。看看到底是什么在影响着我们的开发，是否有方法，或者措施，能减弱这些影响。最终进一步加快我们的开发？

开发的脉络

交流

非正式沟通

交流，在敏捷开发中，是永远都谈不够的东西。也是永远会存在问题的地方。在敏捷开发中，我们会重视交流而轻文档。原因？只是因为交流永远比文档更高效。

并非我们就此放弃文档，文档最终会变成记录我们讨论交流结果的工具，便于未来查阅。高效的原因是，在交流的过程中，我们就可以共同修正分歧，修正个人的错误，并且将信息传达给对方。当然，一切都还仅仅是基础的东西。

进一步的是，究竟如何能让我们的交流高效？首先，必须明确一点，会议并非是高效率交流的良好方式。更好的交流，应该更多来自于更频繁的，更多的非正式的沟通。把所有人拉到一起，强迫他们发言，或者收听，并非能很好的传递信息或者进行讨论。而鼓励他们进行自发的讨论、交流、在每天，在所有的闲暇，都可以进行一些思想，一些想法的发散、讨论。这才是最好的情况。

我们当然也可以就此进行推动。更多的不是人为的设置一些刚性讨论需求，而是制造一种推崇各自讨论的氛围。

邮件

其次，是我们交流的方法。我们有没有真正考虑过，哪些内容我们应该放到正规会议上进行宣讲？哪些内容我们只需要发一封邮件，并收集回信的反馈？哪些内容，我们只需要找到相关的人，非正式地谈论一下就可以得到解决？这些分类一旦清晰，能够为我们的团队节约多少时间？

从另一方面来说，有多少内容我们甚至连邮件都没有发出，完全变成了个人的地下行为？在这里，我想强调一下关于邮件的作用，在原来的公司，我们被要求尽量少使用邮件，因为某个时期，员工们甚至把所有需要面谈的内容都用邮件来代替了。距离5米的两个人甚至一周几百封邮件却没有一次谈话。

而在现在的环境中，邮件却变得相对冷落，很多应该有邮件作为记录，或者应该由邮件发出的内容都借由其他的方式或者没有以任何方式发出。比如现在很多的策划文档，每一次更新，只有一定几率会有邮件通知到大家。比如会议纪要，当然这都还是表现的比较好了。再比如不太重要的设计文档，这些都可以借由邮件发送来让需要知道的人了解，并且相比专门的宣讲会，节约很多的时间。大家只需要看完之后，把反馈意见用邮件发回就可以了。所以，我们可以考虑是否完善我们对于邮件的使用？更重要的是，是否我们可以进一步提高我们对于邮件使用的意识？我相信，这会是一个很漫长的过程，但是必然能够极大提高我们办公的效率。

其实终究，还是我们考虑问题的方式，我们是否能够意识到我们现在的交流方面的不足，是否能够开始改进？这将是我们是否能够继续成长的关键。

项目的基石

人

谈到人，其实就是谈到整个流程和过程中最关键的地方，最关键的元素，也是决定一切事情成败的根本。无论多好的制度，流程，如果没有相应的，合格的人来执行，也只会是失败的结局。那么，在敏捷开发中，或者说在游戏业的敏捷开发中，我们需要什么样的人，我们需要什么样的素质和要求，才能更好的运作这个模式，更好的做，并且做出更好的游戏呢？

迭代的意识

首先，是改进的意识。永远记住，没有完美的东西。我们需要保持清醒的认识，认识到我们的项目；我们的流程；我们的文档；我们的游戏等等，都还有可以改进的地方，都还有很多可以改进的地方。改进是没有终点的，我们需要能够找到这些可以改进的地方，我们还需要可以找到改进的方法，并且切实的推行下去。这样，我们才能在一次次迭代中，得到更好的项目，更好的版本，更好的团队，等等。意识到我们有问题，我们才能够改正这些问题。从某种意义上来说，其实这也是迭代的意识。

效率的意识

其次，我们需要效率的意识，我们要明白，最终，我们是在开发商品。我们是在进行商业运作，所以效率是我们需要真正关心的。而效率的重点并不是每天在公司里花了超过8小时，而是我们的时间是否都真正被有效利用起来了。我们是不是真的在需要的时间内，给出了需要的成品。是否这些成品能够合格。每天做的事情是否有意义，是否能够给予我们的工作和项目帮助？我们是否能够抓住我们工作的重点？而不是浪费在无关痛痒的地方。我们需要考虑我们的工作是否是向着目标前进的，是否足够，是否有效率。要做到效率，我们就需要首先明确我们的目标，其次清醒的意识到我们在做的事情，最后再反省是否有无效或者被浪费的地方。是否我们能做的都做了，是否我们把不需要做的也做了？

理解游戏

再次，我们需要有对游戏的把握。毕竟，我们做的是游戏，如果做的人都不知道什么是游戏，那么如何能保证我们做出来的游戏能被人喜爱？甚至，我们如何能保证我们做出来的游戏，是游戏，而不仅仅是一个选择播放的技能地图预览器？所以，首先，我们大家都需要了解游戏，了解什么是游戏，游戏包含了什么；游戏性是什么；核心玩法是什么；主要模式是什么；画面表现是什么；音效是什么；故事是什么，它们是如何结合的，是如何组合成一个游戏的。不同的游戏类型里，这些要素又以什么比例组合，哪一个更加重要。这些都是游戏开发者所需要了解的基本。进而，开发者才能明白，我们现在的游戏已经有了哪些元素，还差哪些元素，已经有的元素是否足够，是否还有所欠缺。这时，合格的游戏开发者们，才有能力说出，我们的开发方向在哪里，应该补充什么元素，有什么欠缺的地方。这样，我们才有能力，做出一个至少完整的游戏。

开发者的野心

进一步，我们如果还有野心，并非只是做一个完整的，良好的游戏，我们还想要有创新，想要做一款让人眼前一亮的游戏。那么我们就不只要了解什么是游戏，我们还需要对游戏有自己的理解和想法，我们需要有自己对这个游戏的未来的想象，并且时常将之拿出来讨论，碰撞，最后留下那些可行的，优秀的方案来实现。我们每个人都需要对我们的游戏有所希望，并且这些希望都是需要时常在我们的大脑里酝酿的。这才是游戏开发最有趣的地方，我们总是可以实现我们脑海中大胆的想法，我们总是可以把我们有趣的意见，点子说出来，如果能够得到大家的赞同，就可以实现到游戏里去。做游戏应该是有趣的，而不是每天重复枯燥无聊的劳动。所以，我们需要思考，并且说出我们的想法。

快乐地制造快乐

用心制造快乐，是不够的，还需快乐地制造快乐。让我们并不仅仅是麻木的工作着，而是真的有趣的去做有趣的事。这才是做游戏的本意，这才是大部分人最早加入游戏公司制作游戏的本意。如果我们做的东西连我们自己都无法说服自己，“那是有趣的。”那做出来的真的能有趣么？我们在做游戏，之后才是工作。如果整个游戏，都没有一点自己的心思在里面，那我们就真的只是在勤劳的上下班了。

而且也只有相互间的思想，想法在碰撞，才会做出有意思的游戏。游戏的设计并不仅仅是策划的事情，游戏的需求也不仅仅是由策划提出。只有大家每个人都可以针对游戏的缺陷，乐趣，玩法能有自己的见解，每天争的面红耳赤，那才是真正做好游戏的取胜之道。在游戏性的讨论上，根本没有策划美术程序之分。

对游戏工业化开发的把握

最后，我们还需要有对游戏开发的把握，对整体的把握。我们是否知道我们现在处于游戏开发的哪个阶段？这个阶段应该重视那些东西？应该注意那些东西？这个阶段我们应该完成那些东西？对于这些我们是否有清醒的认识，清醒的计划？

我们是否有对我们项目的整体规划？知道我们现在要做什么，知道我们下一步还要做什么，这才能让我们明白我们现在做的是否有意义，是否有效率，是否正确。我们的目的，绝对不是过GR1，2,3,4,5.这一点大家应该明白，我们始终都是在做游戏，如果我们的方法正确，计划正确，那么这些评审对我们产生不了任何影响，那么既然我们每次都需要针对这些评审改变我们的流程计划，那么是不是也意味着我们本身的计划也存在一些问题？这个问题大家也许可以思考一下。不要让问题找到我们，而是我们去寻找问题。

故事WHY ME? WHY STORY?

为什么要使用故事？

我们为什么要使用故事？要理解这个问题，首先要理解故事的作用。那么故事的作用是什么？

消除理解误差。

早期软件开发的需求方往往不懂任何技术，开发者的功能清单却往往难以让需求方有直观的对最后成品的认识。比如，或许一个功能描述是，“战斗场景分为5层可以根据摄像机的移动而相对运动”，但对于非专业人士来说，他们可能无法理解这样的描述意味着什么。于是故事开始发挥了它的作用：以一种大家都认可的方式让所有人对我们要做的功能目标有清楚的认识。

所以：

l 只要能够让全体人充分意识到我们功能开发的目标以及内容，那么它就是一个很好的故事。

对我们来说，这样的共识需要在策划，美术，程序等人员之间达成，所以我们的故事也需要以一种大家都能理解的方式来表达。而更重要的，不是故事的方式，而是确实所有人都能够完全理解。具体怎么写，其实真的怎么写方便都可以。

整体统筹估计和管理。

由于故事是从系统和结构的层面，以一定的高度来描述我们整个项目的框架功能，所以我们可以以较快的速度全面了解我们的功能点，而对于这些功能点，我们还可以进一步快速的给出粗略的估算。进而得出整个项目的大概工期或者每个迭代我们可以完成的故事数量。这里的估算往往是由不准确慢慢到准确的。

l 每一个周期，每一个项目的历史数据都可以让我们之后的估计更加精确。

而且这样划分的工作，可以更好的交付给不同的小组完成。小组内部进一步自行组织计划，使得我们的管理工作可以分散到小组，降低管理难度。

创意管理

本质上，游戏就是已有的同类游戏的完整功能点，加上我们独特的创意。完备的前者能让我们的游戏成为一款合格的游戏，而后者的加入则让我们的游戏变得独特。引入故事后，我们可以总是在一个层面，对功能开发和创意尝试的投入进行平衡，相互以取舍。我们可以总是以功能和创意的价值来判断真正对我们有价值的开发顺序。

故事在讲什么？

什么是故事?

首先，故事本质上依然是功能点，依然是从需求中抽取出的一个个系统功能。只是以一种所有人都能理解的形式进行描述。所以，为了能够让所有人能够理解，故事仅仅只从实现功能的目的来描述这个功能：

l 故事是对功能的目的的描述

同时，故事是在讲述这个功能究竟是发挥什么样的作用。所以它本身价值只是简单描述和给予一定参考。

l 它不是，不能也不需要详细的描述这个功能的所有细节和玩家对此的感受。

因为前者有相应的策划文档，后者难以文档化以标准衡量。

所以，当我们要验收某个故事的时候，并不是我们比照着一个个故事，来体验游戏。看一个个故事是否在游戏中完整的实现了。

正确的故事验收，应该是在这个故事在组内达成统一之，所有人就应该知道要做成什么样子之后。将单个功能的验收在周期内

就实时完成。而在最后版本发布之时，对功能进行检验，检测这个功能的最终效果是好还是坏。

我们的目的不只是要看是不是功能A,B,C,D已经完成了，我们应该再深入一步：

l 关注于功能是否得到了很好的效果，符合了我们的预期

l 在游戏开发中，则是，是否有了乐趣

l 是否有其他想法，能够让这个游戏更有趣

因为仅仅是功能的集合，并不能成为合格的游戏。

因此，我们也需要改变我们对于设计目的的定义：

l 我们的目的并非仅仅是完成某个功能，而是功能能否达到我们需要的乐趣。

带着这样的思路，我们才能真正的在版本回顾的时候，给予能够指导我们开发方向的反馈，而非仅仅是针对我们功能开发的完整与否，发表意见。

作为核心组成员，或者，作为整个游戏项目的一员：

l 我们不应该仅仅关心于完成情况，各种细小的错误。我们应该看得更远，思考的更远，给予我们的开发真正能提升最终质量的帮助。

最后，故事包含对它大小的估计，我们可以使用这个估计来对将来的工作和计划进行评估；对它本身价值的估计，让我们在选择他们时可以参考。简单的来说，就是另一些附加的功能。

用好你的武器

如何使用故事

故事的来源

第一，从已有的游戏设计文档或者框架中抽取的，比如，我们已经知道我们要做的是一个回合制战斗的游戏，那么我们就可以抽取出，基础战斗指令，回合制战斗流程之类的故事。

第二，新出现的创意性质的内容，比如，今天我突然想到在回合制战斗中加入行动顺序条或许是个很有趣的点子，我告诉大家，大家也觉得这个东西很好，于是我把它加入到清单中。

第三，当我玩到某个游戏的版本的时候，发现，某个功能给我的反馈不是很好，或者我觉得可以如何改进，能够让这功能变得更好，那么也可以放进到故事清单中。

故事的使用

首先，我们有一个用来维护故事的列表，术语叫做产品订单，里面罗列了所有我们已经完成或者没有完成，重要的或者不重要的故事。我们可以在里面清楚的看到：

l 故事的描述

l 故事点（大小）

l 优先级（价值）

l 当前状态

于是，在每个迭代开始的时候，我们都将故事从大到小排列起来，依据上个版本我们能完成的故事量（以故事点来衡量）来选取我们这个版本需要完成的故事内容。

故事选取完成后，下一步，则是让整个小组对故事的内容达成统一。也可能只是统一目标，而某些细节在完成的过程中确定。这过程的形式，依然并不固定。

当大家对故事的内容都有所了解之后，我们可以开始对故事进行分解。得到相应的详细的任务。任务又成了计划，在对计划进行评估和检验之后，每个周期的工作内容就如此确定。

故事的作用就基本到此结束，剩下的内容是当单个故事完成的时候，对版本中功能进行体验，如果通过，则这个故事就此完成，最后进行归档之类的收尾工作。

当然，在故事的具体使用中还有一些细微操作，比如如果一个故事在一个周期中制作时发现比估计的大很多要放到两个周期来做才能完成。那么我们还需要对故事进行拆分之类的操作。这些细微操作还是需要在针对不同的情况进行不同的处理。

版本体验会

当我们一个周期的开发内容完成，每个版本功能都已经在周期内得到了验证，并且已经有了一定的优化。为什么我们还要有一个版本体验会呢？

首先，我们每个人负责的领域不同，我们有的人对于美术质量很关注，有的人对于代码质量很关注，有的人对于设计文档很关注。也许我们中的一些人参与了一些功能的开发，但是我们并不能对于这个周期的所有功能，所有的改动有所了解。就算对此有所了解，我们也许也不明白每一个功能的设计用意。最后，为了让所有人对最终结果达成统一的认识，我们需要一个正式的展示会议，向核心组或者高层进行我们这个阶段的成果展示。在展示我们的版本新增功能和内容的同时，核心组也会对这个版本的各个细节和内容进行考察和审核，确定这样的改变是否符合对于游戏性和乐趣的追求，是否符合我们对我们游戏的希望，这样的发展方向是否是正确的。

而在这样的会议中，最重要的是，我们需要得到来自各个方面的反馈。作为开发者，这可能本身就局限了我们对于我们的版本的认知和看法。我们对于我们的版本过于熟悉，有可能自动的忽略掉了一些很重要的问题，或者会错误的认为一些难以被接受的游戏性具有很大的乐趣。而这样的会议，则是指正我们类似问题的恰当时机。针对这些反馈，我们可以更好的修正我们的工作思路和计划。给予我们下一个阶段更好的目标。

所以，在这里，核心组需要给出的，更多，更重要的，还是对于我们游戏的方向性的，涉及到我们目前开发功能的游戏性和表现上的改进意见或者反馈和一些指导性的意见。因此，我们需要要求我们核心组本身更了解游戏，更明白游戏性，并且自己对于我们要开发什么样的游戏，有清醒的认识和思考。

周期总结会

自适应，自我优化的流程，需要有两个要素才能真正的进行自我改进。首先最重要的是其中的人要有对流程中的问题，需要优化的地方，甚至是对优化本身有清醒的认识和意愿。其次，就是这样的人推动的一个优化行动。而周期总结会，就是SCRUM中设立的一种针对流程自身优化而进行的一种行为。

项目总结是游戏业的一个普遍工作习惯，在每一个游戏项目结束的时候，会进行一次全项目级别的总结会议，对于整个项目过程当中，做的好，有典范价值的事物，或者在过程当中发生的有范例价值的问题，甚至是还没有解决的问题进行系统的总结和提炼。之后将之发表，可以成为团队，甚至其他团队将来工作时的依据和帮助。

而每一个周期一次的周期总结，则是将这一行为加快，频率加高，在项目进行中不断反复。以此达到更快速的寻找总结目前我们的优缺点，针对我们目前的缺点问题寻找解决的办法，并且开始行动。总的来说，就是以更快的频率不只是迭代我们的版本，将我们的版本改进的更好。同时也是迭代我们的行为，优化和让我们自己更加的进步。

其实设立一个这样的会议并不难，每一个周期我们都会有这样的总结会。而会议也总会有这样那样的缺陷和需要优化修改的结果。难的是我们需要切实的推行那些问题的修正措施，难的是我们需要能够直面我们的不足，并且将其提出。我们要能对或许难以开口的问题更直白。鲁迅先生有云，真正的猛士，敢于直面惨淡的死生。我们必须承认我们的工作都是不完善的，都是需要优化的。但是这些问题都不是阻止我们开始修正和改革的借口。敏捷开发的意义也就在于，知道一开始的我们不足以成功，甚至肯定会出现问题，会有失误。但是正是在一次次快速迭代中，我们快速的磨合，快速的修正，最后在一次次的改正与进步中，我们才会得到一个完善的团队，一个良好的流程以及一系列适合我们的方法。

这也才是周期开发的意义所在。所以，敏捷开发，并不是一个需要在一开始就有完全的准备的过程，并不是一个需要完整规划，好好考虑的过程。我们只需要有一定的东西可以开个头，哪怕还不算成熟，但是我们依然可以在接下来的过程中，对我们的目标愈发的清醒，越发的明确，并且我们本身也会越发的成熟，最终共同达到目标。

一开始，游戏功能不明确？没问题，我们可以先从知道一定会做的开始做，然后开始探讨我们最后要做的目标，再根据每一个迭代的版本反馈修正我们的目标。

一开始，我们开发团队磨合不够？没问题，我们可以先让他们从开发简单的底层功能做起，并且同时进行磨合，将磨合过程中需要解决的问题一一提出并改正，最终优化得到一个完善的团队。

一开始，我们的工具不够？没问题，我们可以先用最快的方式开发原型，同时分析原型制作的方式和需求，进行工具制作。并且在工具可以使用之后，再根据使用者的反馈和项目的进展进一步的优化和改进。

... ...

我们可以做的东西很多，而那些还没有做的，也同样不能成为我们开始做的障碍。

原文地址：http://djt.open.qq.com/portal.php?mod=view&aid=115

相关话题：敏捷设计和敏捷开发源地址：http://ucdchina.com/post/11432

敏捷开发思想谈（一）

song — 2012-01-28 13:27:52

敏捷的原则

敏捷开发其实并没有标准型的流程。SCRUM也只是众多衍生体中的一个。实际上就算是SCRUM的实际使用也情况千差万别。所以首先，请大家有这么个概念：
敏捷开发绝对不是一套一成不变的标准化流程。而更多的是一种自适应，自我优化的流程优化理念。

并没有一定的流程，而是需要大家有对任何自己觉得不对的，不正确的，效率低下的事情的警觉性，和将之提出来并进一步改正的行动力。其次，敏捷之于游戏开发，则更要体现人对游戏本身品质的把握，而非对各种文档的审核，这就是和传统软件开发区别最大的地方。所以，没有最好的流程，只要是合适并且能够持续优化的流程就是好的。

所以：

l 不一样的项目经理会有不一样的流程

l 一样的项目经理，不一样的团队，也会有不一样的流程

l 一样的项目经理，一样的团队，每隔一段时间，都还会有不一样的流程。

迭代想与得

为什么我们要迭代？

进行游戏开发，首先请大家对此铭记于心：

l 我们的设计不一定是我们真正想要的

l 文档内容在我们想象中和实际体验版本时的感受不相等

l 我们没法100%的思考到所有需要思考的角落

同样，要理解为什么要使用迭代，我们需要明白迭代开发从何而来。最初，软件开发行业中，一般都由需求方提需求，开发方拿到需求开始分析设计，一次性开发成型交付。随着行业的发展，软件复杂度的增大，需求变化的增加，大家发现一次成型的版本往往无法满足需求方的需要，于是返工。当这样的情况多了之后，返工就成了一种标准化的流程，系统化的返工其实就是我们所谓的迭代了。当然这是一种比较民间的解释，但是在游戏产业中，这也说明了：

l 迭代的目的是为了应付需求的变化。

这里的需求变化需要我们的额外注意：

l 游戏产业中的需求变化，并非只是指策划或需求方在中途站出来说自己的想法有变。更多的时候，是自己在进行游戏开发的过程中，出于对开发的游戏的认知的加深产生的需求设计的变化。一般来说游戏的需求来源于设计，但是我们的设计却往往并不是我们真实的需求。或者说，我们的设计往往不能满足我们真实的需求。

例如，我们需要一个激烈爽快的单体攻击技能，那么我们的设计可能会涉及到，这个技能的功能，伤害，消耗，动画播放等。这个设计还会涉及到表现：比如技能的动作如何，特效如何，播放速度如何，镜头如何。当我们看到这些设计，我们是否就能确定这些设计能够满足我们的需求？进一步，就算我们看到设计之后，认为能够满足了我们的需求了，但是否在游戏版本中我们实际体验的时候，实际效果能100%符合我们的预期？

当我们清醒地认识到：

l 无论我们在设计上花多少时间，我们都无法完全消除设计的实际效果和预期的差距。甚至在超过某种程度之后，我们花在设计上的时间将会形成浪费（这就是所谓的OVER-DESIGN）。

我们就应该开始考虑，什么时候设计应该停止，什么时候我们就应该开始先做，然后预留足够的时间，把那些可能出现的，和必然出现的问题，留给我们后续的迭代来发现和解决。而不是把这些问题试图在一开始全部解决掉，第一，不现实，第二，不科学。

旋转上升

什么是迭代

那么，迭代究竟是什么？

首先要申明一点是，其实我们现在谈论的迭代并不是纯粹的迭代，而是迭代加增量开发。纯粹的迭代是指没有新需求的加入，第一个版本实现的内容就已经完整，之后的版本只是之前内容的优化。而增量，则指下一个版本是在上一个版本基础上增加内容的开发形式。

那么，迭代加增量开发的意思就显而易见了，而我们需要的开发模式就是这种：

l 在不断以版本为基础的增量功能开发的基础上，不断对已经有的功能进行完善和优化。这就是狭义的迭代

进一步来讲，广义的迭代，则不仅限于我们的功能开发。而且还要对于我们本身的流程，工具，工作方式，方法，习惯等等所有可以改变，可以优化的地方进行优化，进行修改。最终的目的就是通过一个个版本迭代开发，不只功能品质在变好，团队效率，团队流程等各个方面都会变得越来越好。最终形成一个真的具有战斗力的团队。

周期总结会议，以及一系列的问题改正，优化提高事项，以及平时提倡的交流，对于变化的拥抱等等，都是为了这个目标而发生的。所以，

l 敏捷开发是一种精神，而不是一种固定的形式。我们需要有一切都是可以改变的心态和准备，并且真的可以着手去改变任何我们觉得有问题的东西，这样才能真正发挥敏捷迭代开发的优势。

陀螺的转动

如何迭代

迭代的漩涡

首先，我们抽象一下，以便大家能简单的明白迭代的形式。迭代就像是一个漩涡，从漩涡中心开始旋转，越转越大。而处于迭代最中心，所有的东西都围绕它来转动的那个核心，就是我们的产品订单（故事清单）。

而那条旋转的线，就是我们的版本。版本永远围绕着我们的故事清单来开发，（故事清单，抽取于我们的游戏的设计），版本总是由故事清单里寻找需要完成的功能，再将根据实际版本得到的反馈，并更新故事清单。于是功能清单的功能越发的有价值，而版本本身也会越来越有价值。

迭代的步骤

那么，我们的版本该如何围绕我们的功能清单来画这个漩涡？

首先，漩涡是一个环绕的圈，所以我们先确定圈的长度：

l 一个迭代的长度

在这段固定长度中，它其实是一条单向封闭线性的线段，有始有终。有始有终的过程才能被量化和计划。在线段开始时我们从产品清单中取得信息，在结尾会释放一个版本并向产品订单反馈信息。

再进一步深入：

在这线段的开头，我们要从产品订单中取得什么？故事。什么样的故事？价值（优先级）总和最大，且大小（故事点）不超过我们一个周期工作量的故事。仅仅如此么？当然不是，首先，有一个重要的概念：

l 系统

也许有几个故事隶属于同一个系统下，它们共同组成了这个系统，它们全部完成，或者至少关键部分完成。这个系统才是完整的。当系统不完整的时候，这些功能的乐趣根本无法体现。

那么，有可能当我们选择这个周期开发某个高价值功能时，没有开发相应的属于一个系统的其他低价值功能。于是周期末的版本我们发现，由于系统的不完整，这个功能乐趣甚微。如果对这种涉及系统的问题没有认识，那么我们很可能就会对这个高价值功能有错误的认识。（关于系统理论的知识，请参见WIKI系统学一词）

如何避免这个问题？这个时候人的作用就体现出来了。当然我们可以在故事列表上增加一列系统属性，提醒我们。但根本的方法还是一个或者多个对整个故事列表有着足够把握能力的人来进行掌控。

我们需要有人能够全面的了解设计意图，并且对我们的故事列表进行把关，对我们周期开始的需求选取进行主导。有一点大家应该明白，规则和标准都是人制定的，那么我们究竟是依靠标准和规则来更好的控制结果，还是依靠人本身？是完善更好的标准，还是培养出更能把握质量的人？

接下来，线段中的开发过程，本质上其实就是分析需求，制定计划，开始开发。或许会周期内分为更细小的周期进行迭代。但是这些小迭代其实依然是瀑布式开发，这点毫无疑问。区别只是在于，这样的小周期内，我们开发的思想和方针是以敏捷开发的思想为指导的，我们更注重版本，更注重交流，更注重结果。而不是预定义式的开发流程（pre-defined)。

在线段的结尾，一个周期结束了，我们需要做两件事情，第一是将我们体验版本之后的反馈，反馈回故事清单中。或许我们体验某个功能之后会觉得加上另一个功能会更好玩，于是我们提升这个功能的优先级。或许我们会觉得这个功能很无聊，于是我们把同类型的功能优先级都降低。再或者我们添加，甚至删除一些全新的故事（不推荐）。

迭代的节奏

在迭代中，我们还需要注意我们迭代的节奏，什么时候该松，什么时候该紧。什么时候我们允许大家的发散和更多的思考。什么时候我们应该专注于我们的目标并且忽略其他的一切以得到我们最终的版本。这些都是有所讲究的。

这节奏包括各个方面。那么究竟这样的节奏应该如何来走呢？

在一个迭代之内，我们的节奏应该是先松后紧。当然不是说迭代开始时我们的效率可以放缓。这里的先松，是指在一开始时我们可以有更多的想法和思路，更多的探讨和研究。本来我们的迭代工作就是从粗到细，从模糊到精确的进行。在迭代中，我们也如此一步步明确我们的工作。

一旦目标明确，那么迭代周期SPRINT的名称的含义就出来了：我们向着我们的目标冲刺而去。到了这个阶段，我们需要收缩我们的讨论和想象，一切以最后的版本和质量为前提。以尽可能快的速度来开发我们的功能，提高我们游戏的质量，得到我们需要的结果。至于具体的迭代方式，各有不同，我的方式大家可以参加之前发出的那个VISIO图表。某些细节接下来还会讲到。

响应式Web设计：50实例例与实践

波希米亚 — 2012-01-20 00:08:42

Responsive Web Design: 50 Examples and Best Practices
Designmodo.com版权所有
作者：Adrian
译者：UCD翻译小组，波希米亚
原文地址：http://designmodo.com/responsive-design-examples/

译者序：当我看到这篇文章的时候，还好发布的时间不算太早，主题很对我的胃口，因为我的Blog已经这么做了。但这篇总结的很全面，提到了一个新的名词“响应式Web设计”，作为Web内容应该去更加灵活的呈现在不同的终端上。这让我想起了之前写的一篇文章《未来我们只需要浏览器》，随着智能手机和各种Pad的发展，内容终端终究会发生改变，Web展现需要去适应这种趋势，并带来优秀的阅读体验。

响应式Web设计是在开发和设计网站过程中产生的一种方式，它的目的是让内容布局能随用户使用显示器的不同而变化。再明确点说，这种设计概念，就是让原本1292像素宽，4栏的内容，能够很好地显示在1025像素宽的用户屏幕上，同时还能自动简化成2栏。当然，让它很好的适应智能手机和其他种类电脑的屏幕也就成了水到渠成的事了。这种特殊的设计形式就被成为“响应式Web设计”。

响应式Web设计与传统的设计方式截然不同，开发人员（特别是新手）必须要理解它的优势和弊端。这篇文章正是为大家揭示一些实例的。（这里介绍一个叫“Media Queries”的网站，里面介绍了更多实例和演示）

数据表格是响应式Web设计的经典使用情景，实现它的想法与传统的设计理念有很大不同。数据表格默认很宽，当你要查看它全貌时，你得缩小表格，但这时字会变的很小，很难去阅读。然而当你想看清楚上面的字时，就不得不再把表格放大，这时要查看完整表格就得横滚加纵滚。这么阅读表格也太KB了。或许重新格式化表格或以饼图形式展现是种解决方案。再不然，你可以弄一个迷你图，即使在窄屏幕里它也能适应。

响应式Web设计中的图像以流式图像为主，可以被上下文感知的图像所替代，这是一种更好的设计方式。这种技术的真正意义在于，能够让图像适应不同的屏幕分辨率，更大的或更小的。所以它与传统设计的理念和技术都有很大不同，合理使用会让你的网页化腐朽为神奇。

响应式Web设计实例

Simon Collison

Andersson-Wise Architects

Stephen Caver

Sparkbox

Food Sense

The Boston Globe

Think Vitamin

Sasquatch! Music Festival

Internet Images

Staffanstorp

Seminal Responsive Web Design Example

Naomi Atkinson

Forefathers Group

Spigot Design

New Adventures In Web Design Conference 2012

Illy Issimo

Arrrrcamp Conference

Robot or Not?

Earth Hour

Clean Air Commute Challenge

Launch Kit

Teixidó

Ribot

Deren Keskin

Sweet Hat Club

Glitch

dConstruct 2011

Adaptive Web Design

Authentic Jobs

Five Simple Steps

Splendid

Ryan O’Rourke

FlexSlider

El Sendero del Cacao

Do Lectures

St Paul’s School

Naomi Atkinson Design

Ben Handzo Photography

Stunning CSS3 Media Queries Example

Nordic Ruby Conference

Halifax Game Jam

ASU Online

3200 Tigres

Pixelab

Kings Hill Cars

8 Faces

Asbury Agile

Alsacréations

Sleepstreet

源地址：http://blog.b3inside.com/design/responsive-design-examples/

【Paul Adams译文】为社交设计

Paul Adams — 2012-01-18 20:56:59

为社交设计

Strong, Weak, and Temporary Ties

by Paul Adams on 2010/04/09

PS：作者Paul Adams Facebook全球品牌体验总监

电话和手机聚集十亿用户用了15年的时间，而Facebook只用了9个月。我们看到越来越多的人开始用在线社交网络，这种网络好像也在成倍地增长。但是事实是，社交网络却没有增加人们交流的次数。我们差不多见过所有我们在社交网络上联系的人们。我们在线下也和这些人联系过。社交网络只是将这种关系可视化了。举个例子，我们经常联系老同学，然后补上几张大字报。但是只要我们联系过我们很少能够继续谈下去，久而久之我们忘记了这些关系的存在。事实上，Facebook的用户通常和他们将近达到50%的关系人没有互动交流。当我们研究人们如何在社交网络上互动交流时，我们发现绝大多数交流只是人们交流中一个非常小的子集。

Facebook上平均好友数量是130，有些人会有很多。尽管有成千上百的朋友，Facebook大部分人只定期联系4-7个人。对于90%的Facebook用户来说，他们20%的好友占据了他们70%的互动交流。在手机使用上我们看出同样的道理。我们的手机联系人里有许许多多的朋友，但是80%的手机呼叫打给了相同的4个人。我们认识几十个用Skype的人，但是80%的Skype通话都是拨给那2个人的。即时我们在线玩游戏，但是主要和线下认识的人一起玩。

我们与一些我们不亲近的人保持着多种多样的交流。我们找新工作，不是通过我们的朋友，而是通过朋友的朋友。当我们的朋友的朋友的朋友减肥，我们也减肥。我们去eBay，从没见过的人那里买成百上千美元的东西，也许之后我们不会再联系。

我们和我们生活中的人有着非常多样化的关系，尽管网络不能很好的支持它。

在Facebook上，所有我的朋友都是同等对待。我被授予了一张很长的按字母表顺序排列的列表。他们中的某些人我能过存放我最深的秘密，也有另一些人我还没见过5次。尽管他们集合在“朋友”的大桶里。在Facebook上和我是“朋友“的人中，有许多我都不会称为“朋友”。我可能叫他们熟人，或者同学，或者家人，但是他们和我的亲密朋友不在同一个类别。

在我的手机里，所有的联系人都是同等对待。我有一张很长的按字母表顺序排列的列表。我最好的朋友和那个我和他5年没有说过话的人占据同样的数字字符像素。我可以通过”收藏夹“找到我最常联系的人，但是这些人和那些我已经失去联系的人是同样的表现形式。在Linkedln上，我所有的联系人都是同等对待。尽管有一些人近年来的每一天我们都一起工作，但也有些人我只在一个会议上见过一次。

我们的设计网络工具必须要认识到这些联系的强度，我们与一些人有着比另外一些人更密切的联系。我们应该适应这些知识。

有三种关系类型：

强关系：人们彼此非常关心

弱关系：人们的联系很稀松，像朋友的朋友

暂时性关系：人们彼此不认识，但临时地联系过

让我们来看看每一种关系类型，想想我们应该如何为它们做设计

大多数人只有不到10个强关系

几十年来，人们都在说社交网络是由强关系和弱关系构成。想想你生活中的人们吧。你最亲密的朋友，在家庭里和你更亲近的人，这些都是你强关系的例子。强关系就是你最关心的人。人们的强关系通常指的是在“信任的圈子”里的人。强关系的人通常对朋友的决定发挥着重要影响。大部分人只有很少的强关系，一般少于10个。一个针对随机挑选的3000个美国人的研究表明一般美国人只有4个亲密的社会关系（4个强关系）。大部分人的强关系介于2到6之间。人们的强关系来源于各种不同的地方。强关系里大约一半可以称之为朋友。剩下的一半包括配偶，合作伙伴，父母，兄弟姐妹，孩子，同事，俱乐部同事，邻居，职业顾问或辅导员。在2002和2007年，一份关于1178位成年人的研究发现，平均每个人有10个在至少每周与他们见过面或者交谈过的人。所以当我们为强关系设计时，我们是在为一小组人做设计。

有些人相信这种情况正在改变，网络让我们与更多人亲近了。相反的是，研究报告显示绝大数量的社交网络使用发生在强关系之间。我们可以轻易的看到，在Facebook上那是4-6个人，在手机呼叫上是4个人，Skype上是2个人。当人们与其他人玩在线电脑游戏时，他们主要和那些他们认识的人交流，一起玩，或是和那些住的离他们很近的人。这种用于强关系交流的技术模式并不是新的。当电话出现时，它极大扩大并促进了强关系，而不是弱化它们。20世纪七十年代的一份研究表明手机呼叫的大部分都是打给住在与呼叫人5英里以内的人。

为强关系设计

想一下现有的交流方式，手机呼叫、文字信息、邮件。我们与强关系的联系因为它们得到了增强。我们应该谢谢它们，不要试图用我们自己的信息系统替代它们。

展示有关10个最亲密人的更多消息可能比显示更多的人的少部分信息有价值的多。

避免如”朋友“等的一般措辞。这很可能导致超出人数的团体，减弱了他们的相关性。

向人们推荐关系，但是要说说明增加关系的影响。

人们日常与大约150个人为弱关系

除了你的强关系，想一下你朋友的朋友。人们彼此不是很认识。他们就是你的弱关系。弱关系是指你认识但关注很少的人。他们和你联系的很少。弱关系指你们困同一个电梯里，你不会感到不舒服，但也不会干到非常亲近的人。

在二十世纪七十年代，社会学家 Marc Granovetter写了一篇关于弱关系的强度的、非常创新的论文。他推断弱关系是比强关系更好的信息来源。因为我们的强关系是一个非常小的圈子，弱关系拥有信息和建议的更强大的资源。研究表明大部分人在现实生活中只能与的150人保持最新的弱关系。这种模式千百年来都是正确的。新石器时代的村庄一旦达到150位居民，就开始分成两个村，这样每个人都认识彼此。现在这也是正确的，不管线上还是线下。我们和150多人都有关，但是我们没有和他们保持联络。我们在Facebook上和成百上千的人有关，但是我们很难说出他们的生活怎么样。

在社交网络上，弱关系有时非常有用，例如在Linkedln上的关系人可能会帮你找到一份新工作，一位朋友的朋友可能就一个专业题目给你一些建议。然而有时社交网络上的弱关系也可能导致一些尴尬的社交局面，举例来说，收到不必要的Facebook的邀请，这些邀请来自你不是很认识的人。

为弱关系设计

在交流和信任之间要考虑权衡。弱关系可能对于我们感兴趣的一些事上更有见识，但是我们可能不怎么相信他们。弱关系对于展现我们的其他共有关系，展现他们知识资源很重要，所以我们提高了对人们（弱关系）的信任。

让人们能够很容易地揭露他们的关系网给他们相信的人。这打开了弱联系之间的连接，同时没有损失用户隐私。

在弱关系之间开通合适的交流通道。这可能会有促进或突出共有的强关系。

网络正在促进我们与暂时性关系的互动交流

当我们谈论线上关系时，强关系和弱关系是不够的。我们需要一类新的关系——暂时性关系。

暂时性关系是存在的，但是网络把他们推向了前面。想想我们只交谈过一次的人。事实上你不认识他们。暂时性关系在线上比线下更常见。他们和你没有公认的关系，只是为了某个特殊原因而暂时性的交流。一旦任务结束，暂时性关系就不会再联系了。除了他们打的字，你并不了解他们，不管他们有什么样的网络资料。由于在线用户产生内容的增长，暂时性关系变得越来越重要。

以下是暂时性关系的4种常见类型：

1.人们有时和暂时性关系交流是由于一种信息需求。人们需要信息时就寻找有跟答案有关知识的人。一旦这种信息需求得到了满足，与他们的交流通常会结束。你可能会在街上问路，或者在网络上用雅虎问答来查找信息。这种暂时性关系类型对网络搜索的发展前程越来越重要。人们留心某些人，不是为了商业利益，只是回答疑问。

2.暂时性联系也存在于当然们需要临时的交流来完成意向工作。一旦任务完成，交流终止。举例来说，在商店里与销售助理交流，或者让一位水管工人到你家修理泄漏的管道。现在许多这种任务都是在网上完成，像和电话代表中心联系，让他们安装电缆装置，或者从eBay的暂时性关系那买东西。

3.暂时性关系也可能是因为一个共有的、正在进行的嗜好而形成，如一个运动团队或者爱好。这种交流互动通常发生在社区网站上，例如某个运动队的论坛。这种关系的真实身份还犹未可知。在这些关系中，经常发帖的人开始认识其他人，了解其他人的行为。尽管他们可能从未见面，他们的关系正从暂时性走向弱关系。有越来越多这样的例子，暂时性关系在网上交流，在线下见面。

4.人们经常和在分享相同地理位置的人形成暂时性关系。这种关系可以像在街上一分钟谈话一样简单，有时像音乐节上间歇3天的谈话一样复杂。现在的技术允许我们和分享过跟我们一样物理位置的暂时性关系交流，尽管他们不是在相同的时间。我们能用手机查看谁之前去过我们正在考虑的旅馆，他们订的什么，还有他们认为它好不好。

因为我们和暂时性关系的人没有关系历史，所以代表性的身份特征和声誉对于成功交流至关重要。我们需要知道eBay卖家是可信的。我们需要知道我们正在读医疗建议来自于一名真正的医生，而不是冒充是医生的人。我们需要知道旅馆评论来自与知道它们食物的人，也需要知道Amazon的评论不是公司雇员写的。

在Yahoo问答上，人们通过不同方法建立他们的声誉（威望）。在图的左边，“Messykat”通过提供问题的最佳答案建立她的声誉。她的意见在20%的例子里都有帮助，但是我们仍然不是很清楚她在三个专业领域（猫，狗，婚礼）里的作为专家的凭据。在图的右侧“RuthAnn”通过说明她已经训练了40多年的狗狗，来建立自己的声誉。这只是表面上增加了可信度，因为我们无法核实那是不是真的。

在eBay(左图），“jmjenkins”通过跟他交易过的暂时性关系人的积极反馈建立信誉。他们中一些人在他的概述里留下了肯定的评论：商品跟描述的一样，安然无恙的收到。谢谢！A++”。

在Amazon（右图）“W.Todd Dominey”因为在711个案例中提供了665条有帮助性的评论，建立了自己的信誉。他还因为用了自己的真实姓名，说了自己来自哪里，获得了信誉。尽管如此，和Yahoo问答的“RuthAnn”一样，我们不清楚“W.Todd Dominey "知道多少他评论的主题。我们无法核实他的可信度。

帮助暂时性关系的大部分人的动机都不是钱。你不能用经济回报创建一个好的暂时性关系群体。Yelp曾经这样做过，一条评论一美元，之后他们尝试支付人们每小时15美元来评论现有的意见，并写一些新的。Yelp最后获得了一些低质量的评论，和许多负面新闻。暂时性关系的真正动机包括成为一个专家的或利他主义的认同感，他们感到自己属于

源地址：http://article.yeeyan.org/view/258129/246735

目标商品辅助搜索——分类检索

江南阴雨 — 2012-01-18 15:46:45

假如你想买一个衬衫，只有一些比较模糊概念，格子或者纯色的都可以、棉的或者涤纶的无所谓、休闲和商务也没什么影响、对品牌什么的也没什么偏好…… 遇到这种情况有一个很好的解决方式——社会化关系网中的好友推荐。可惜这一块还不怎么成熟，靠推荐就甭想了。只好老老实实地去网站上检索，碰到什么是什么，看着顺眼就行。

在进行分类检索的时候，商品的分类筛选要么太细，不选吧，结果商品太多，动则超过100页，看也看不完，何况有些还不是你想要的，选吧，分类太细会漏掉你真正想寻找的商品；要么太粗，选项一选，根本找不到你想要的商品。

分类的作用对于商城系统来说有很多用处，算法推荐、搜索匹配、快速查找等都离不开分类，这里只说用户对于商品分类的使用，用户对商品分类的使用只有一个目的——快速检索到自己喜欢的商品或符合自己心意的商品。那么分类检索就需要明白以下几个方面：

用户购物时会按照哪些条件来进行检索
这些条件中哪些是重要的，哪些是无关紧要的
取出任一条件，这个条件下有哪些分类
这些分类中哪些是重要的，哪些是无关紧要的
分类和条件能否最大限度地将不同属性的商品区分开

我们以男性“衬衫”这一商品为例，假设现在想要找的是：休闲、格子、棉质、长袖、素色一些（纯色、偏暗、黑白）、最好是有口袋。看下京东商城、亚马逊、当当网、淘宝商城在分类的处理和检索商品准确率上分别的表现。

京东关于衬衫的分类

亚马逊关于衬衫分类（放在侧边栏上，为了图片不那么长，在PS里进行了组合）

当当网关于衬衫的分类

淘宝网关于衬衫的分类

共同点都有品牌、风格、材质、尺码、价格等因素，不同点是各个地方都加了属于自己的一些特别的东西，比如当当和季节，亚马逊有折扣，淘宝有工艺设计。再让我们根据之前设定好的条件来分别在这四个网站进行检索，瞧瞧结果会怎么样。

京东点击相关条件后搜索到的商品

亚马逊点击相关条件后搜索到的商品

当当网输入相关条件后搜索的结果

淘宝输入相关条件后的搜索结果

风格方面我希望是休闲类，淘宝网和亚马逊条件可以复选，当当和京东条件不能复选。比如京东的时尚休闲和商务休闲，很难定义的清楚，复选更好，当当干脆风格是成熟、阳光、绅士、街头等让人无所适从，街头就不阳光了？绅士就不能成熟？淘宝的风格也很奇怪，嘻哈、韩版、英伦、欧美风等，让人无法选择。
颜色方面我希望暗一点，但我并没有明确地说是黑还是蓝还是灰，当当和京东没有颜色，淘宝和亚马逊颜色都可复选；
棉质和长袖都有明确的类别，这是商品的基本属性，没什么好说的；
最好是有口袋这个条件，只有淘宝有相关属性；
品牌到底有多重要？无一例外地都把品牌放在第一位，如果品牌重要到是第一条件的话，那其它的条件都是浮云，因为一个品牌的衬衫能有多少，想也想得出来，除非品牌能多选；

商品的多少先不去管它，毕竟大家的商品数不同。京东风格中规中矩，但风格和样式、颜色选择无法满足需求；亚马逊则承袭了最普通的商品属性，让人一目了然；当当和淘宝基本走的是一个路子，事无具细，把不得袖子上有几颗纽扣都要做为条件来进行检索，模棱两可的选项太多，无从下手的地方也太多。他们虽然属于一个路子，但淘宝可以多选，遇到模糊项时大可都勾选上。

从结果表现来看，最差的是京东，后来看了下不进行分类筛选的京东衬衫，有很多都是淘宝和当当搜索出来的风格，京东却用分类过滤掉了这些目标商品；稍好的是淘宝，虽然分类精细，但却能用复选进行弥补，得到一类商品后，可以去条件进行二次搜索；个人觉得最好的是亚马逊，虽然限于他的商品数，结果只有一个，但，一分类清楚、不繁琐；二通用语言、易理解；三各条件顺序合理（我真不觉得在这种状况下品牌是第一要素，品牌是个死的特定项，太容易搜索出结果了）；四价格和折扣相得益彰。

这种按分类进行检索的形式，再结合下搜索框，极易找到目标商品，但往往我们都找不到想找的商品，或者花上很长时间不停地在点下一页。我故意在条件里加了个希望有口袋，但其实口袋的影响有多大还是个问号，说这话的意思是，很细的细节检索上影响购物决策有多大的影响还需要进行数据上的论证，也许淘宝能给个用户常点哪些条件的数据出来看看。明确、准确、简单的分类要经过很长时间的不断调整，最近在这方面也在采集相关数据进行分析，如果你有这方面的数据不妨也分享一下。

综上，好的分类检索应该但不限于包含以下几点：

用数据来衡量哪些条件是你的目标用户群在意的，一定要是你的目标用户，照搬别人的过来会不合适。其它不重的条件或者用到的机率少的条件可以隐藏点击再展开；
条件下的分类一定要让用户看了就明白，分类要能涵盖所有商品，分类不宜过细，否则会把目标商品给过滤掉，同时应该注意分类多选性，特别是在商品数较少的情况下；
分类检索只是商品搜索的一个辅助方式，根据网站实际需要设置出现的频率和位置，辅助的搜索方式如果让它占主导地位恐怕会为选购商品带来不必要的麻烦；

源地址：http://www.thismyway.com/?p=517

Android 4.0设计规范（附全文翻译pdf）

CDCer — 2012-01-18 15:02:01

在拜读和翻译了Android design设计指导后，对比Android 4.0与Android2.3及之前版本的app设计指导，总结了Android 4.0设计的10大改变：

1. 导航栏 (详见模式PATTERNS>导航Navigation)
由之前的物理按键导航（返回、菜单、搜索、主页）变成了嵌入屏幕的虚拟按键（返回、主页、最近任务）。

左侧为早期有4个物理按键的手机，右侧为新版只有3个虚拟按钮的手机

把菜单项和搜索项从导航栏去掉，把之前通过长按主页键才出现的最近任务直接展示在导航栏中。

最近任务的界面
把菜单收起的同时，在软件界面的操作栏上增加了“更多操作”（action overflow），如下图中的黄色圆点所示。

黄色圈部分为“更多操作”（action overflow）的位置和点击后内容的展示方式

2. 操作栏 (详见模式PATTERNS>操作栏Action bar)
操作栏从之前的app图标＋操作，变成如下图所示：
1向上＋2 Spinner＋3 重要操作＋4 更多操作。
其中，向上按钮，点击后是去到当前界面的上一个层级，非第一层级界面有此按钮，第一层级界面则无向上按钮；Spinner 是用于展示内容的下拉菜单，其内容包括视图的快速切换和显示相关内容的完整信息；更多操作（action overflow）是集合操作栏中不常用的和非重要操作的地方。

操作栏可以拆分成下图中的1主操作栏、2顶部栏和3底部栏。如果需要，顶部栏可以承载选项卡tabs，底部栏可以承载主要操作和被收起的更多操作（action overflow）。

在空间足够的横向屏幕展示界面时，被拆分的操作栏，可以灵活合并在一起。如下图中的手机端横竖屏操作栏所示。

3. 多面板布局 (详见模式PATTERNS>多面板布局Multi-pane layouts)
多面板布局更多的是针对平板电脑，把手机端的目录视图和详情视图两个层级的界面，甚至更多的页面，复合展示在同一个界面中，有效地利用平板电脑的屏幕空间，扁平化层级结构，简化导航。这点在iPad上已经运用得相当娴熟了。

4. 选择 (详见模式PATTERNS>选择Selection)
Android4.0中的长按与Android2.3及更早期的版本有很大的不同。早期版本长按操作后，是出现情境菜单的浮出层。在Android4.0中，长按后在操作栏的位置会覆盖一个临时的情境操作栏，不再弹出情境菜单浮出层。在临时情境操作栏的环境下，当前界面的内容项允许被单个处理，也允许被批量处理。

长按Android2.3及更早期系统版本的内容项时，出现情境菜单的浮出层。

长按Android4.0系统版本的内容项时，情境菜单栏覆盖在操作栏上。

在情境菜单环境下，支持批量操作。

5. 返回和向上 (详见模式PATTERNS>返回和向上Navigation with Back and Up)
返回按键用在手机全局的虚拟导航栏中，基于用户最近查看的界面历史，采用时间倒序的方式，连接界面间的关系。向上按钮用在操作栏的左侧，基于层级结构，点击后是去到当前界面的上一个层级，若当前界面已经是最高一级，则没有向上按钮。

黄色部分为点击向上按钮后的页面路径，红色部分为点击返回按钮后的页面路径

6. 主题样式 (详见风格STYLE>主题样式Themes)
推出三套默认主题：Holo浅色主题、Holo深色主题、Holo浅色底+深色操作栏主题。主推app在这三套默认主题的基础上做设计，以加快app研发效率，但只是建议使用，并没有完全强制。视觉设计师们可以重点看下STYLE和BUILDING BLOCKS这两章。

7. Widgets (详见开始吧GET STARTED>UI概览UI Overview)
在原apps页里，用选项卡tabs的方式增加了widgets内容。一改用隐晦方式添加widget的操作和把widgets零散放在桌面呈现的方式。在app设计中，应该提高对widget设计的重视程度。

8. 兼容性 (详见模式PATTERNS>兼容性Compatibility)
向后兼容，考虑到物理导航按键手机如何兼容Android 4.0系统和虚拟导航手机如何兼容Android2.3和更早期版本的apps。

在物理导航按键手机上安装android4.0系统，点击物理按键，在屏幕下方出现action overflow的内容。

在新的虚拟导航手机上安装为android2.3及更早版本系统设计的app，会在屏幕下方的虚拟导航的右侧出现action overflow按钮（如上图的黄色部分）。

在新的虚拟导航手机上安装android4.0，点击action overflow后的展示状态如上图。

9. 强调纯粹的Android应用设计 (详见模式PATTERNS>纯粹的Android)
在Android4.0 app设计准则中，特别强调为Android设计纯粹的Android app，切勿使用其他平台特定元素的注意事项，有以下5个方面：
（1）强调视觉元素的样式要符合android系统；
（2）不用其它平台特有的图标；
（3）不在界面的下方使用选项卡tabs；
（4）区分向上和返回，不在操作栏上使用返回样式的按钮；
（5）不在内容列表里使用向右箭头。

Android系统里，选项卡（tabs）会固定放在屏幕上方，不会放在下方。这点与ios系统不同。

10. 其它细节
增加许多新的交互细节、信息展示和视觉样式等规范，详细见翻译。其中，有几点在此强调下：
（1）新增了横滑移除内容的交互手势。在部分模块中，支持向左或向右横滑移除内容的操作，如最近任务和消息通知抽屉。

（2）视觉的平面化，栅格风正在4.0中上演。
（3）在writing style中明确指出写wording时，要直接使用第二人称“你”。

原文见http://developer.android.com/design/index.html
快速查阅，Android Design全文翻译下载地址：http://cdc.tencent.com/?download=Android-Design-4.0

Android Design全文翻译由CDC D3多媒体小组（江宁、张云）出品。
感谢您的阅读！

(本文出自腾讯CDC博客: http://cdc.tencent.com/?p=5082)

相关话题：android设计原则源地址：http://cdc.tencent.com/?p=5082

Windows Phone app的设计过程

小气的神 — 2012-01-18 15:00:32

原文http://ux.artu.tv/?p=192
译文http://www.mdong.org/?p=2232

译者注：
原文的作者为Windows Phone Design Studio的设计师，虽然话语啰嗦，但是能够感受到许多Windows Phone设计完善过程中的细节。重要的一释疑是业内对Windows Phone开发环境封闭的以讹传讹，至少从app设计角度，Windows Phone的心态是开放的。并致力于提升产品创造的团队效率。思维方式不限于Windows Phone，同样适用于其它平台的产品参与者。

–

这里有一个我在使用的Windows Phone app的设计过程。其中许多设计过程阶段是传统的，我尝试从Windows Phone app特别的视角来阐释。

这篇文章是关于end-to-end的过程，所以会保持其高视角，并在下面的文章里详细的探索每一个步骤。比如，下周我们会从理念与概念开始，关于讲故事（storytelling）、草图（Sketching）、故事板（storyboard）与低保真原型(low fidelity prototype)。这篇文章会是系列内容的轴线。但是并不确定会不会基于反馈重新定义（refine）某些阶段，以及增加更多的示例。

图表自下向上读……

Windows Phone设计过程与其它的网站、移动app或任何设计没有本质不同。所有的设计师重视设计过程，用他们自有的方式调整、完善设计，并改变适用于每一个项目。没有项目是相同的，因此非常重要的是以指南（guidelines）理解设计过程而不是规则（rules）。保持灵活性（flexible）。

理解“设计”，设计不是按快门（one-shot）这类活动。你不能凭借一次尝试既确定设计，而是像创作雕塑作品，有一个迭代过程。艺术家拿到一组大理石，他们不会从细节开始，如眉毛、指甲或者头发。而是第一步先塑造整体的感觉，主要的体感与大块。接着第二步定义更多的特性区块，如手臂、胸、头与腿。随后有第三步、第四部与第五步。达到刻画小细节的程度需要经过许多步骤。用户体验设计同理。你不能从细节开始，最终会让你自食其果。应用程序流程（Application Flow）需要在视觉设计（Visual Design）前定义。我看到过许多类似事情的发生，他们尝试跳过一些步骤走捷径，而缺乏设计探索（design exploration）最终得到的是随后项目中的暴怒。

应用主题（App Theme）

我们从应用主题开始。这个是第一个可能产生分歧的点。我只是知道应用主题对于创建接下来的阶段非常重要。我注意到当开始app设计过程我们通常有两个选择。1，已经有一个我们想做的、非常清晰的idea；2，我们有一个目标，基于现有的API与Web Service。但两个途径在我看来都是错的。如果你有一个清晰的idea，你知道你决定了自己与团队的解决方案，但还没有通过探索验证。如果你决定创建一个app基于现有的API或者Web Service，你会最变成另外一个Twitter、Yelp！或者Foursquare 客户端或者另一个从Yahoo获取数据的股票软件！金融或者另外一个从CNN获得内的RSS聚合器……从Marketplace上搜索CNN你就知道我正在说什么。即使这些app有好的体验。相信我，他们无法突围或者为用户做出贡献。不要想APIs或者RSS Feeds。想想用户体验。所以替代的思路是”哇哦……CNN的RSS Feed是可用利用的“ ”我们如何为用户在获得最新与关联且重要的新闻的体验做出贡献？”尽快思考这些，越早为自己与团队打开一个新世界的探索。不再是RSS阅读器，现在你有一个更高的目标，史诗般的任务来帮助用户获得更多关联且重要的新闻。因为对象是宽广的，解决方案是不具体的，这才是想要的点。你保持开放，所以你会探索并拥有革新的idea。替代基于APIs的思考，而基于体验思考，如跑步体验、进餐体验、航行体验，询问自己与团队，你如何为你的用户做出贡献提升体验。注意这并不是必要地意味着解决全部的体验……它意味着只是解决X或Y部分的体验，用户趋向难以发现的地方或者你看到一个机会可以帮助用户发挥全部潜能。在随后的开发过程中，你会选择你会选择API或RSS Feed从任何源，但是起点一定不是技术解决方案。最流行的Twitter或Foursquare客户端都是成功的因为它们将体验放在第一位——而不是API。

现在如果你已经有客户端的app服务于特定的产品服务，或你正在移植iPhone或Android app到Windows Phone，请做好准备，针对主题进行重新定义（refine）。在许多的情况下，受制于预算或委托人，你需要直接跳到信息架构（Information architecture）阶段。然而真诚地说，即便由委托人雇佣你移植一个iPhone/Android app到Windows Phone，请依然做好主题、理念与信息架构的重定义准备。事实上这不是一个坏消息，一旦你进入了信息架构与交互设计（Interation Design）阶段，会得到最好的Metro设计语言：Pivots、Panoramas、App Bar、List View、Typography、布局与动画。当从其它平台移植app，你的工作会变成：1，理解这些平台上的当前信息架构，并用Metro翻译它们到正确的屏幕、内容视图与导航。基本的事情是理解当从iPhone与Android迁移时，你不能迁移UI。你迁移的信息架构。通过思考与实践，你会预防错误的转化过程……如当人们尝试从iPhone迁移返回按钮（通常是屏幕左上角的按钮）到Windows Phone……你在Windows Phone上不需要一个屏幕上的返回按钮，因为我们有一个硬件的返回按钮。所以，遵循思考“迁移IA”比“迁移UI”要更合适。

理念与概念（Ideation & Concept）

现在你有一个主题或者任务，到了为其产生idea的时间~理念与概念阶段非常有趣！——就像是在玩游戏。头脑风暴（Brain storming）的游戏，草图游戏讲与讲故事的游戏。在这个部分有三个关键阶段：1，头脑风暴；2，探索；3，合并（Consolidation）。概况来说，在头脑风暴阶段你产生了大量的idea，在探索阶段你详细分析与研究许多idea（但不是全部），在合并阶段你决定哪些idea会继续向前变成app一部分。只有少数的idea会存活。

完全自由的头脑风暴

这个阶段的目标是产生关联任务的大量idea，如“贡献酒店预订的体验”。想象力（Imagination）、妄想（delusion）与古怪（craziness）是在这个点上都是好的技巧。让自己有玩的心态，思路跳出思维框架。有需多具体的头脑风暴练习如Subject+Verbs+Objects与扩展思路的Alternate Worlds、Impossible Scenarios与In Other‘s Shoes。我们会在下一篇文章讨论所提到的技术。这些游戏你可以与团队一起参与，如果你是独立开发者你可以跟朋友一起参与。这个阶段的目标不是强迫你疑虑“你如何build或编写这个或那个”。也不是关于这些东东长什么样。它是关于产生idea的。在接下来的几个阶段，这些idea会落地执行。后面，就像我们知道的，有百万个非常好的idea，但是只有一个或者两个会被恰当执行，并且成功。

探索分析/审查/测试（Exploration Dissect/Inspect/Test Ideas）

在探索阶段你会得到头脑风暴中脱颖而出的idea，并需要了解更多关于这些idea的内容。你可以通过分析、审查与测试来达到目的。这个点idea刚刚出生，它们就是孩子，没有完全的发展或成熟。然而这些idea只是头脑风暴的一部分，也许许多疯狂的idea在头脑风暴过程中已经灭了——但是有一些依然存在。你可以肯定会发现你或团队中其它人会坚信、接受并深深爱上这些idea——他们的孩子。我冒险地说这不是好事情，但同时，你需要爱上已经确定的idea，这样你就可以把其它idea推得远远儿的。有些时候idea需要发展来完全的证明。如果你太快地放弃了一个idea，也许你会失去一个好的机会。幸运的是这个阶段我们有4个非常有用的工具，允许我们探索我们的idea并发现优秀的种子：草图、故事板、简易原型与讲故事。这些工具帮助开发人员与设计人员针对idea进行测试。

拥有草图能力可以帮助你维持更多的抽象概念。故事板可以帮助你像接近皮克斯或梦工厂动画师一样讲故事。你使用手绘与故事板展现idea的用户体验情景，如何通过app来提供帮助与做出贡献。这是一个可视化的方式。原型是一个全新世界可以探索，当前重心在简易原型。这里有几种方式：一个是通过纸张、便条、卡片与胶带建立模拟原型。你可以通过手动粘贴到画布上测试情景（scenarios）来传达交互。这类简易模型需要一个向导与测试用户。这听起来像是落伍的活动。但是它真的不是……它是非常严肃的。你会惊讶，你能在一张简易原型上用15~60分钟而不需要花一分钱，就可以收到许多反馈。在进一级的设计过程阶段不会使用简易原型，但在这个点，这是最佳选择。另外一个做简易原型的方式是使用Expression Blend（或者是Powerpoint或者其它的交互工具）。这个是Design Studio的Jared Potter第一次向我展示的复合数模技术。简单的说，你在纸上画草图、拍照、载入图像到Expression Blend，在头部的可点击区域增加透明按钮并关联导航栏。Done！他称这个是15分钟简易原型技术，我们会在下一篇文章中讲得更多。

整合产生决策（Consolidation Make Decisions）
从头脑风暴开始得到许多idea，经历自己与团队的探索……在这里需要整合，非常好的idea会脱颖而出。这是一个决定哪一个idea会进入app的过程。有不同的练习会帮助你的团队缩减列表与基于优先级排序列表。这里的目标是移除尽可能多的不明确信息。这时，idea比起概念阶段进一步进化，并引发更多的用户情景（user scenarios）或者信息情景（information scenarios）。你需要带到下一个阶段的是一个基于优先级的情景列表。

信息架构（Information Architecture）

信息架构阶段的目标是定义信息、任务与彼此之间的关系。用户所拥有的数字体验：信息与信息利用的潜力——使用信息来帮助决策、获得关于某些事情的知识、产生信息。

信息架构是一个完整的学科。信息架构的目标是制定信息规则。

在理念与概念阶段产生的用户情景包括不定型的信息，如名字、日期、价格、图像、温度范围-在信息架构阶段你会带着不定型的信息并传递为结构化的信息。一次尝试是不可能完成的，它需要经历多个过程。

我们有两个非常有用的工具可以帮助我们定义信息框架：应用程序流程表单（Application Flow charts）与低保真原型（Low Fidelity Prototyping）。

所以在信息架构进行第一次尝试，并通过创建Flow charts进行测试。这里有不同成熟度等级，主要是从任务流程到具体屏幕+内容视图+导航表单。记得经典软件工程的Flow charts吗？这就是app flow charts，它只是一个可视化术语，我们专注在用户流程（user flow）、体验（experience）与交互设计（Interaction design）。一旦你拿到一个flow chart，你就可以尝试讲述用户情景（user scenarios）的故事。你会获得反馈与idea，用来重定义信息架构，并返回完善AI文档。这时你可以反复通过创建较高仿真的flow chart进行测试。flow charts渐渐地变得详细，从简单的任务flow到屏幕展示内容视图、导航。我不称之为高端的flow charts线框图（wireframes），确切的说是低保真框架。

另外一个工具是低保真原型（low fidelity prototypes）。在这个点纸质原型依然有用，因为低成本。无论如何，flow charts会渐渐地更高保真。你需要打印这些app flow chart并把类似的放在一起（不再是草稿、而是打印材料）或使用Jared在Expression Blend的原型技术，用拍摄的原型图像替代，把app flow程序呈现在屏幕上。

在最后你会有一个独立的IA文档，包括组织化的信息、可靠的成组flow charts与基于app flow的低保真原型。

我注意到的一件事情是，创建Windows Phone Design Process chart后，它在IA文档接近35%的高度，占有同样高度的是Interaction Design（下一阶段）。这些chart不代表在项目中占有同样的时间，但是我要说它着实正确的思考了IA应有的时间。如果你明确IA，会更加游刃有余。

最近的几个星期，我们有一篇特别的文章会关于Windows Phone apps的信息框架。

交互设计（Interaction Design）

我们已经定义了信息架构，也就是说目标用户可以使用这些信息。现在我们开始针对性制作用户界面。

交互设计是什么：创建一组用户界面与用户体验元素，用来验证良好的信息架构与用户完成信息关联的任务。我们希望在这个阶段达到的效果是传递信息与任务最大化的潜力发生。即使IA可能是刚刚完善，如果交互设计不能完全执行，这时信息中发生的事情就不会完全正确地在app中体现、用户也不能完成他们想要的任务。

依照我的观点，交互设计默认是信息与任务的过滤器（filter）。它定义的不是信息也不是任务，而是一个工具。交互设计（或用户界面）是在用户与信息之间的中间人。用其它的方式描述，用户界面（交互设计的最终形式）应该是从有罪直到证明无罪，我想这个概念关联了许多Metro法则要点：信息是展示的核心，不是用户界面。它是决定一个好（坏）设计定义的重要因素，无关用户界面层是薄、无形或者笨重。我们不谈论视觉设计，只是交互设计：用户基于现在发生的关系如何面对信息与任务交互。

如果我们没有一个Windows Phone Metro设计语言可用，这时我们需要从零开始弄明白交互隐喻。在未来的文章里我会谈论如何推动Metro，并给出一些idea与如何基于Metro革新，这篇文章里会重点定义交互设计与开箱即用（out-of-box）的Windows Phone Metro设计语言。

设计模式（Design Patterns），可靠的帮助翻译信息架构到Metro控件。信息架构与任务会赋予Pivots、Pages与Panoramas以生命。信息层与架构会赋予内容视图（Content Views）以生命。信息与信息、任务与任务、信息与任务的关系会赋予导航栏（Navigation）以生命。IA文档的所有内容会翻译到明确的Windows Phone控件中。最后不会出现歧义。

让我们回顾，基于IA文档，选择Windows Phone已有的设计模式，例如：search、maps、email、playlists或people hub的Contact cards。这时，如你没有找到一个完整的设计模式，或者根本不能满足你的IA需求。那么你可以定制一个接近或者创建全新的设计模式。当定制或创建自有设计模式，你有三个好的工具：1，Windows Phone设计网格；2，不同尺寸标准的Typography来传达结构化信息；3，Metro控件。当然，这三个不是所有你可以可用的武器，但它们是最基本的。相信Windows Phone用户体验指导（UX Guidelines）会cover到你的安排。

我提议通过设计模式来设计Windows Phone app。这不是唯一的设计Windows Phone Metro app的方式。像我们前面提到的，我们会在随后的文章里谈论关于推动Metro的设计模式，但在这篇文章重心在Windows Phone Metro语言设计。如果我们明确，从我的观点，我们可以创建自有的设计模式，可能一点都不像Metro控件库只是隐喻接近（但仍然基于Metro设计法则）。

你可以在Photoshop format（ListView_PSD.psd）找到许多列表视图设计模式，全景板图（Panorama_PSD.psd）以及其它控件。我们会延伸更多的内容。

经过选择设计模式，定制并创建设计模式，你基本上设计了app。听起来很简单！其实不是，事实上只是选择了正确的设计模式，定制了它们的工作区块。我发现Windows Phone设计工作室投入了超过2年加工与展开Windows Phone体验与UI。设计模式是非常灵活与广泛的。经过在Windows Phone Design Day回顾将近200个app，我相信它们当中90%使用已有的设计模式与定制设计模式。当我开始我在设计工作室的工作，我对Metro并不熟悉，我的印象是它很漂亮但所有app都看起来很像。现在我在这里写给你的是关于再利用（re-using）已有的设计模式设计整个app做出改变？是的！我印象里6个月前，在Windows Phone中所有的都是Pivot与Panorama时代。但是我发现经过6个月，许多Windows Phone app比仅使用一个Pivot或Panorama更丰富。所有的事情是相通的。这三种类型的屏幕依次主导了app中无限量布局的可能性。这是app之间区别的地方。定制Panorama面板的可能性、Pivot页面的无限量。Windows Phone app使用的Metro设计语言可以非常丰富与独特。像“如果背景不是黑色就不是Metro”的迷信不是真的。请查看Mike K的这篇文章或者Core77的Windows Phone设计辩论。

其中一件重要的事情是以不同的格式生产大量设计模式：Photoshop、Illustrator、Expression Design与XAML。现在，市面上没有大量的设计模式，所以推荐使用手机当前的内置，同时我们这边也在大量工作更多的格式将会投入使用。

返回开始，设计模式的选择、定制与创造阶段会呈现在线框图（Wireframes）。线框图是灰度图。不是色彩的！没有品牌……也没有panorama背景！这些线框图理想情况下是由Expression Design、Visio、Photoshop与Illustrator创建（提醒我们应该提供Visio格式的设计模式）。

我们已经准备转移到下一个交互设计阶段：定义动画风格与UI控件规格。实际上，这些概念会跟随之前选择的设计模式。最后，设计模式在这个语境（context）是交互设计模式，而不只是视觉设计模式。

动画风格会帮助我们基于线框图指明，会有动画出现在从A到B屏幕的转化过程（旋转风格），何时显示列表项目的详细内容（飞出飞入Continuum）。动画是Windows Phone app的重要部分，所以我们设计使用的动画风格的要点规格时会非常挑剔。与此同时，UI控件规格同样需要基于线框图，所以开发人员知道当创建一个app时，键盘类型需要基于输入的用户体验。或者当有通知（notifications），我们需要显示内容A、B、C通知消息内容的规则，通知在哪里会带你进入app。对于Loaders会发生同样的事情……我们需要一个%的loader还是一个等待光标？

在这个阶段的最后，针对完整的app，会有可靠的一组线框图，由开箱即用的定制与自主创建的设计模式驱动。这些线框图会包括动画风格与UI控件规格。准备下一阶段：视觉设计！

视觉设计（Visual Design）

目前为止，你会想：什么，到最后才有视觉设计？！。像我之前提到的，设计过程（任何事物）不是线性的。要是像我一样，我会开启Expression Design（你可能会使用Photoshop或Illustrator）我会把额外的事情丢一边并开始工作，我喜欢这样，用我喜欢的工具并开始app设计。没有草稿、没有线框图，只是漂亮或纯粹的视觉震撼！——许多视觉设计师想的就是这个味儿（就像工程师直接跳到Visual Studio开始敲代码！）

我必须承认比起一个交互设计师我更是一个视觉设计师。我肯定会依靠它看起来如何引导自己，所以我在项目的初期被视觉设计所吸引，但是我必须控制自己并记住有一个设计过程如何我跳过了，我的设计最终会非常漂亮但是不能忠实地表现app如何工作的信息架构与交换设计需求。也就是说，我们知道看起来受欢迎与我们都做过在过程的早期被客户询问发送给他们app的设计。明确开始的视觉设计是徒劳无功（虽然有些客户喜欢说要的就是这个）但是更像是“售卖设计”。

尽管我们喜欢信息架构与交互设计，为用户、商业决策制定者或市场管理者，然而一图胜于千张AI（an image is worth a 1000 pages of IA）。一组漂亮的Windows Phone app会帮助人们购买这个app与产生更多购买，给团队boss的进度报告会看起来漂亮。其实就是这样。所以当IA没有完全确定或交互设计被定义时，视觉设计引导人们在项目早期，最好的想象并最终实现。许多次人们会想这个愿景是最终的产品。但事实不是，这只是试图展示了我们方向在哪里。问题既是团队或客户信奉这个早期的视觉设计做为方向。期望应该被规定，这样在随后项目中就不会失望，因为它后于IA与交互设计，你可以完全的认识到视觉设计。

所以，现在我们有IA与交互设计明确时间来做许多有趣的视觉设计活动，像定义调色板（color palette），设计自定义图标、背景、整合品牌到我们的体验与设计live tiles。

你是否知道有一个有关设计的经典对话关于是否开发人员应该做设计？自始至终，对于这点我认为一个开发人员即使没有正式在设计方面训练可以成功的做到。信息架构是一个系统化与结构、逻辑驱动的学科。我个人认为开发人员有正确的思维模式明确IA。交互设计需要更多的体验，这是交互设计在过程中擅长的地方，但是一个开发人员沿着设计模式，我想他肯定可以做正确。这个阶段的挑战在于当前的设计模式缺乏与恰当的工具来实现方法、挑战，这增加对没有正式设计训练的人们的困难程度。最后，视觉设计阶段，我想你最好雇佣训练有素的图形视觉设计师。虽然有相当数量的设计教程与有版权的图标、图像与其它元素，但它与雇佣一个训练有素的设计师绝不一样。我希望我们可以在后面的文章，提供给开发人员许多实用的技巧，将基于素材的视觉设计元素变得更好。

Redlines and Greenlines

什么是Redlines？什么又是greenlines？！简单的问题。他们是交互体验的蓝图。就像是建筑的蓝图，你可以在上面看到楼梯平面图、侧视图、建筑正面，通过标注尺寸，门有多大、窗户有多大、墙的厚度、水管通道经过的地方、电源出口坐标、楼梯有多高、楼梯采用的材质、涂料颜色等等……在交互设计我们同样有我们的蓝图称作红线。我不确定为什么它们是红色而不是品红……但是我们想是因为红色是经常看到的颜色，容易跳出来，所以UI标识尺寸容易读。屏幕上的redlines显示了一个app不同屏幕，顶部不同成串的测量。这些数字定义了外边距（margin）、内边距（padding）、元素的大小与短暂元素如状态栏。为什么我们需要redlines？我通过Expression Blend就可以解决问题！

很久前在设计过程中我们没有Expression Blend。我知道这会引发一个很长的讨论，所以我在个系列保留了对这个设计工具的细节。我会说不管怎样，对于设计师控制UI到不论谁拿到XAML格式的UI，redlines都是最好的表现技巧。这个人可能叫做整合者，另外一个用XAML或Blend的设计师或开发人员。不论是什么情况，拿到设计与设计app的人不是同一个人。团队仍然可以工作。所以这个人需要一个方式用XAML产生UI与redlines帮助实现。通过redlines就没有歧义，但是如果这个按钮是30×150像素，距离屏幕左边24像素，距离顶部427像素，这时这些尺寸就是位置。不需要讨论。在过去，没有redlines，设计师会设计网站并转换JPG素材（不要使用JPG、只用PNG、没有压缩）给其他人产生HTML与CSS。这个过程会破坏设计，结果会与最初想象不同。Redlines表现了“契约”，一个当事人双方都同意写好的文档！我们会在未来的文章讨论更多的redlines与如何创建。

Greenlines是什么？Windows Phone设计工作室定义为触摸区域。需要按钮会说，10像素的直径，但是它们的点击区域会是20像素（便于用户点击）。Greenlines指明这些点击区域，不论它们匹配的物体大小。Greenlines与Redlines传递不同的信息。

最后（The End）

这个是一个高视角的流程总览，在下面的一周，我们会从细节开始。

下一篇：理念与概念 ideation&Concept

讨论头脑风暴（brainstorming）方法，草图（sketching）、简易原型（paper prototyping）与讲故事（storytelling）。

相关话题：WP7的设计研究源地址：http://mdchina.org/?p=602

阿里巴巴中国站手机客户端项目总结

liuchenhuan — 2012-01-18 14:59:41

从无到有的阿里巴巴无线端设计，经历了由前期的产品定位、产品形态探索、无线需求场景脑暴、产品拆解、分合的产品思路讨论、版本规划到手机行为、手机平台特性分析乃至信息架构的确定、细节的推敲…

无线端敏捷开发节奏快，如何低成本、有条不紊的迭代更新，版本规划以及产品的拓展性考虑尤为关键。九宫格聚合的工具平台形态和运营形态在我们客户端的定位中必然共存，但一期内容不足功能较少，过渡期既要保证目前版本的充实和架构合理，又要考虑用户习惯的延续和activity等的代码模块可复用。

在已有13年历史的网站（培养了稳定的用户群以及培养了一定的用户习惯）基础上，实际上我们并非从零开始。B2B的业务属性决定了无线场景的设计与网站的关联性，而用户使用时必然伴随部分网站习惯的迁移，因此在基于无线场景和手机端特性设计的同时，我们也同时考虑用户在网站端的认知映射。

作为项目owner，跟进后续流程的过程中有几点经验值得highlight：

1. 关于视觉适配难

相比于iOS平台, android硬件厂商众多，屏幕分辨率五花八门，且dpi不同，我们这样做：
(1) 进行目标用户群使用手机比例调研(可通过问卷投放等方式)，选取一个主流分辨率和目标机(本项目中目标机为htc G7，分辨率480*800) ；
(2) 视觉设计过程中，实时在目标机并定期在其他分辨率手机上查看实际效果，并调整方案；
(3) 规范点九图(九宫格)的切片尤为重要。.9.png不但能最大程度低成本、高还原度的适配到android的各个屏幕，更是设计师和开发同学之间的沟通工具，避免在视觉－前端这一环节的设计走样。

2. 关于视觉切片资源文件大

由于功能模块相对独立的迭代开发，造成不同开发同学对于切片管理不统一，以至app文件大且运行过程中占用内存大，操作流畅度不佳的情况。在UI Check过程中，优化切片资源包，替换掉不规则渐变和纹理，尽可能复用样式，统一.9.png格式。

3. 关于UI Check

UI Check的目标不但是保证UI在开发环节的设计还原度，更是对设计方案的重要review。尤其手机操作流程性强，过程更为动态，转场动画、hover效果、gesture这些内容都需要高保真demo在真实的测试下确认调整和再优化。

最后，产品更新和体验优化是一个永无止境的过程。之后我们除了拓展更多无线平台(windows phone/iPad/…)以及新产品新功能追加，也会根据埋点数据和一手用研不断在迭代过程中同步优化体验设计。敬请期待！

下面为项目总结ppt中的部分内容，方便大家有个更加直观的了解：

感谢各位看官的时间，欢迎亲们更多的专业交流~~

如何做首页改版（阿里巴巴中国站首页改版经验谈）

robert.think — 2012-01-18 14:58:38

同任何网站一样，阿里巴巴首页的每次改版也都是一次纠结和挣扎的洗礼。设计的过程总是痛苦的，因为判断和选择总是艰难的，这里我们并不想叙述改版的整个流程——尽管不同团队的架构和设计团队的职责有所差异，但除了决策过程不同外，大公司抑或小公司在流程上并无本质区别。我们在此是想通过总结我们在改版过程中经验和教训，以及对于首页甚或产品redesign的思考。

以下是我们觉得必要的思考流程以及一些方法和关键点：

一、关于定位的思考

在首页改版之前，结合网站整体的策略变化我们首先思考以下三个问题：

1、改版的目的/目标是什么？

是配合网站整体战略的调整，还是用户体验的改善和提升，是自上而下的网站转型升级，还是自下而上的流量再分配？…
这些因素也决定了首页的设计思路是宏观还是微观，是信息层面的梳理还是视觉表达的优化。

2、首页的用户是谁？

用户是谁，用户特征是什么，用户的需求和价值在哪里？
考虑这个问题时，需要对于用户类型做相应的区分，不同的网站可能根据网站服务的特征来区分不同的用户群，比如：

时间：新用户与老用户
来源：自有用户、SEO用户、BD用户
关注行业：原材料用户、工业品用户、…
……

3、现状

目前的内容运营规则是怎样的
当前的界面是否存在可用性或易用性的问题
基本数据是怎样的：PV、UV、回访率、流量转化率，各产品的流量分布、各类型用户的访问基础数据是怎样的。这些数据本身是否能暴露当前的问题，或者能用以评估预期目标的效果

二、做好设计管理

1、找准关键角色

在这个过程中能否找准关键角色非常重要：谁是真正对首页负责的人，谁是对具体业务负责的人，相关的合作方的决策者是谁？只有明确关键角色，问题才能高效的决策和推进，而不是互相推诿和拖延，这将是考验改版项目团队工作技巧的重要一步。

2、提早沟通设计思路，而不是直接进入设计

不同工作风格会产生不同的工作流程，以首页改版为例，我曾经见过给出十多个首页设计稿给老大选择的壮观场面，这未必是不好的工作方法，但却显然是低效的。

建议在改版之前，能够和相关方（尤其是对于首页有决策权的leader）建立起充分沟通，将改版的整体目标建立共识，而不要一开始就沟通具体的设计细节——这很容易就陷入对于细节的争议当中。

当然为了避免“空谈”，做好相应的准备还是必要的，有可能的话提供数据依据和现状分析，并给出鲜明的观点。当然您也可以通过低保真的页面结构图，以便各方对于首页有概念上的理解。

3、项目管理

a) 资源保障

首页改版对于投入精力的需求长期而稳定，能否争取到相关资源，并且在项目过程中获得高优先级的支持将非常重要。

b) 时间计划：定期与追踪

首页改版是一个耗费较多资源，牵涉业务众多的项目，强烈建议按照项目流程来执行，但与一般项目不同的是首页改版的进度往往并不完全受控，相关影响因素较多，并不完全能由技术评估方案的工作量，因此建议在项目前期编制较为粗线条的项目时间表，主要用以对执行过程进行分解，而在方案基本成型后再建立精确的上线时间计划。

三、把握设计细节

1、设计即运营: 设计的过程也是运营策划的过程，尤其是以运营为主的首页，设计师不仅要关注用户如何浏览和阅读，也需要考虑首页内容如何产生，因此首页的设计过程也是和相关业务方订立运营规则和运营方式的过程。
2、追求细节，但别害怕不完美: 就像产品设计中常说的，产品的成功往往是通过快速迭代而造就的，如果追求完美的产品，则时机早已错过。首页的设计和改进也会是一个不断经受用户检验和快速迭代的过程。因此在设计上线先后不断通过用户的反馈和行为数据验证和确认，而无需去追求完美的方案——因为完美是不会存在的。

四、善用数据与用户

1、数据是了解用户的重要途径

a) 在设计前要对要验证的目标设定可衡量的指标

首页改版效果的指标与首页的定位关系密切，如何设置用户体验指标，建议参考Google的用户体验衡量指标体系(HEART)。

b) 是否有足够的数据来支持分析结论

一旦明确首页改版效果的指标，就要通过各种方式来收集指标的相应的数据，网站的基础访问数据、tracelog、点击分布等。如有必要应当对当前首页的数据指标进行收集，以便用以对首页改版后的效果进行对照。

我们的经验：我们在首页改版时主要采用的是（结合采购商身份的）页面CTR和Bounce Rate，以此来评估新老版本与用户需求的匹配度和吸引力。当然在不同的目标驱动下可能会采用完全不同的数据指标，比如在分析局部板块时可能会关注诸如广告效果、专场转化率、登录行为数等。

2、用数据来做决策和验证

a) 关键指标的定义及描述应该达成一致

在我们改版的过程中遇到一系列数据上问题，包括监测数据的不稳定、数据前后矛盾等，而在总结原因时发现问题出于不同的部门对于数据的定义和观测都有所差异，并且在AB Test过程中由于选取的样本数量和类型上的差异，也会使得观测的结果不具可比性。这也促使我们在后续的测试过程中建立统一的数据收集通道，并且在后续的AB Test中和BI部门进行充分的沟通来确保测试样本的可比性。

b) 不要迷信数据，要寻找数据背后的意义

3、意见反馈，有时候并不重要

这取决于你是否有足够的判断力和敢于say no。请考虑接收到的问题——

表达的是感受，还是使用的实际问题
是否是目标用户的问题
是普遍性的问题，还是个体问题
……

在从而做出自己的判断，要记得一点——聆听少数人的声音，但为大多数人设计。

五、“习惯”与重建习惯

一般情况下，首页改版总是会原有用户的使用习惯，因此在首页的测试过程和上线都需要慎重考虑用户习惯的延续和给予一定的指导。请考虑——

在测试版本上给予用户返回默认首页的入口，允许用户退出测试
在新首页上线后，在一段时期内保留旧版首页的入口，让那些尚未适应新首页的用户能够有缓冲期来完成原来习以为常的任务
如果有必要，提供一个what’s new页面，帮助用户快速了解新首页

我们经验：在新版正式上线后，在首屏为用户提供了新首页指南，在页面底部提供了回顾旧首页的入口，给用户留有充足的时间进行过渡，通过监控旧版本的流量也可以判断用户对于新版本的接受度，从而逐渐降低新版本的帮助的权重，并且在此过程中基本上未产生用户的主动投诉。

以上是我们本次阿里巴巴中国站首页改版的经验总结，在这里分享给有相关困惑或遇到同样问题的同学们，欢迎大家在专业上更深入的探讨。

浅析WEB表单设计

WondeRui — 2012-01-17 19:02:55

设计师不再只是为互联网创造漂亮美观的图形那么简单了，作为一个WEB设计师，我们还需要考虑一些其他的问题，比如用户体验，算法，代码等等。如今用户体验设计越来越重要，对于WEB表单的设计尤其如此。

WEB表单设计的目标是设计出一套让用户能够从填表到点击提交按钮的最简单的流程。这个过程中不需要太多的炫目效果，虽然jQuery的表单插件一直都很受欢迎。在这片文章中我们只关注于表单的用户体验和交互过程。这里的概念也能够有效的帮助你减少用户在填表过程中的挫折感。

保持醒目和简洁

我听过不计其数的用户抱怨注册表单需要太多的信息。如果你正在想办法增加注册用户数量，那么你必须保证你的表单尽可能的易于填写。这点同样适用于其他地方的数据输入。

根据项目的不同，用户需要填写的信息数量也有所不同。注册表格可能会要求用户输入用户名，电子邮件地址，然后两次输入密码，这样当然很合理并且是用户所期待的注册方式。但是也有特殊情况，看看WordPress的默认注册页面。

这里用户只需要填写用户名和电子邮件地址，之后系统会自动生成一个密码并发到你所填写的电子邮件地址当中，这样做减少了原始表格的数量，并且将恶意注册者挡在了门外。你不需要去邮箱点击激活链接，但是你必须在你的邮箱中取得新的登陆密码。

始终与用户的期待保持同步

用户们最讨厌的事情就是页面有出乎他们意料的跳转。你绝对希望你的表单行为保持自然，并且将额外的JavaScript代码减到最少，弹出气泡和Ajax都是很有用的东西。好用的表单不应该被划分成许多小的项目，用隔断将他们彼此分离，那不是好办法。

另一个我们经常犯的错误是错过了HTML的tabindex属性。这个属性从可用性角度来说真是棒极了，因为通过它用户不使用鼠标就能填写完整个表格。但是如果你没有保持tabindex属性的有序性，或者只在某些输入框中使用了这个属性，而另外一些没有使用，那么整个系统一定会出乱子。这一点适用于所有的注册表单，而且同样适用于其他的输入页面，特别是网上购物的信息输入页面。

保密性是最重要的

不论用户输入的是他们的信用卡号码还是电子邮件地址，你都应该将保证这些数据的安全放在第一位。用户信任你的网站和后端代码正确的收集了他们的信息并将之保存在一个安全的地方。

如果可能的话我建议在你的整个网站中都使用SSL认证，这不仅仅保护了用户的注册信息，用户浏览网站的整个过程都被HTTPS保护了。这可能会有点麻烦，但是有些WEB主机会辅助你安装这些功能。当然并不是每个网站都必须这么做，但是你只需要多费一点儿时间和精力就能保护用户数据的安全，你的用户会因此而觉得安全，你和用户之间也能建立起一种相互信任的纽带，何乐而不为呢？

另外，不要使用那些很容易被探测的信息。除非信息是完全非“个人”的，都需要使用POST数据类型。只有在URL结构能够从数据中获益的时候（比如说搜索页面中的search.php?q=my+search+terms）才使用Ajax的GET requests。

更大的输入框

我听过很多关于WEB表单输入框大小的争论。vBulletin，Joomla！和Drupal使用的都是相当小的输入框，大都是10px-12px的文字和很小的内边距。

Diigo的注册表单结构就很大气！你需要缓和不同输入元素之间的冲突。加粗的文字提示你哪些区域已经填写了，哪些区域还空着，当激活某一输入框时，它会变成淡蓝色，提示你光标现在所处的位置。

传统的Digg注册表单就是用很相似的方法来设计的。Twitter的注册表单同样都很大，你不会错过任何东西。他们不会吝啬于用大量白色的空间来突出输入区域。他们的标签系统也很独特，空的输入框中会有预先设置的占位文字，通过颜色的变换，你也可以清楚的将用户输入的文字和系统预设文字区分开来。

结论

现在的WEB设计出现了许多新的设计趋势。最新的CSS3正在越来越多的被设计师们所采用，表单设计也不例外的需要设计师们投入更多的关注和思考。

我希望这些用户体验背后的指导原则能够指引你创造更好的WEB表单。对于后端数据来说，即使是PHP这样简单的语言也能够很好的处理。但是通过一到两个星期的时间，你应该能创造出一套你自己的系统。网络开发者们，不论是前端还是后端，都应该尽力去理解这些设计原则和范例。

源地址：http://www.uedreamer.com/?p=178

给设计师的10个新年决议

玉婷 — 2012-01-16 22:24:05

用这些决议给新年一个良好开端

该醒啦！希望你们都有度过一个愉快的新年假期，而现在，是时候回到工作上来了。去年我们做的确实很不错。我们为自己而站了起来。我们不再免费工作。我们也开始有了自己的小金库（今年请别再让我处理合同的事情）。我们又一次发现了新的排版。我们学会了在设计前先考虑手机客户端的问题。我们学会了制作能响应的交互性网站。我们不再在设计上与 Lorem ipsum 较劲，而开始关注我们正在设计的、实实在在的东西。

今年呢？今年是一个要命的黄金年代！去年我们是处于训练期，今年，我们要开始战斗了！

1. 选择更好的问题去解决

按定义，设计师就是解决问题的人。而这个世界从来没有像现在这样到处都是问题。我们的基础设施很烂，经济纯粹是胡扯，华尔街充斥着犯罪，数百万的人民得不到基本的医疗保健、食物和水。我们不需要一个 APP 去评估你的三明治怎么样，我们不需要知道什么时候睡觉、什么时候起床，我们不需要数字化的农场。我们需要真实的一切。我们需要新鲜的水。我们需要为灾难找到解决方案。

就是现在，我们拥有比设计历史上任何时刻都强大的处理问题的能力、可用的工具，还结合了智能。而我们却用它们制造出狗屎。是时候把眼光放高一点了。让我们去找那些被解决后真的能提高人们生活水平的问题。无论是找出访问医疗记录的更好方式，还是找到不再让 14 岁的学生每天携带 40 磅的课本来回学校的办法，又或为社区屋顶农场制作一个预定系统，这些都比制作一个 facebook 的克隆版有意义得多。

2. 停止抄袭垃圾作品

别误会我的意思，我不是反对抄袭，而是质疑你们正在抄袭的垃圾作品的质量。

设计是一门不断累积的学问，你可以学习他人是如何解决问题的。学习他们处理问题的方法，并试着把这些方法带入到下一步工作中去。

我的意思并不是说你可以逐字地抄袭人家的代码或者直接把图片拖放到你的作品里去。我是说你要学会去认识到并利用你面前可用的知识。认清你在时间轴上所处的位置，争取做下一代设计师会抄袭的那个大师。

不要怕抄袭，要去抄袭正确的东西。我的年纪够大了，我的第一本有关如何制作网页的书叫做《View Source》（查看源代码）。如果我们看到很酷的网站，就会查看它们的源代码。我们复制这些代码，并尝试自己去做这些类型的网站。然后我们加入了一些新的东西，把做好的网站推上线。之后就有另一些人来查看我们的网站，并复制它们。

自宇宙起源，设计就一直跟着我们，而你还没有活到那么长时间呢。了解它、探索它、学习它，并不时地在时间轴上加入一些新的东西让别人去借鉴。尝试去重新解决那些曾被数百万设计师在无视自己的无知和自大的情况下解决过的问题。

3. 停止挽救糟糕的作品

当我指出设计师们作品的问题时，我最常被问到的是：“能补救吗？”

你不是耶稣，糟糕的作品也不是用来挽救的。如果一些东西不再有用，那就重新来过。否则你工作的目的就变成挽救你的工作，而不是解决问题本身。

作品没有感情，所以你并没有遗弃它们。（那些语句你根本都不知道该怎么修改，真的。）

补救的冲动往往来自于不甘心花在作品上的时间都白白浪费了。而你真正在浪费时间的是对自己不诚实、高估了这些糟糕作品的价值。如果你在成功的作品上只花费了一个小时，那这就是你解决了问题的如实的时间。当你意识到你的作品出了问题并试图去补救时，你所做的就不再是好的设计。你在做的是自我挽救。你要为此买单吗？这就是我所说的不如实的时间。

4. 别再让自己变成了障碍

我职业生涯的头十年是这样度过的。我常说“如果我能按照我所认为的它应该被处理的方式去做…”，还深信不疑的认为其他人一定是在阻止我做更好的选择。我常常和其他设计师一起审阅自己的作品，他们会说：“好吧，如果是我这样做…”我会惊讶的盯着他们，直到他们意识到自己说了什么。到底是什么奇怪的基因让设计师自己变成了障碍？

停止设计你所期望的折衷作品。担心出错总比焦虑于让别人信服你要好受一点。客户就在你的脑子里，告诉你把图片再做小一点，logo 大一点，为多页文章标好页数。你选择的是你认为客户会喜欢的字体，而不是解决问题的最佳选择。

对客户来说，找一个好设计师，然后拿到看起来像是他们会做的作品，这是个可怕的过程。客户值得你最好的作品，而不是他们的最好作品。我希望你们合作的真正的好客户，是宁愿他们的意见被挑战的，而不是被迎合的。

要一直做最佳选择的设计。在众多争论和推销之后，妥协总是会出现。但是如果你拿着你的妥协方案出现，甚至是在你试着说明你的作品之前，你就会失去客户对你的尊重——这样做太傻了。

你不能带着恐惧去设计。不要在一拳未出之前就放弃了战斗。

5. 先责备自己

逾越了最后期限？漏掉了一个要点？这些都常常发生。请举手告诉所有人这是你的错。你越早承担起责任就越早可以去着手修复。借口帮不了你。大家都尊重那些勇于承认错误的人。没有人会尊敬把责任推给队友的人。

今年，一切都将是你的错。这种感觉会很好。

6. 保持好奇心

不要做一个满足于现状的设计师。依靠你所擅长的工作来维系生活是一件很容易的事，直到一些事情发生了，抹灭了这种平淡。要胸怀大志。还能记起那些擅长 Debabelizer（一种过时的图形工具）的人吗？不要满足于已经擅长的事情，尝试去做那些你不擅长的事。你会擅长越来越多的事，你也会了解到自己在哪些方面确实不擅长，也将拥有一个较长的职业生涯。

今年 pike（一个动态程序设计语言，语法类似于 Java 和C）会出现很多麻烦的事情，包括那些会给我们惊喜的事，更不用说那些我们去年已经习惯的事。未来不只是有趣，也很凌乱。张开双臂迎接它吧！

7. 学会更快的犯错

当我和一个设计师坐下来后，我做的第一件事就是偷偷看一下文件的命名。如果现在是下午两点，文件的命名是“acme_article_1.psd”，我就知道有麻烦了。下午两点我们应该看到的是修改过后的文件名。如果不是，那可能就是设计师太谨慎太细心了。他们要不是不愿意犯错误，就是不愿意承认自己速度慢。即使你觉得第一次的作品已经成功了（实际上并非如此），也要自我挑战一下尝试另一种方法。相比于努力把第一种想法付诸实践，尝试 50 种不同的方法会让你学到更多。

8. 别再把“妈妈”作为笨蛋的例子

这句话不知你有听过多少次，“我们要把它做的足够简单，简单到我妈妈可以用它”！这种目标是值得实现的，但这种例子不太恰当。

你认为 Chelsea Clinton 会问自己她的妈妈是否明白复杂的东西吗？不会，因为她的妈妈是个坏蛋。你自己的妈妈可能不是国务卿，但是她有足够的才智养育小孩直到他们学会阅读、浏览网页、成为职业人员。她不是傻瓜。所以别再用她做例子了。（更不用说我们是利用一个深爱的家庭成员在遮掩全行业的性别歧视问题。）

别再把“妈妈”当做受众人群的简称。去了解你的受众人群是怎么生活、怎么处理业务的，好的设计来自于换位思考，而不是定型思维。

记得送花给妈妈，她会知道怎么处理的。

9. 学会写作

90% 的设计是需要沟通的，半数将以书面形式进行。一个不会写的设计师不能捍卫他的作品，而不被捍卫的作品就会消亡。

我看过很多很棒的作品结果被糟蹋，原因就是设计师在交稿时没有解释清楚它是怎么映射战略目标的，它是怎么满足项目需求的，也没有一个思路清晰的设计说明。

你听过的最大的谎言莫非就是“作品自身会营销”。这么说的人一定不擅长书写。

10. 获得舒适的争论

记得我说过沟通的一半是以书面形式吗？这儿有另外一半。今年（尽管有玛雅预言）你会花很多时间向人们展示你的作品，他们会针对你的作品提问，你需要知道怎么去回答。有时他们会要求你在作品上做一些变化，你会觉得这是不对的。你要坚定你的立场。你会惊讶于人们只为找出辩解理由的次数之多。不要只因为有人要求净化环境就把农场拱手让人。你只需要平静的告诉他们为什么你觉得你的选择是对的。你是站在保护作品的这一边。保护好的设计作品是你的工作，不是别人的。有时你会赢，有时你会输，但你会一直做你的工作。

总之，记住你有比你想象中更棒的力量，开始用吧！

享受你的这一年，它会相当的棒！

英文原文：Mike Monteiro 编译：伯乐在线-胡玉婷

源地址：http://blog.jobbole.com/11830/

探寻一下用户体验设计的 Experience

Jake Zhou — 2012-01-16 22:13:32

“User Experience”用户体验，在业界这是被 CEO、设计师、Geeks 以及企业管理者反复提到的一个概念。“我们的产品或商品是站在用户的角度来思考、设计、发明……”这是在我耳边最常听到的一些话，但在实际的产品中真的就是这些企业管理者所说的那样吗？我认为只有极少部分的产品真正做到了，当然作为大多数普通的用户可能不会在意察觉产品中的细微变化，而这些细微变化的背后是由许多优秀团队默默辛苦努力的结晶。

移动的交互设计

腾讯移动微博在信息交互上的直观设计充分的显示了它对用户的使用“考虑”，在移动终端上浏览一条微博进入传播或评论时，按通常的做法是你必须用手指点击后界面切换到评论的状态，而腾讯微博只需用手指在信息上向右划过立刻显示评论状态栏而省去了切换界面（没错，跟 Tweetie 一样）。就这个细小的设计优势体现在许多方面：

简化操作，能一步完的事有理由还要多走一步吗。
节省浏量，这对于付费而不是 WiFi 网络的移动用户来讲，绝对是省钱的体验。

腾讯微博另外一项设计令我非常欣赏的就是它的“图片进度”状态。微博中常带有大小不同的图片，当你点击查看原始图片时，你不知要等多久这个图片才会显示。所以这又是一个付费上网消耗流量不省钱的体验，所以有了腾讯微博“图片进度”显示，并非常清楚的知道开原始图片所消耗的时间。这可以用业内非常有名的那句话形容：“即看即所得”，过去学校做公益帮助贫困区，每个人都会捐一些钱。但大家有一个共同的感受就是：我们不知道这些钱具体捐到那、我们的捐赠到底改变了什么？我们不知道也看不到捐赠后的成果。所以腾讯在设计图片显示上让我们知道信息的透明度，而不是一头雾水。

这些只是腾讯在局部做得比较出色，但在整个设计框架中，还没到达完美。在“关注”组显示的方式上 Google+ 设计得就非常棒，Google+“Circle”在移动 UI上横向浏览方式，比腾讯、新浪的菜单式更高效，打开新浪、腾讯“关注”下被划分的群组，进入到那组的界面切换。每次这样因加载页面停留的几秒时间会被浪费，对于新浪和腾讯两家公司加起来上亿的用户，也就等于每次有几亿秒时间被浪费。而Google+的“横向”浏览设计在节省它的几千万用户的几千万秒时间。

如果把 Google+ 的横向浏览与腾讯的直观评论、图片进度结合起来我想将会是一个最佳的用户界面体验设计。

网购的文化体验

在所有的网购体验中，我总认为亚马逊是最“用心”的一个，虽然它上面的商品在国内并不丰富，这就是为什么大家的首选是淘宝。在网购中“收藏”这一功能颇为常见，但细心的用户会发现，在亚马逊的收藏是“Wish List”（心愿单）。我一直在脑海中思考“心愿单”这不就是电商的一种营销上的鬼把戏嘛：什么心愿单，不就是收藏。在随后的日子中，这种想法开始转变，我慢慢觉得“心愿单”比收藏听上去更好。收藏与心愿单作用一样，但从用户心理体验上差别非常大。收藏，一种习惯性的标准做法，你不会感觉到有一种人文的关怀。心愿单，你会从心里感受到这是我的目标商品，我将为此付出。这种文字上的新意会让你体会到有一种人文的关怀在里面。所以两者的区别，为此你会为有个性的体验买单。

在亚马逊中还有一项服务是其他大多数电商没有的（也许以后会有），免费短信包裹跟踪。用户订购商品后，最关心的就是什么时候发货？在亚马逊成功订购商品后到出货时，你的手机会收到亚马逊出货的短信提示。作为一个追求创新和体验的电商，亚马逊除了这些区别其他电商在局部细微的不同外，还有其他细节上令人满意的设计这在我的另一篇文章《化繁为简——设计之美》中有所描述。

除了亚马逊这种极其注重用户的互联网上的体验外，还有一种电商极其投入注重在商品上的流露的个性体验，就是后起之秀乐淘网。

在乐淘网之前的电商之前都围绕着：诱人的价格、丰富的商品以及绚丽的广告等展开轰炸式的消费客户体验，很少有在在商品上投入令人振奋的感受。这种类似“惊世骇俗”的消费体验最终出现在创立不到几年的“新秀”乐淘网身上，它把流行的东西跟自己的产品结合在了一起，造就了一个区别于其他同类产品的文化产品——时尚的小鸟。

愤怒的小鸟、水果忍者、太鼓达人这几款风靡全球的游戏已经让不同年龄段的人感受到它们的魔力，然而乐淘看到了其中的商机。它把人们对这些游戏的痴迷行为运用到了自己的业务中，制作出与之相应的平板鞋。除了像迪斯尼这样庞大知名的机构极少有那家电商或者商家会把游戏中的角色用到自己销售或设计的鞋子中去，而且都是些很普通的动植物角色。对于80、90后穿上带有小鸟、水果的平板鞋将会引来许多同年人羡慕的眼光，这跟手上拿着苹果的手机、电脑的感觉不相上下。

在《IDEO：设计改变一切》一书中有一段文字可以拿来形容这些创造非凡体验的产品：

“创造体验文化要求超越一般，设计出为每位顾客量身打造的体验。不同于批量生产的产品或标准服务，当体验带给人个性化和量身打造的感觉时，体验本身就会焕发出活力。”

我们会为优秀的互联网产品、绝佳的网购体验以及个性化的商品哪儿得到前所未有的满足感，这种满足感令我们可以区别那些平庸、乏味以及一成不变的服务。因此我们会为那些优秀企业创造出来的作品买单，而不太会在意价格本身阻碍的隔阂。这点在苹果的产品中已经得到验证，苹果的产品已经无须再说它好了。但除此之外，我不知道手持苹果产品的人有没有注意到苹果产品本身外的另一个创新之作——激光镌刻。

虽然产品本身价格不菲。当你的 iPod、iPad背后印着你的名字或一句精简的爱情宣言时，你会是什么样的感受？我相信那些正真苹果的用户心底都会带着宗教般的信仰来享受苹果这种与众不同的文化。就像那些乔布斯自传里写到的：苹果不希望自己的产品跟戴尔、惠普这样平庸的产品摆在一起被销售员已背好的台词销售。

结语

用户体验的好与坏不仅体现在科技产品的外观上更多的是在挖掘人们的思维和行为。就像我上面列举到的众多例子一样，这些细微的变化我想不是每个人都会特别在意，但是有了对细节的精准把握并叠加在一起才会有了那些非凡创造的体验。

源地址：http://www.ifanr.com/68324

Android4.0界面设计指南之语言风格

Ro — 2012-01-16 22:07:18

语言风格

当您为App选择单词的时候：

简短。简洁、简单、准群。如非绝对必要，一个句子不要超过30个字母（包括空格）。
简单。就假如您正在对一个聪明能干的家伙说话，但他不是很懂技术属于，并且英语不太好。用较短的词汇，动词以及通用的名词。
友好。压缩你的句子。使用第二人称（“你”）来和用户直接对话。如果你的句子读起来并不像是闲谈，那么你应该再想想怎么写。不要很突然或者令人讨厌，要让用户感觉到安全、开心和被激励。
重要的优先。最开始的两个字（11个字母左右，包括空格）就应让用户感受到这串文本最重要的信息。如果它们不能，那么重新来过吧。
仅说必要的，别画蛇添足。别试着解释细微的差异，大多数用户注意不到。
避免重复。如果一个重要的术语在屏幕或文本块中重复出现，尝试仅让它出现一次。

例子

简短。以安装引导为例:

太正式

请参考随电话附赠的文档来获取更多指示。

更好的

阅读随电话附赠的指南。

简单。以地理位置设置为例:

让人迷惑

使用GPS卫星
定位时，将精确到街道程度。

更好的

GPS
允许应用通过卫星定位你的位置。

友好。应用崩溃时的对话框：

混乱和恼人的“对不起”只是在伤口上撒盐。

抱歉!
操作动作（在应用中）停止响应。
强制关闭	等待	报告

更短，更直接，别总是抱歉的标题：

应用停止响应。
是否要关闭？
等待	报告	关闭

重要的优先。

最新的信息反而在最后

77个家伙顶了该帖, 包括拉里·佩奇。

仅说必要的，别画蛇添足。

如安装引导屏幕：

登录中…
您的手机需要与Google服务器连接来登录您的帐户。这将最多花费5分钟。

如安装引导屏幕：

登录中…
您的手机正在连接Google。这最多花费5分钟。

说明

以上内容翻译自Android界面设计指导网站Android Design

拒绝平庸——浅谈WEB登录页面设计

CDCer — 2012-01-16 21:42:15

用户活跃度是检验产品成功与否的重要指标之一，传统行业的商家极为重视门面的装潢，因为一个好的门面可以聚集人气，招揽更多的顾客。古时候的大户人家院子门口的石狮子或其他的摆件的摆放极为讲究，有一定的风水学说道理，更能彰显主人家的身份地位.由此可见，“门面’就如人的脸面之于人的形象一样重要，而WEB的登录页面就相当传统的“门面”。

现在越来越多的大型网站把登录和首页放在一起设计，由此可见登录页面的重要性，一个出彩的登录界面，将提升产品的品质，赋予产品独特的气质，登录界面也是一个发挥情感化设计，提升用户体验，拉近与用户之间距离的兵家必争之地，本文不谈趋势，不讲交互大道理，不涉及技术，就侃侃用户登录页面的一些设计表现形式。希望这些设计表现手法能给大家带来一些启发和灵感。

优雅大方
如果说iPad是介于传统电脑和手机之间的产品，那么tumblr则是介于blog和twitter之间的服务。相比twitter，它的功能更复杂、内容展示性更强、更加重视多媒体的应用。Tumblr做为轻博客的鼻祖，带来一种全新的视觉体验，安东尼·德·圣-埃克苏佩里曾说过，“完美就是多一点则太多，少一点则太少。” Tumblr的登录页面没有过多的视觉干扰，优雅大方，一切元素的存在都是为了用户更好的登录，登录过程非常流畅。

精致的质感表现
iCloud是苹果公司所提供的云端同步服务，用户有5GB的免费存储空间。负责Macintosh用户界面设计的柯戴尔·瑞茨拉夫回忆说：“乔布斯会一个像素一个像素地检查屏幕上的每个细节，确保相关的图像准确对齐。他非常重视细节，细致程度居然达到了像素的层面。如果发现问题，乔布斯就会立即冲着某个工程师大吼起来。”iCloud登录页面的设计继承了苹果公司对细节的苛求, 细致的纹理，微妙的阴影，精致的质感，完美的细节，金属光泽可以随着鼠标指针移动，底部的图标可以随着分辨率的大小自适应，改变排列方式，确保用户的浏览体验。

iCloud给我们上了很好的一课，有句大家都听过却未必做到的话——细节决定成败，丰富的细节可以提升设计的价值，也是判断一个设计高下的一条很重要的标准之一，精致舒适的质感纹理，给用户一种沉浸式，充满惊喜的登录体验，是一种很棒的表现方式。

小清新的插图
在网页设计中，插图非常具有表现力，它与绘画艺术关系密切。所以大部分设计职位，对手绘能力出众者格外青睐，许多表现技法都是借鉴了绘画艺术的表现技法。插画艺术与网页设计的的结合，具有独特的艺术魅力，从而更具表现力。越来越多的设计师，将插画运用到网页设计中来，生动有趣温情的清新插图，能迅速的抓住用户的眼球，让登录界面的更加具有亲和力，

163邮箱的登录页面就采用了大幅的插图,小邮差很快唤醒了80后等待来信的记忆，有故事的插图与用户建立情感的联系，唤起用户的心灵共鸣，让用户更有归属感。

Vimeo是一家提供高清视频存放服务的网站，在这里可以找到很多来自世界各地非常有创意的设计师。相信登录过Vimeo的朋友都对Vimeo的登陆页面记忆深刻。

人文关怀的品牌传达
设计以人为本，以人为本的设计不仅能提高产品的品质，还能提高设计的艺术水平，而登录页面是体现人文关怀，传播品牌理念的绝佳位置。

QQ邮箱登陆页面每一次刷新都能看到不同的内容，或用海子的诗，或用迈克尔.杰克逊的歌词，唤起用户的共鸣，设计手法简洁，主体信息突出，引导清晰，并没有多余的元素，界面中最重要的操作“登录”按钮使用了交通中通行的绿色，而没有使用常用的蓝色，细节设计非常考究，对每个细节都注入人文的关怀。

新浪微博将登录框设计成一条围脖的样式，用户的每一次登录都是一次品牌传达的过程，切合新浪力推的围脖品牌理念，织围脖的概念深入人心。

越来越大的登录框
越来越大的输入框设计，让用户输入起来感到心情舒畅，登录过程非常愉悦，在显示器越来越大的今天，mailchimp大输入框显的霸气十足，并且一反常态的可以看到自己的密码，第一次在WEB登录框里见到这种设计，非常贴心.正是这种不拘一格的设计，让mailchimp从一个内部项目蜕变成一个该公司最成功的商业产品。

简约而不简单
WEB设计的风格越来越趋向于简洁，登录页面大量地使用留白可以让登录框更加突出。最大程度的减少用户分心，从视觉的角度来看，简约的设计是平静的，砍掉了多余的元素，颜色，形状和纹理，不能使用让人眼前一亮的设计元素，只能靠空白去做视觉吸引力。布局的权衡及简化设计做的不到位的话很容易变的单调乏味，wordpress后台登陆页面采用适当的投影，灰色的巧妙运用，以及出错的抖动提示，让整个登录页面简约而不简单.堪称典范。

随着互联网的高速发展，移动互联网的到来，WEB设计越来越呈现多元化。尽管一个好的设计并代表产品就一定会成功，但却能为产品加分，为产品注入设计DNA，创造独特的风格和视觉感受，好了，今天就先侃到这，作为用户使用的入口，希望这篇小文可以让大家对登录页面重视起来，设计出更多精彩的登录页面。

相关话题：登录、注册的表单源地址：http://cdc.tencent.com/?p=5037

怎样通过设计帮助用户制定决策

C7210 — 2012-01-16 11:16:13

设想一个潜在用户正在浏览你的网站，比较着你们所提供的产品与服务，琢磨着是否要进行购买。也许你可以自信的说，当前的“购买”功能对于用户来说是非常醒目和易用的，但是你能保证在“对比”和“选择”等方面的体验也是同样靠谱的吗？

如今，很多用户体验设计师对于面向用户行为的设计思路已经非常熟悉了。但是在很多情况下，大家的设计都是基于“用户必然会执行操作”的假设。要知道，所有的操作行为都是跟随在某种“决策”之后的；例如，要产生购买行为，用户首先需要在目标商品的选择上做决策。

曾经有研究指出，决策的制定过程是具有很强的弹性的，可供人们参考的因素也不像我们一直以来认为的那样明确和稳固；该过程所处的上下文环境对于决策结果本身具有很大的影响。从网站产品设计的角度讲，这个研究结果是非常重要的；它相当于在告诉我们，作为用户制定决策的上下文环境，网站本身的设计方式不仅会作用于“可用性”等常规的用户体验要素，更可以影响到用户对行为的选择和决策。

决策制定的目标

面向决策制定过程的设计应该怎样进行呢？首先我们要清楚这个过程的目标是什么——简单的说，就是以最低的资源消耗量，换取最合理、最有价值的决策结果。也许大家会注意到，这个说法里存在一种矛盾或折中的感觉，因为通常，好的决策离不开努力的付出。

对决策制定的目标及其固有的内在矛盾的认知是很重要的，因为从本质上说，我们的设计要么可以化解这层矛盾，有效的帮助用户制定最合适的决策，要么反而会加剧它的存在，影响用户的选择和判断；当人们无法做决定时，他们就不会去做决定，对于网站来说，即使后续流程的体验再优秀，也是没有意义的。

面向决策制定的用户体验设计

设计方案的很多方面都会对用户制定决策的过程产生影响作用，包括视觉布局、选项的数量、信息的类型及措辞方式等等。这些因素对于决策制定的作用是很微妙的，但同时也是强有力的。

面向决策制定过程的用户体验设计中，最有效的一个思路，就是促进用户的自然行为方式，挖掘人们在制定决策时所惯用的策略。

通过比较来评估价值

首先我们需要了解的一个关键问题是，用户是怎样判定和评估一款商品的价值的？

人们并非生来就拥有判断事物绝对价值的能力，他们需要一个比较的过程。人们一直在对各种事物进行比较：产品、服务、主意、他人等等；这是人们的一种自然行为，同样也是设计师们需要通过正确的方式来促进和激发的行为。

为了演示“比较”在人们制定决策时所起到的重要作用，我们来看一项有意思的研究(PDF格式)。其中，研究员将一群人划分为三组，并要求他们每个人都对词典的价格进行评估。

其中一组的人们被展示了一本拥有20000条词汇的词典，但它的封面有破损，而另外一组看到的则是一本拥有10000个词条的崭新词典。最后的平均结果是，人们愿意为那本封面破损但内容更多的词典支付20美金，而对于那本崭新的但内容较少的词典，却乐于付出24美金。

然后，研究员将两本词典一起交给第三组，让他们进行仔细的观察对比。结果是，他们更愿意为那本内容更多的词典付出更高的价格，无论其封面是否存在破损；具体的开价分别是27美金与19美金。这与前面不进行比较而直接估价的测试结果正相反。

这个研究看上去很简单，但对于用户体验及相关的Web设计领域来说，有不少重要的看点在里面。首先，我们可以看到，单独的审视一本词典，或是将两本放在一起进行比较——这两种评判方式会对价值评估的结果造成最直接的影响。这也就是我们在前面提到的，人们并非生来就拥有判断事物绝对价值的能力；比较的过程决定了人们对价值的判定结果。

要想正确的判断一本词典的价值，人们需要一些衡量的标准。一本优秀的词典应该收录多少词条？绝大多数的人并不了解。所以在做价值评估的时候，由于无法通过比较来看到利弊，人们只能参考自己内心的主观标准。例如，第一组的人们并不知道他们拿到的词典的内容量是更多的，他们所能了解到的，只是这本词典的封面有破损，所以他们自然更加容易做出负面的判定。

当人们有机会对两本词典进行直接比较的时候，他们才可以就那些他们所关心的方面进行判断，比如收录的词条数量；此时，那些外观上的瑕疵就不再是最重要的了。只有在他们无法对真正重要的方面进行评估时，那些更容易看到的次要因素才会直接决定最终的判断结果。这就是我们所说的决策过程所处的上下文环境对于决策结果本身的影响作用。

所以，如果我们能够针对“比较”这个环节进行合理的设计，就可以帮助用户将注意力放在评估对象真正重要的属性上面，进而做出正确的价值判断。在词典的例子中，另外一个会影响人们的判断结果的因素是“信息”。试想在人们对词典的价格做评估的时候，如果告诉他们一本典型的好词典所需要拥有的词条数量，那么最终的估价结果是否会发生变化。

为“比较”的环境空间进行设计

如前文所述，“比较”的过程有助于人们对目标对象的价值进行更加合理和全面评估；而能否对该过程所处的上下文空间进行合理的规划与设计，就是我们所面对的挑战了。优秀的设计方案可以全面而有效的展示目标对象的重要属性，帮助人们充分的了解关键信息，做出合理的决策。

要更好的了解怎样针对“比较”进行更加有效的用户体验设计，也许最好的方法正是“比较”。让我们通过正反两个方面的一些实例来具体看看吧。

实例1：设定上下文环境

下图中的两种方案，哪个更具有对比效果？显然是第一种。在这里，正是“原价(Regular Price)”为比较行为设定了上下文环境，让人们在判断当前价格是否划算的时候有了参照的依据。虽然第二个设计方案中的现价比第一个里面的要低2美金，但价格的对比效果让第一种方案更具吸引力。

实例2：突显用于比较的关键信息

下图演示了一个负面的例子。这个设计方案希望通过配色的变化来体现出三款服务的差异性，但并没能有效的突出重要信息。他们假设用户会仔细阅读每款服务的细节信息，然后进行比较；而实际上，用户更希望在最短的时间内对每款服务进行充分比较，了解它们之间的差异在哪里。这个方案显然没能以一种容易辨识的方式来展现那些用于“比较”的关键性信息。

实例3：提供参照物

下图中的实例体现出了人们对于“比较”的自然需求。多数人会关心他们是否有足够多的存款；类似这样的需求中，仅仅使用一个数字来呈现用户的存款信息是不够的，谁知道5万美金的退休金是高是低呢。这个实例网站的产品策划人员及设计师很清楚人们在这时需要一个参照物来进行比较——他们在用户个人帐目的下方增加了一个“和你相似的人”作为参考指标，显示了用户所在行业的平均水平，并用柱形图的方式清晰的体现出了对比的效果，使用户能够一目了然。

实例4：对比度

我们可以在下面的实例中看到，通过柱形图的形式表现出来的用户打分情况，在视觉上具有很强烈的对比效果；类似这样的方式可以有效的加深信息在用户头脑中的印象，促进选择决策的制定。

实例5：增强视觉表现形式的可扫描性

这也是一个负面的例子。下图所示的页面中，其设计方案的本意，是希望用户可以逐条对比PC与Mac的性能参数，并且最终发现两者在性能几乎完全相同的情况下，价格差异是如此的巨大。然而，居中的内容对齐方式却使这种效果打了折扣，用户必须以一种不适合视线扫描的方式逐条阅读内容信息。另外，内容配图的尺寸也显得过大了。

实例6：突出特色

下面实例中的数据表格就是一种有效的内容形式，它很便于视线扫描，用户可以在很短的时间内清楚的看出TD Bank在各方面的表现都胜于对手(至少是在他们自己所选择的这些服务项目中)。我们来简单看一下视觉设计是怎样对页面信息的呈现进行有效支持的。首先，在标题栏中，TD是唯一带logo的银行名称，并且放在了最左边；无论从样式还是呈现顺序的角度，都可以保证让用户首先看到TD这一栏。另外，与其他列不同的是，TD所在的列中使用了背景色。当然，为了突出他们自己的服务优势，对于所有这些项目指标，TD一列中都是绿色图标；而即使竞争对手会提供同样的服务，也只是使用灰色的对勾作为弱化处理。

总结

我们来回顾一下前文中的内容要点。面向决策制定的用户体验设计中，最有效的一个思路，就是促进用户的自然行为方式，挖掘人们在制定决策时所惯用的策略。要时刻注意两个方面：

决策制定的目标，及其固有的矛盾因素。
人们并非生来就拥有判断事物绝对价值的能力；比较的过程决定了人们对价值的判定结果。

要帮助和引导用户进行选择判断，关键在于我们能否对决策制定过程所处的上下文环境进行合理的规划与设计；以下这些方式原则可供我们参考：

提供参照物，让人们更容易通过比较来判断目标对象的价值。
让关键信息更醒目，便于用户在最短的时间内将注意力集中在最有用的信息上。
通过合理的页面布局及视觉样式，让内容更便于视线的扫描。
在正确的地方提供正确的信息，去除那些不仅无法帮助用户进行比较，甚至可能阻碍决策制定过程的信息与页面元素。

在这个过程中不存在所谓的中性设计，任何细节中的设计都会作用于用户决策的制定。这与可用性设计的道理是类似的，无论设计师是否刻意为之，方案中的每个地方都会从正面或负面影响着产品的可用性。

从历史的角度讲，“决策制定”方面的相关话题，并没有在用户体验设计领域中受到应得的关注，这种情况需要一点点的被改变。我们应该逐渐了解到，对于网站产品的目标期望来说，用户决策的制定过程其实一直在扮演着重要的角色。

本站原创编译文章。如需转载，请注明：本文来自Be For Web

英文原文:

http://uxmag.com/articles/decision-architecture-de...

译者信息: C7210 - Web设计与前端玩家，现就职于大众点评网产品部用户体验设计组(UED)

源地址：http://beforweb.com/node/40

2012年1月书友会暂停通知

千鸟 — 2012-01-14 19:58:42

1月正值新春佳节，苦逼了一整年的设计师们也都该回家过年了。

所以，1月UCD书友会暂停一期。

预祝大家春节快乐。

源地址：http://ucdchina.com/blog/?p=585

Android设计原则

羊老师 — 2012-01-13 17:04:22

译者按：在iOS HIG已经强大经典了N年之后，Android终于推出了一套比较系统的HIG（大概是为了配合Android 4.0 Ice Cream Sandwich）。仔细比较两套HIG的“设计原则”部分，发现完全是截然不同的两种风格。iOS HIG走的是更专业型的路线，描述严谨且有不少的专业词汇（比如Metaphors、Consistency之类的）。而Android则显得亲民许多，不仅描述方式简要易懂，配图鲜明直观，甚至还用了“me”作为了一系列要点的标题，更充分地传达出以用户自身的体验为中心的思路。

设计原则

这些设计原则是由安卓的用户体验团队制定并应用的，以此来保证用户心目中最佳的用户体验。应用开发者应该参考这些设计原则，并将之用于自己的创作与设计，有针对性地对应用的用户体验进行调整。

吸引我

以令人惊讶的方式取悦我

漂亮的界面，精心设置的动画，或是恰到好处的声音效果，都是快乐的情感体验。各种细微的效果精妙地组合在一起往往效果惊人，不仅显得轻松明快，更可以营造出丰富强大的氛围。

真实的物件远比按钮和菜单更有趣

使用现实世界中的对象和操作来构建应用中的对象和操作。这样不仅能够帮助用户，尤其是新手，迅速地理解应用程序的操作方法和作用，减少认知成本，同时也使他们能获得更多的情感满足。

把它变成“我的”

人们喜欢添加个性化风格，因为这让他们感觉像在家一样一切尽在掌握，也让这个应用显得和自己一样与众不同。应用应该提供明快合理且漂亮的默认值，同时最好也考虑添加一些有趣但不妨碍主要任务的自定义项目。

了解我

随着使用时间的推移，应用应该了解并记住用户的行为和使用偏好。不要让用户一遍又一遍作出相同的选择，让他们能够方便地使用上一次的操作会更好。

简化我的生活

保持简短

使用简单的单词和短句进行说明——用户极有可能跳过冗长复杂的句子。

图片比文字更快

尽量使用图片来进行说明。图片更吸引用户的目光，往往也比文字更有效。

为我选择，但让我来决定

智能地推断用户的行为，并推荐相应的解决方案，而不是一开始就询问用户想干嘛——太多的选择和决定让用户烦躁。不过为防万一推荐得不对，记得给出“撤消”操作。

只在我需要的时候显示

同时看到太多的东西让人感到不堪重负，所以最好把复杂的任务和信息分解成小小的步骤。隐藏当前不需要的选项，并让当用户学会在需要时到哪儿去找它们。

我应该知道我在哪里

让用户清楚地知道他们在应用中的位置和操作路径。让你的应用中各个部分看起来有明确的区分，并在界面切换时使用适当的过渡效果，以表明它们之间的关系。对正在进行的任务提供反馈。

不要丢失我的内容与设置

保存用户花费时间创建的内容与设置，让它们在任何时间任何地点都可以被访问，并在手机、平板电脑和计算机之间保持同步一致。这也可以让升级变得更加容易与方便。

如果它看起来一样，那它的功能也应该一样

尽量使用明显是视觉差异来帮助用户区分功能上的不同。避免使用看上去相同或相似的模式、操作来实现其实并不相同功能。

只在重要的时刻打断我

如同拥有一个优秀的私人助理一样，用户不应该被无关紧要的旁枝末节所打断。人们希望能集中注意力完成手上的任务，除非有十万火急的事情需要处理。任务中的一次打断真是让人觉得费力又沮丧。

让我惊艳

给我各处皆适用的技巧

当用户自己摸索出使用技巧时会感觉非常良好。在你的应用程序里使用其他安卓应用广泛采用的交互技巧——包括相同的视觉模式和肌肉动作，可以让用户更容易上手也更容易获得满足。比如，“轻扫”就是一个在安卓应用中广泛使用的良好的导航快捷手势。

不是我的错

友好礼貌地提醒用户改正错误——在使用你的应用时，用户当然不希望自己显得很蠢。如果出了差错，请清楚简明地给出解决方案，以便用户能够快速地进行修正，避免提及让用户看不懂的技术细节。如果应用能够在后台默默处理那就更好了！

积极反馈

把复杂的任务分解成较小的步骤可以让用户更轻松地完成。给每个行动都提供反馈鼓励，即使只是一个微妙的光芒也会让用户大受鼓舞。

为我完成复杂的任务

让新手使用他们能够做的简单操作，完成他们从未奢望过可以处理的专家级任务。例如，结合多种照片效果的快捷方式，只需几步操作，就可以使业余的照片看起来让人惊艳。

让更重要的事情更快

并非所有的操作都是平等的。决定在你的应用程序什么是最重要的，并让它能更容易更快速地被找到和使用——比如照相机的快门按钮，或是音乐播放器的播放/暂停按钮。

via Android Design Principles