页面性能不仅仅是前端同学的问题

页面性能的重要性不再赘述，就我个人而言，能忍受一个网站加载出DOM和css的时间是5秒，否则就会毫不犹豫的关闭网页。上面罗嗦了半天，实际上只想说明一个问题，设计师需要考虑页面性能。实际上设计师就是一种“通才”的角色。在传统设计领域，多数设计大师都是通晓好几个行业，比如科拉尼。在设计过程中充分考虑到各种因素，这是设计的难点，也是成就一个好设计的关键所在。以往那种网页设计师做好psd图稿，扔给前端工程师去做DEMO的时代已经过去了，因为互联网进步了，用户进步了。

原生控件的应用——关于页面性能，设计师应首先考虑的

浏览器的原生控件虽然有其不足之处：ie的外观很难控制；不能支持更加丰富复杂的交互等等，但它对浏览器的兼容支持得特别好，在用户需要费力填写表单的地方，原生控件相比非原生控件会提高性能，让用户操作起来很流畅。这也是为什么在一些银行的网站或者客户端上，会用原生的select来代替很多支持复杂的交互控件，比如选择银行。在满足设计需求的前提下，优先考虑原生控件会让你的页面更快，兼容性更好，你的前端同学也会少许多抱怨。设计师应当了解，在写具体应用中控件时，不止是展现出用户可操作的部分就完事了，还有很多事情要做：验证，安全，兼容，框架等等。这里可看财付通的付款页面的js请求数，会吓你一跳的。

我在使用招行专业版客户端的时候，遇到过一个很好的控件交互设计。需求是填写银行卡的开户支行，给用户一个input让他自己去填显然是不靠谱的。招行的做法是先给一个搜索框，让用户输入关键字，比如我住在西湖区，我就输入西湖二字，页面刷新之后返回一个结果列表，从中用户来选择支行，这样搜索过滤之后的结果，只有10条左右，容易辨认。而我只用了两次就学会了这种操作，额外的好处是操作过程中页面反应相当快。而我在其他网站上选择开户行支行的时候，遇到过省市，再选支行联动控件，输入+下拉列表混合控件，选择的时候都能方便且正确的选中，但是我点击控件的时候相应速度却有延迟，心里略有不爽，这就是差别。有关原生控件和复杂控件的应用对比，可见我的一篇旧文：易用且轻量级的交互设计。

而随着html5的标准日益完善，新的原生控件会满足更多的需求，比如外联数据源xml，浏览器内置的不同数据类型的验证，这些会大大减少js的体积。当然这依赖着国内ie6市场份额的进一步下降（目前为60%）。相信未来一些轻量级的非原生控件，也会慢慢纳入到html的标准之中，比如困扰过很多人的日期控件。

页面的框架——设计师也能帮助到前端

我并不完全赞同设计师必须要懂代码，这应是因人而异的。但一个好的网页设计师，必须要为页面框架考虑，小到一个页面上的一个控件，大到一个项目。这是经验的积累，并不依靠对代码的理解，和设计原则中的一致性是密切相关的。不仅仅是少两张图片，少两行代码，充分考虑css框架的设计，组件的重用，图片的分割和整合，这些能让页面性能提高不止一个档次，同时保证设计感。

我感于日常工作及学习中，大家讨论设计时设计页面性能的次数十分少，而它又是项目中设计师和前端最主要的分歧点，为了消弭这种分歧，最好的做法就是大家互相增进了解。我在公司里有给设计师分享前端知识，给前端分享photoshop知识，也是为了大家一起进步做出更好的产品和应用。其实在自己的博客上实践提高页面性能的各种方法，是相当轻便且有效的，实践过的常识经过转化再提炼，成为知识，这点我十分认同白鸦和千鸟的看法。

类似的网志，挑你喜欢的看：

• 易用且轻量级的交互设计
• 《程序员》7月刊上刊登了我的网志+工友李白离职
• 设记系列：Draware手机界面设计
• Draware概念手机界面的flash演示
• 和翔子聊交互

原设计方案中，历史记录这块是一个添加联系人控件

上图中的联系人控件功能很强大，交互设计得也不错，看图便知。用户可以在这个widget里面直接选择保存的联系人（有分组），亦可即时搜索；同时还记录最近交易的，方便有连续交易行为的用户。抛开具体环境不谈，联系人控件在这里是一个很有用的工具，它帮助用户选择转账的对象；用户不需要记忆复杂的银行账户信息，只用记得对方的用户名就可以，用户体验应该是不错的。

但是在具体应用环境中呢？

文章开头的那张图是一个刚上线的新产品截图。我们来分析一下，用户在使用一个刚上线的新产品的时候，是否有从联系人中选择的需求呢？实际情况很可能就是大部分用户在两三个星期内只使用过一次这个产品，因为它不是普通用户日常所必须的。少数用户会使用过至多4-5次，如果到了10次，那这个产品无疑收获了巨大的成功，显然在短期内这是不可能的。因而，在可以预见的时期内，用户的联系人控件中只有1-2个联系人，之多4-5个，这样的话联系人控件在这里还有必要么？

如果结论是没有必要的话，联系人控件放在这里其实在交互上并没有消极的影响（用户只不过从有限的几个联系人中选择了一个而已，一样可以不需记忆复杂信息来完成任务）。但它对页面性能（载入速度）却是有影响的，这样一个联系人控件其实是调用了好几个js文件，而对于一个刚出生的新产品来说，页面性能是很关键的一个指标，太多的例子表明，页面载入速度如果提高个一两秒，用户的感受会好许多，自然而然商业价值也会提升。

有没有替代方案？

替代方案就是文章开头的那张图中的历史记录下拉框。这个方案在记录不超过10条的时候会很好用，轻量级且明显，没有多余的（用户在还处于初级阶段时候用不到的功能，比如：联系人分组，搜索等）。如果不考虑安全因素的话，这个历史记录的方案可以非常方便地用cookie来实现；在实际情况中，为了避免银行卡信息泄漏所用到的解决方案也是相当轻量级的。在用户第一次使用时，可以隐去历史记录；而用户下次再来的时候，则把历史记录放出来。等到用户成为“高级用户”了，拥有许多联系人（至少10+），并且将联系人分组了，这时我们可以对产品进行升级，将强大无比的联系人控件放出来供用户使用，这样的用户体验会是很好的。而这也是产品迭代的敏捷开发思想的体现。

本文的小例子绝对不是best practice。交互设计绝不是很多人看来画画白板，选选控件这样机械的活。书本上的知识运用到实践中，需要相当的经验积累以及敏锐的洞察力，这些才是交互设计师的财富。大家如果有好的交互设计经验，也请分享给大家哦。类似的网志，挑你喜欢的看：

• 从需求到功能再到实现
• 网页设计师也该关注页面性能
• 设记系列：Draware手机界面设计
• Draware概念手机界面的flash演示
• 设计中的边际效应

之前有写过记录这个手机界面概念设计过程的系列网志（还没完成全部），已完成两篇：Draware手机界面设计和设计系列：Draware是怎么炼成的（1）。如果你感兴趣可以订阅我的博客，我会尽早完成这个系列网志，到时就能在RSS中看到。

界面演示一：idle
界面演示二：dile
界面演示三：call history
界面演示四：message center
界面演示五：webr

类似的网志，挑你喜欢的看：

• 设记系列：Draware手机界面设计
• 设计系列：Draware是怎么炼成的（1）
• 易用且轻量级的交互设计
• 从需求到功能再到实现
• 网页设计师也该关注页面性能

1.设计最初肯定是下意识的，心智模型更是人类自身无法完全了解的。

就算到了现在，我们所讨论的设计仍有部分（比例因人而异）是下意识的。但到了今天再做设计的时候，单纯靠经验和感觉来做设计是不够的了，肯定要有数据说话，这个数据如何得来、统计方法都是理论支撑。而心智模型这个东西，实际上在产品设计这块已经有相当多的案例是设计和它结合一起做的。阿莱西、深泽直人的许多作品就有相当强烈的心智模型的印记。

而在web这一块，对于交互的探索确实还没有多少和心智模型相结合的地方。所谓心智模型，是需要人长期经验积累而形成的，譬如手拿杯子的动作，不同的地区的人对早饭内容的理解等等。互联网的交互发展才刚刚开始，用户在浏览网页中所展现出来的习惯还比较琐碎，并没有十分系统的心智模型可以提够研究。像google做的以gmail为核心的心智模型的研究其实也只是刚刚起步而已，研究内容比较松散。

不过我相信，这将会是未来交互研究的重要发展方向，诺曼的书已经反复在论证这一观点。不管是产品交互还是互联网的交互，根源的本质都是一样。

我最近在做的一个项目有一个需求是：一个网上学习管理系统的管理员可以添加一个持续一个月，参与人员40多人的课程计划，其中包括几十门课。在做这个功能的交互的时候，我会考虑制定一个计划到底是什么样的情形？如果不是在web上来完成这个工作，人会这么样来制定一个计划。这里，就把用户对于“制定一个计划”的认识加入到了交互设计的思考范畴。有意识地去思考用户的心智模型有时候的确会给你带来很多新的想法，当然，也有越陷越深的危险。

2. 我相当同意你对技术的看法，而且最近我深刻体会到了做设计的了解一定的技术的重要性。

你可以不会编码，甚至看不懂java类的声明都不要紧，关键的是你要知道你脑袋里想到的东西是如何被一层一层传到最底层——持久层的。当然，有的情况会是方向倒过来，但我并不赞同。

这两个多月来我接触到的技术人员里，他们还是很看重“设计“的。最近不知道为什么，用户体验这个词被喊得很厉害，我周围的人都在说这个词，可能是支付宝的战略关系。技术人员能够参与到设计中是最好了，不过最好还是设计师来决断。一个好的设计师不一定每次都冒出很多好点子，更需要的是搜集和决断的能力。决断力其实是被很多人忽略却相当重要的能力。但从我这次项目经验来看，刚出学校门的程序员和刚出学校门的设计师在某些地方很相像，那就是看问题还不够大局，或者说明晰。他们说的一些交互想法都有很大的硬伤，而我们对技术的理解也有很多可笑的漏洞。一个好的团队必然是互补互足的，技术和设计人员耦合得越紧密，知识面叠加得越多，沟通成本就越低，效率自然就高了。

3. JSP和ASP等等也不能说是平台吧。

它们都是页面渲染技术标准啊。服务器端运行jsp，然后返回到客户端html，jsp自身是带着功能性的。然后客户端上也能处理脚本了，也就是JS，所以很多轻量级的应用都放在JS上。JSP已经达到分离页面（MVC）的地步，但是它还没有彻底，Spring在这方面做得更好更强大。开发上JSP这个标准就慢慢没落了。也就是说JSP已经达到了前后端分离，只是还不干净。如果说网页是静态的，那前后端分离也没有必要了，当有了动态页面，就需要页面渲染技术来把一个模板和一个context合成一个文本。

比如
hello,&name
和
{“name"=>”world”}

通过模板渲染就会得到hello,world
而用Velocity来替代JSP，则会更简单，这里就不详细说了。在我写vm的过程中所体会到的是，velocity远比jsp要来得方便。基本上和html没什么太大的差别。

站在框架本身的角度上，它提高了重用性、扩展性和可用性。用框架就表明你无需单个地对某个元素进行大量的调试啊兼容啊等等。这样一来，框架本身就限制了元素本身的创造性，这是它本身的劣势了。不过框架最大的取舍点还在于，如果你是UI框架，是否和系统框架能够融合，这才是最重要的，否则你JS写得再好，发现放到Spring里之后不能用，就悲剧了。

4.JSON好就好在它提供前后端数据传输的格式。

和XML相比，两者在可读性上没什么太大区别。相信前端开发会非常喜欢json，因为它可以写出很实用美观可读性也强的代码，但是后台开发则会更偏好xml，因为它是标准的结构化标记语言。json易于解码，只要定义好数据结构。喜欢json是因为js拥有很大的创造能力，而json就为这种创造能力搭建了实现平台。只要前后端开发沟通好。不过我是无法预见JS的未来，虽然web发展以来有很多模板语言更新换代，但是html/css/js这三者还是依旧，在追求标准的年代，这三个很难拆散，也就意味着很难取代其中一个。

时间有限这次就聊这么多了～～

类似的网志，挑你喜欢的看：

• A beginer guide for designers who wanna learn html&css
• 3种css中的white-space使用技巧
• 网页设计师也该关注页面性能
• shimu将不再对ie6做兼容（更新：已兼容chrome）
• 从需求到功能再到实现

这一篇focus在前期的设计，包括icon，交互等等。

一：概念的产生。

概念是在一天晚上睡觉的时候产生的。当时想，像iphone那样那么多的应用放在一起，用户在操作的过程中会不会不太方便，一个页面上有十多个icon，寻找一个icon会花费一些时间，甚至用户所需要的应用会在下一页上（iphone换页的交互方式是拖拉页面边缘）。如果有一种交互方式能让用户不需要选择就直接到达应用，那会大大提高易用性和可用性。

这种交互方式未来会有多种解决方式，以现在的无线技术发展前沿来看，context-aware（基于上下文的感知）、gesture recognition（捕捉手势，葡萄牙学者研究的方向： The current feasibility of gesture recognition for a smartphone using JEME. New York）等，都能为这种交互方式提供可能性。而我在那天晚上想到的是用手指在屏幕上画，画那些经抽象icon后得到的图像，然后页面就跳转到用户想去的地方。

这实际上是关乎于信息显示的方式。现在大多数手机都是将所有应用的icon放在主页上，然后让用户来完成判断、选择的过程，从而过滤出用户想点击的图标。

直接把应用显示在主页上，让用户完成判断、选择的过程：

用户输入信息，系统来完成过滤和映射的过程：

如果能够让系统自己来完成判断、过滤的过程，用户只需要输入指令，就能到达相应的页面，这无疑就省去了很多步骤。要让系统具有这种特性，有两个关键元素，一个是过滤条件：用户画什么？一个是映射关系：用户画出的东西怎么应对手机应用。

二：icon的设计

前面的概念提到，这种新的交互是用户在屏幕上画出icon抽象后的图像。于是Draware的icon的设计就需要满足：

1. 线条化，很简单，容易抽象出来
2. 辨识度高，最好能用户一看就知道是什么
3. 容易记住或者学习，用户在使用过几次之后就能熟记icon抽象出的图像。

在满足这三点的情况下，设计了一组icon和它所对应的图像。

在项目后期，我还延伸了这种交互。手机上一个通话的icon是链到通话记录和拨号两个页面的，在用户画出图像之后，系统有一个缓冲时间（一秒左右），用户在这个时候可以进行第二次操作来选择具体要去哪个页面。同理应用于短信页面和写短信页面、拍照页面和相片库页面、摄像页面和视频库页面等。

其实Draware项目对于这种新交互方式的探索只是刚刚开始，抽象图标后的图像并不是用户在屏幕上去画的最佳方案，在我的预想中，一个语义强烈的动作会是很好的图像，比如说在日常生活中打开信件的动作，应用于短信的图像上。下面这个图大致的显示了图像演变的过程：

下一篇预告，具体页面的设计。包括视觉的细节和页面具体的交互。类似的网志，挑你喜欢的看：

• 设记系列：Draware手机界面设计
• Draware概念手机界面的flash演示
• 从需求到功能再到实现
• 网页设计师也该关注页面性能
• 易用且轻量级的交互设计

一，背景

在Trilogy实习的时候，在Zozoc这个项目中做设计。事实上当时这个项目的business goal已经很迫在眉睫了。当时Zozoc还没有收费，通过viral提高的UV每周在60%左右，下载产品的用户只占UV的20%，但用户流失率却在50%以上，可以说用户黏度是非常之低。

而项目可以利用的资源也是不容乐观，当时我们有web/wap/sms几个可以利用的资源，其中web方面由于人力原因，项目老大就排除了这个资源。也就是说，我们需要赶在Zozoc收费之前，近1个月的时间，将UV的增长率提高到50%以上，conversion rate要到60%，而用户流失率降低为10%以下，而能利用的资源是wap和sms。

二，前期的挫折

可以说自从我开始接触项目实践以来，这次是压力最大的。每天都在与PM和老大沟通。Goal是非常的清晰了，基本的用户需求其实早已明确，就是用“免费”的短信，或者是说比传统短信通道资费更便宜的短信。但何以用户来到我们的web或者wap之后下载的却不多？而下载产品后流失的却这么多？

如果我们的产品足够好，用户也有这样的需求，按照道理是不会出现这样的问题。毛病在哪？一开始我们认为用户可能不了解我们的产品，对Zozoc的优势并没有清晰的认识，因而都成了inactive user。所以通过brain storming，我们制定了一份通过sms来推广的plan。这份plan具体内容是通过短信通道向下载过Zozoc的用户发送软广告，内容多种多样，极尽勾引之能事。

同时，我也负责改进我们的wap站点，显然，原有的版本并没有基于用户更多的考虑，而是站在我们产品本身的角度来设计的。但这时由于时间紧迫，并没有很多时间来改进设计，只能在原有的基础上增加一些可用性，而这些可用性实际上仍然是架空在用户会花上5秒停留的前提上。

结果很显然，第一次改进并没有取得多少实质上的进展。UV只提高了3%，conversion data维持不变，用户流失率略有下降。

三，反思

事后分析，我们应该是从一开始需求定位上就有错误。的确，我们的目标用户是喜欢免费短信的。相当数量的人在使用各种各样的免费短信软件（当然，随着当时SNS的热潮，很多软件公司也挺进，我当时也头脑很热，认为这是提高我们用户黏性的一个好办法，还向PM提出过，现在看来，这很荒谬）。对于免费短信相关的网关质量、通道质量和客服服务等，用户都有相当的需求。但这些仍然是大的需求，用户为什么会不用我们的软件？这恐怕曾经困扰过很多互联网业从业者。一个产品做出来，设计开发的人自信满满，这么优秀的软件肯定能得到用户们的喜欢！然而结果却很让人失望和伤心，甚至是委屈。究其原因，是我们并没有真正明白用户的需求。

用户的需求80%以上都不是问出来的。我试过问很多身边的朋友和同学，用哪些免费短信软件，即便飞信发其他运营商的手机要收钱，你们为什么仍然要用？答案让我大吃一惊，除去网关、通道质量这些正常的原因之外，很多人都不出个所以然来，为什么自己会执着于飞信。而我向他们介绍Zozoc时，他们更是吃惊的说，原来不同运营商之间发短信也是可以免费的！

问题到这里，实际上有些明白了，原来我们并没有找到细化之后的用户需求来进行改进。还有很多细化的需求：用户可能并不知道自己的手机应该安装哪个Zozoc版本；如果下错了安装包，安装过程中出现了问题，用户可能就会认为这是个骗子软件等等等等。站在产品架构的角度上，对用户的经过细分的需求进行分析，才是可行的出发点。

四，执行

新的plan比起原来的要进步很多，在sms软广告上面，针对很多不同用户的需求，设计了很多短信内容。也提出了用户等级系统，积分奖励等等。用户其实很好玩，虚拟头衔一直是吸引用户的一个大因素，而积分，就算在当前没有多大用处，但是在广告中提到众多用户爱好的东西（从BBS上的帖子搜刮而来），用户也是相当喜欢。而对于那些从来没有用过Zozoc的用户，我们也设置了很多应用情景，通过短信发给他们，让他们尝试着使用。

在wap改进设计方面，更是细化了很多用户的需求。用户不知道自己手机该装哪个version的Zozoc，在经过数据分析后是个大头（从选择版本安装的页面跳出的用户占70%以上）。于是我们决定开发一个automatic-installation的功能，这也是非常符合Zozoc特色的功能，真正care users。同时这个功能的exception handlement也是设计得相当完善，考虑到了不同的场景。这个功能开发出来后，用户只需要访问wap站点，就能自动提示安装正确版本的Zozoc到自己的手机上，中间如果出了一系列问题，则会有向导帮助用户完成版本的手动选择。

同时也在wap站点上加入了很多为用户需求设计的功能，broadcast sms/blessing sms/joke sms/special contact，这些功能都是在这段时间集体爆发出来的点子，给了用户更多的发免费短信的理由。

在设计的过程中，也在不断的和工程师沟通，确保这些功能都能开发出来。实现应用环境的限制实际上也削去了很多不必要的设计累赘，我感觉这种经验是弥足珍贵的。我们往往可以设计出功能不错的产品，但最简洁最符合用户使用习惯的产品却不多。

五，总结

以前总说以用户为中心的设计，而我感觉UCD更应该是从用户需求开始的设计，用户这个中心点不应该靠后，而应该在产品设计最前端的位置，从一开始就指导整个产品设计的流程。

比较让人遗憾的是我由于毕业设计的原因，在项目目标未完成的情况下不得不离开了Trilogy。幸而在后来听PM说，这个plan成功完成了预期的目标，这简直让我下巴掉地上去了。之前我经常挂在口上的是这项目肯定完成不了，Zozoc可能要完了。我非常高兴，同时也带点儿自豪，为这个项目付出了相当多的精力，有此回报，我也很满足。现在Zozoc再次改版，因为开始收费了，我也帮忙做一下visual design。希望Zozoc能就此成熟起来，毕竟一个有“收入”的软件才是真正给用户高质量服务的，才是真正运转的。

P.S. 有兴趣的可以手机登录wap.zozoc.com来看看wap页面，或者用http://a1.timewe.net这个地址来在电脑上浏览类似的网志，挑你喜欢的看：

• 易用且轻量级的交互设计
• QQ2010beta3内置的腾讯微博体验感受
• Draware概念手机界面的flash演示
• 设计系列：Draware是怎么炼成的（1）
• 网页设计师也该关注页面性能

虽然有相当多的瑕疵，不过还算是比较完整。最大的收获应该是实现了自己的一些交互的想法，在视觉上也有了突破。

不过实际而言，研究并没有进行到很深的一个程度，限于精力和时间吧，对于draw这个动作的细化还只是在比较表面的阶段。

先给大家看看最后的poster和swf动画：

动画原来是几个swf串联起来的，虽然体积小，但是需要摆好几个swf在上面，所以录影了,画质有些下降- -大家将就点吧。记得戴上耳机，里面有音效的～

点击观看：

类似的网志，挑你喜欢的看：

• 设计系列：Draware是怎么炼成的（1）
• Draware概念手机界面的flash演示
• 易用且轻量级的交互设计
• 网页设计师也该关注页面性能
• 网页设计(web design)和用户界面设计(UI design)