既然我们已经做了这么多的项目，那有一些经验我觉得还是值得跟大家分享一下。

关于设计

对于大多数网页设计师来说，设计可能就像平面设计一样，排版，调色即可。但是这里我要说一下网页设计与平面设计有非常大的不同，其中最不同的一点就是，网页设计是有精度的，不仅仅要对大版面考虑精度，对于细节同样需要考虑。甚至是文字的使用与字体大小 ，行距等。

其中的计算我在以前的文章中都有介绍。

前端开发手册之设计篇 里面详细的讲解了关于字体与设计时应该计算分格的问题。

前端MVC – PSD设计篇 里面也同样讲解了关于PSD转HTML时应该注意的问题。

我这里以GlobalMakret Web Design 2011为实例，这是设计稿（已经去除辅助线与标尺）：

关于前端开发

在完美的设计之后，就到了实践的步骤，让设计稿动起来。

在这里首先要说一下，关于字体的差异，在PSD转HTML时一大问题就是字体不能完全转换，因为浏览器渲染的问题，不同的浏览器里对字体的渲染并不相同。所以这在设计时同样需要考虑的问题。

先看图，开发后的HTML页面（Win7 Firefox3.6 截图）：

可以看到Win7对于字体的渲染效果还是非常不错的，由于使用了ClearType技术，对字体的渲染几乎可以达到PS里的锐利效果（对于IE效果会更好些，IE对字体的渲染一直都不错）。

重叠

设计就让他完美的去实现，这才是我们的目的，不然设计师费了那么大的力气设计的作品就这样被糟蹋了肯定会骂娘的~

这是把两加图（设计稿与浏览器截图）重叠后的效果图，从图可以看到，图片是肯定可以Perfect Pixels！但是文字的确非常难，但是我们也一定要至少保证首字母是应该重合的或者差不多重合，由其是行距，这行关键，因为设计就在于这几PX的版本中，如果这都无法保证，那就相当于没有设计一样！

问题

图中依然可以看到有些问题的存在，就是更改，在设计时由于不能把信息提供的准确，而最终导致终稿与实现的还是有差异，不要小看这一点点差异，对于精益求精的我们来说，是非常难以忍受的，因为很可能这样就没有辅助色，或者没有了中灰色！或者由于格的间距发生变化，留白就会了现差异，这就严重的影响了视觉效果。

在现在来说，在设计之初提供的东西非常有限，都喜欢做完后再添加东西。这点要在平时尽量的去灌输思想，并且在实践中让大家更默契才能减少问题的发生。优质的产品是源于团队的默契！

（由于XP对字体的渲染与Win7相差比较大，所以在XP下不开户ClearType，只能保证80%的相似度。）

后计

设计一定要将他完美的实现，实现一定要更精确！

所有简单的事情，把它做的精细就是完美。

有相关问题欢迎与我讨论联系方式

YSjia

也许这些文章您也感兴趣:

• 前端开发手册之设计篇
• 商业用图图库，包括一些免费的图库
• 世界500强牛企英语面试精彩问答

由于客观的限制条件1.显示器 2.浏览器 3.现代技术的存在所以你必须去迎合这个时代网页设计所具有的特殊情况。

而此篇文章，不是教你如何去做网页设计，而是从合作的角度对分析你在前端开发中的角色。

在充分理解需求之后，完成设计稿。在完成设计稿后，并不是设计师的任务终结（如何去与需求人员交涉自己去搞定，这里咱不谈）！下一步，你需要做的就是把你的设计移交到网页重构师（搭建HTML与CSS的）帮你去实现。

而在这之前，你还有几样工作去做：

详细标注你的设计稿

这是一件可以说“繁琐”的过程，因为你也许对这些已经了如指掌，但是并非所有人由其是你下一步合作的人都明白。所以耐心的标注你的细节是非常重要的。由其是字体、字号与颜色值等。

进行简单的描述

网页设计与广告媒体的设计的不同之处，就是在于其精细度。又因为在不同浏览器下字体解析会有差别，所以这个精细是有一个范围值的。

简单的计算

这里大家可能注意到了，图片框为什么是99px呢？

99 = 90+3+4+2

width = image width + padding-left + padding-right + border

为什么不是一个双数呢？

我们来看，在整体宽度为960的情况下，想要产品得到最好的展示，而又不能太挤（同时要考虑文字）

这样算下来就是：960 = 52*7 + 99*6 +2

要注意这里的图片与图片之间的间距是双数，主要是为方便padding的拆分。

所以在满足整体宽度的同时也需要对其进行一番计算这样前端开发人员在制作时才能更省时间，更快速。同时也是最大的限度保证你的设计稿与制作出来的产品Pixel Perfect！

在设计的时候需要最大限度的保证可行性，因为一但返工，这就不是一个人的事，所以在把自己应该做好的事情做完，在合作中减少摩擦。

技巧：善于应用切片或者辅助线等（包括置入比例标记与标尺）计算工具可以事半功倍！

上图已经是分割的非常精细，包括column width与padding都已经划分完，平时设计时如果非特殊情况，最后这一步设计师应该是可以选择性的制作，重构师也不能太懒了吧，总得做点东西吧，哈哈。

这里推荐一款度量软件，可以快速的度量间距，虽然功能还是很有限，但是相信作者会不断的完善，点击查看。

虽然上面会耗费很多时间，但是你会发现效果也是很明显。就像写开发文档一样，得到好处不是你一个人的，而是大家的！

相信你会找到合适你自己情况的合作方法。

也许这些文章您也感兴趣:

• Perfect Pixels
• 微型设计专用工具Dorado试用
• 前端开发手册之需求分析
• GlobalMarket Web Design 2011
• 微言重听之美工刀

这里所提到的只是涉及到与其他领域（设计与制作）密切相关的问题，绝对不是一篇教程教你怎么去做需求分析，请大家注意。

不知道想要什么

有时经常接到的命令就是：先做吧，做完看看能放啥放点啥。（不能描绘自己的思想）

这样的命令到设计师简直就是一头雾水，正所谓巧妇难为无米之炊，这样模棱两可的说法一点信息含量都没有是无从下手的。更不要说是做设计。

按XXX的样子做出来就行（崇洋媚外形）

这应用也是最常用的说法，对自己的需求不理解，不知道我们现在到底需要什么。设计师按XXX的样子做出来后，发现填入自己的数据根本不着调！为什么呢？就好像不知道自己的脚多大号，然后指着旁边帅哥的脚对着售货员说：就要他那对鞋。结果拿来自己不但大小不合适，连款式也不合适。这样的作品出来设计师做出来不爽，提需求的人不爽，拿出去别人更不爽。

我觉得用红色会很强眼（幻想形）

经常接到任务是没有文档或者是文档不全的，然后做出来后发现不是当初想要的，抓住设计师一顿狂改。

“这个再加一张图片，要大一点的，突出气势；然后加一张图片，突出场面宏大；再加些人… …”这样流水账一样的描述相信当场已经崩溃的N多次。

这是需求人员与设计师沟通的一个瓶颈，这个瓶颈主要体现在需求人员对文字把握能力太弱，不善于总结，更不能对整体进行概括。造成给设计师没有一个完整的思路与创意模式。更无法对这样的流水帐进行创作。

设计师需要什么

设计师往往需要的是更清晰的思路，他需要知道这是干什么的、用在哪里的（促销或说明页）、需要有哪些注意的（图片的版权与其相应表达的意思，这个意思不怕你多，但是一定要精炼主次分明）还有一点很重要，对文案的理解（文字排版需要）与字数的范围（宽与高）

让其他人理解你的思想是非常重要的，由其对于团队合作来说！

自己的事要自己解决

不要忘记分析二字，刚才上面提出的情景都是只提出需求，而根本找不到分析在哪里。暂且不说什么数据分析、用户行为分析、用户统计调查与行业分析调查等。

一个最基础的就是建模，参加过数学建模的同学应该了解，对于一个问题首先需要找到切入点，然后不断的去探索实验，最后用一个简单的（或复杂的）模型来说明甚至是证明你们的结论。

那需求人员用什么“建模”呢？

首先应该读一下《餐巾纸的背后》将使你的执行更有效率

然后去熟练的应用一下工具吧：

Balsamiq Mockups – 非常不错的草图工具，这就是你的纸和笔！

Axure – 如果你追求精度，这就是你的利器！

纸、笔 – 这是最简单也是最有效的工具，你肯定有！

最后参考一下我的流程：前端组需要什么 原型设计流程也许能找到适合你的方法。

以上的方法有一个要注意的，就是不要把画出来的草图当作设计稿来做，这仅仅是草图即使你使用Axure做出来的高精度也是一个草图而以，这仅仅是让你和你的伙伴思路更清晰的工具，不是设计指导！

最后还有一点需要注意，千万不要盲目的去追随交互设计的概念，交互设计是没有错的，但是要符合你的情况下才使用，盲目的跟随往往令你陷入困境甚至是失败。基础才是重要的：交互设计？文字编辑？

也许这些文章您也感兴趣:

• 前端开发手册之设计篇
• 微型设计专用工具Dorado试用
• Perfect Pixels
• 微言重听之美工刀
• 前端组需要什么？

同理如果你没有交互理论你就不是一个好的设计师，如果你没看过XXX交互设计的书籍你就不是一个好的设计师，如果你没听过XXX写的交互理论你就不是一个好的设计师，如果你没画过XXX图你就不是好的设计师！

在N多年前，人们是怎么过来的？在没有交互设计之前都是原始社会吗？没有交互设计之前就没有好产品吗？令人崩溃的想法。

做为一名设计师很多事情只有经历过才知道，也只有经历过才懂得。不是因为一个按钮设计的成功你的产品就是成功的，也不是因为你的流程顺畅你的产品就是成功的，当被浮华的表面想象所迷惑时是不可能出现好的产品的。

Dieter Rams是最有代表性的工业设计师，有把设计当成道德追求的偏激取向，其10大设计准则也成为一个好的设计的标准。

Rams是一个信仰“少就是好”的人。在极简的外表下却蕴含着一个最基础的东西“实用”！而这些正是我们现在交互设计里面所缺少的精髓！

大量的人员投入的同时却忽略了对文字编辑的加强，很多词用的跟本词不达意，这样再好的设计能做到指引用户吗？再优化的流程设计能吸引用户吗？

一个时期被炒的过热的概念，但是在最顶端的人却没有时间了解基础，直接从巨人的肩膀上起来，还是养分不足。

百变不离其宗！一棵大树没有根基，而枝繁叶茂这棵树迟早都会死的，因为养分供给不足。

也许这些文章您也感兴趣:

• 这一段话说出了多少人的心声啊！内牛满面！！！
• 前端开发手册之需求分析
• GlobalMarket Web Design 2011
• GlobalMarket.com设计稿
• GUI进化史

但是很可惜，我用Gmail不支持此功能，非常痛苦。而转用QQMail却支持良好，而且速度很快，这不得不说QQMail做的更符合我的需求，现在用QQMail的次数也越来越多。

Gmail

不能直接C+V，所有浏览器都试过了。

但是Gmail有很多第三方的存储软件比如说：http://picturepaste.com/

这是一个桌面软件，原理就是上传到网上的空间，然后再连接回Gmail内，感觉还是麻烦许多。

QQMail

Chrome

在Chrome下是不支持粘贴图片的，但是有个提示，挺不错。

Firefox

Firefox是我最常用的浏览器，当粘贴图片时会有与IE一样的提示框，然后按步安装完成后，就可以粘贴图片了。

IE

一进入IE后立刻提示安装插件

当然如果不按的话当C+V时会出现提示框

使用方法

使用方法非常简单，应该说这个习惯就是为了QQ的用户而制定的，只要截图，然后在写信区域内粘贴图片，就会显示上传图片中

完成，然后按自己的需要排版

总结

QQMail这一功能应该说就是为了迎合QQ用户的使用习惯，但是这一功能的确是非常方便，可以极大的提高写邮件的速度。当然首先你要习惯截图。

以前真的很少用QQMail，但是现在发现QQMail的某些细节之处做的的确不错，由其是与QQ的结合程度，让写邮件就写发QQ消息一样简单方便。这也许就是QQMail的巨大优势吧。同时是不是也映射出QQ在潜移默化的改变用户使用互联网的习惯呢？

也许这些文章您也感兴趣:

• 美国彪悍摄影师拍摄极端天气“奇观”(图)
• 什么是像素图
• 解决WordPress Window主机无法接收Email
• 领先五年的迷思
• 2009地球日-40幅震撼图片

原文链接：http://piglili.blogbus.com/logs/77069181.html

Facebook的产品设计经理 Adam Mosseri最近做了一个非常棒的演讲： Data informed, not data driven（数据启示，而非驱动）

演讲以Facebook如何利用数据指导产品设计为主线，还涉及到Facebook的产品设计团队架构、不少的设计案例，以及Facebook是如何做产品设计决策等。 本文将其内容以译介形式总结如下（意译非翻译）。

1. 小而精的产品设计团队

“ It’s important to understand that, at Facebook, we believe in particularly small teams. ”
（有一点需要被清楚认识的是，在Facebook，我们特别认可小团队）

Facebook的产品设计团队通常只有6、7人，因为他们认为这个人数最高效率，且团队拥有的产品决策权很高，架构扁平( flat decision-making structure )，有的决策可以直接到CEO那里待通过。

一个产品设计团队的结构通常是这样的：

• 一名设计师，负责交互、视觉，产品战略(product strategy)，甚至一点前端
• 一名用户研究员。两年前，Facebook只有为数较少的研究员，而且只负责大项目，如今，随着对于定性研究的重视逐步增加，基本上每个团队都配一名。
• 一至四个工程师。
• 一个项目经理(PM)，项目经理通常相当于团队中的迷你CEO，需要对产品负责。不仅要保证项目的按时完成、资源协调，还要保证产品质量。

产品 设计团队之上，会有一个经理负责统筹管理。演讲者本人就担任这一职位，他负责着九个产品设计团队。另外，有专门的20人数据团队，一半是工程师，一半是数据分析专家。

2. Facebook如何利用数据

“ Data helps us understand how users use the product, which then in turn helps us understand how to optimize the product. ”
（数据帮助我们了解用户如何使用我们的产品，从而帮助我们更好地优化产品）

Facebook每天会采集到4TB的用户行为数据，这些数据能指导设计持续优化。例如 通过瀑布式分析、追踪交互步骤的转化/流失率，大量的A/B testing，观测行为使用模式 ， 优化界面交互和操作流。

例1：照片上传器的改造

在新照片上传器刚上线时，有85%的用户每次只上传一张照片。针对这一痛点，对界面进行了优化，在用户选中一张照片后浮出了一个上传tips，虽然有点“扰民”，但结果数据每次只上传一张照片的用户数降到40%，平均每次上传数从3上升到11.

同样地，通过数据他们发现，用户在周日量达到平时的150%，这种行为模式的识别也为设计带来不少启示。

例2：What’s on your mind的位移

在推出Question这个产品后，原来的What’s on your mind需要调整位置。于是他们使用A/B testing的方式测试了 8 个设计版本，但每个版本对于核心指标的影响都不具有统计意义上的差异，所以最终他们选择了最简洁的一个方案。

例3：注销页的改造

除了瀑布式的分析，数据还会用于回溯性式的分析、优化一些小页面。例如一个设计师发起了注销页的改造，他思考的是如何在用户即将离开之时将其挽回。最终他通过一种情感化设计改造了这个页面（图1），成功将注销率降低了7%，这对于Facebook的用户量来讲是非常了不起的数字（当时Facebook有7千万用户）。

3. 对数据过度利用的警惕

“…at Facebook, in product – we call product "product management and product design" – that there’s a healthy skepticism of being overly data driven ”
演讲者提到数据怀疑论的三个原因：

一组数据指标很难完整地代表你所重视的价值

影响产品决策的因素很多，除了定量数据，还有定性数据。Facebook的用户研究员会做大量定性研究，如可用性测试、眼动测试等。另外还有战略因素，用户需求，竞争产品，商业利益因素。

过度依赖于数据，可能导致“微优化”或“局部最大化”

对数据的变化过度敏感，可能导致所谓的“微优化”(micro-optimization)，即过度着重、不断追求某一项指标的提升，而忽略了其他因素。尤其当Facebook规模不断扩大，各个团队更专一于自己的产品，就可能导致各自只从自己的指标出发，使得整体上出现冲突，没有了全局观。

例如 ，应用菜单的设计几经周折，位置从左边栏换到顶部，又换到底部，由于流量不见大增，还曾考虑使用蓝色大按钮的方案。虽然流量提高了5倍，但由于设计师自己都觉得很难接受，这个方案最终没有被发布。无论如何，直到一年后他们才发现，尽管朝着提高引导到应用的流量这一指标不断优化，却出现停滞不前、达到局部最大化(local maximization)的瓶颈。最终他们成立了一个菜单项目组，推翻之前的重新开始，设计了目前的版本——而这实际上有一半回归到菜单最初的样子。

另一个例子是相片上传器。相片团队花了好几个月朝着提高上传成功率的数字优化， 虽然数字有提升 ， 但成功率已几乎稳定，不可能有什么新的变化了。如果一直围着这个指标打转，体验并不会有质的变化。

真正的创新通常会导致数据的变差 ， 但这未必是坏事
“… real innovation invariably involves disruption. And disruption is usually – involves a dip in metrics ”

Facebook 一个核心价值在于打破，甚至扰乱。这往往导致某些指标变差，但这也是创新的意义所在。他们曾经有不少无视民意无视数据的革新，比如新首页，就完全不是根据数据来的。当然，他们的革新有的成功（News Feed和Mini Feed），有的失败（如Beacon，将你在外站行为导入到FB的功能）。失败了，只要理解失败、承认失败，就能继续向前。不可能因为害怕数据变差而拒绝变革。但是， 变革有时候会因为扰乱用户而造成他们的反感，坚持变革，不代表不聆听。如演讲者提到他最喜欢的Facebook group是“我不由自主地讨厌新的Facebook首页”。需要学会如何更好地向用户传达革新的目的和意义。
4. 最大的冒险在于不敢冒险

“For us, the greatest risk is really taking no risk at all… at the end of the day we make decisions based on common sense, on interests, on strategic interests. And we use data. We acknowledge it’s important, but it’s really just a small piece of the pie. ”
（ 对我们而言，最大的冒险在于不敢冒险……很多时候，我们最终依靠常识、洞见、战略意义做决策。我们使用数据，数据很重要，但这只是大饼的一小块）

也许这些文章您也感兴趣:

• Facebook 的工程师文化
• TWO IT-Services Web Design
• [转]让开发也懂前端
• GlobalMarket Web Design 2011
• GlobalMarket.com设计稿

在选卡的做法上却有小小差别。

有延时还是没有延时？

QQ弹窗

这个相信是大家最常见的，上面大量的应用了选卡，而且最近变成了又双层的。

当鼠标移上时会立即转换，没有延迟。但是这种做法经常使我们要小心翼翼。

但是事实上鼠标通用是乱飞的，在屏幕上没有一定的规律，而且速度很快，这样会造成经常不能准确点到自己想要的新闻，通常都会碰到选卡，而它则会瞬间切换。

个人还是喜欢以前能点击的时代。

MSN弹窗

MSN做法有少少差别，鼠标在选卡内停留不到1秒时切换（有少少延迟），这样做法可以提高精准度，使用用户“所见即所得”但是又不会造成太大的干扰。

延迟多久才好?

MSN

新的MSN.com改版后，也是大量应用了选卡

同样选用延迟触发，延迟时间大约为1秒。

这种这大量选卡，1秒的时间还是非常合理，因为你不知道鼠标什么时候就飞到哪个选卡上。

Yahoo

我觉得Yahoo做选卡一直比较好，这个新闻栏的选卡同样有一定的延迟，鼠标快速掠过是不会快速切换，但是Yahoo在延迟时间上掌握的更精准（小于800ms），好像他知道你什么时候要切换！

这选卡上是需要点击才触发的

上面选卡的点击触发，同时也是因为其侧栏拥有高触发频率（即时触发），这样避免了鼠标快速移动而造成不必要的触发事件，使整个页面跳动太大。

小结

选卡的应用，可以另页面展示更多的信息，扩大信息量。并且增加信息堆放的合理性。

然而大量的信息同样纯在着相互干扰，弄不好会使用户比较茫然。大量快速切换也会造成一定的心理负担。

一个网站不是独立的一个控件组成的，所以每个控件之间有着必然的联系，只有符合整体信息编排，使用户感友好就是好的选卡，延迟与否只是达到目的的一个效果。

魔兽争霸是一款非常出色的游戏，自己已经玩了四五年，但是依然热衷。

魔兽争霸不仅仅视觉效果与其性能优越，其中还一些经典的交互设计，首先从选择（主要针对建筑）来说起。

人物优先级最高，不论是农民伯伯还是英雄（有关人物以后再谈）。

角度不同，选择不同（针对建筑）

左上到右下，优先选择左上建筑（选中祭坛）

左下到右上选择，优先左下（选中兵营）。

同理，优先选中起始象限里的建筑。

然而在同一象限里做两次选择，则会优先选中象限中其他建筑，中轴线左右偏移。

右上到左下第一次选择，选择地洞

右上到左下第二次选择，选择了大厅。

多选

起始点为第四象限，所以优先会选择地洞。然后向第二象限移动时四方选择框会选中第一象限内的另一个地洞，结束选择时会选择两个地洞。

同理，如下会选择两个BE（兽栏）

跟上面的选择规律一样，同一方向选择两次的话，第二次会选中祭坛。

这里有一点，正在建造的建筑与已经完成的建筑，虽然是同一个，但是在未完成时，是不会选中两个。

对单个建筑选择

当鼠标移到某个建筑范围内时，触发当前建筑的查看状态，这里暴雪的范围是某个建筑的边缘，不是发光的圈，而是建筑的边有颜色的实体！

不触发

触发，注意鼠标位置。

选择框选择建筑，触发

扩大选框，建筑没有触发！

选择其他建筑。

但是当选择框偏向左时，建筑又被触发。

这样的一个小细节，会让操作者更轻松，当然高手一般都是点击或者是快捷键。

但是这样的细节在会让在游戏中的你有更多的选择，百忙之中也有错手之时。

虽然这些细节平时我们可能并不在意，但是这对于初学者或者资深玩家来说，都是非常好的体验。

电脑会听从你的指令行事，它好像知道你要选择什么！

也许这些文章您也感兴趣:

• 交互设计？文字编辑？
• GlobalMarket Web Design 2011
• GlobalMarket.com设计稿
• 互动对于新的互联网至关重要
• Perfect Pixels

而如今的Grid在网页上出现也是为了规范性？

难道人云亦云，大家说好才是真的好？

Grid的分法我就不详细的说明了，在这里讨论一下Web Grid System可以有哪些重要的用途。

一开始我觉得Grid只是一快事构建与多人协助所用的方法，只要开发人员都应用统一的标准，可以很好的控制代码统一，易于维护。

但是实际应用中发现不仅要追求“黄金分割”这样以美学为标准的Grid，其实Grid System还有一个更重要的用途，可以统一页面之间广告的展示。

我们都知道，在网页上经常会因为不同的大小，所以经常改变广告位，这对于现在这种没有Web AD标准来说，非常头痛。

而在一个网站内部来说同样存在这个问题，一个大型网站必然有很多种不同布局的页面，这些面会被不同的部门所应用，但是里面的广告内部有时几乎不变或穿插很大。为了以一种最好的广告尺寸来应对多页面布局的方法—Grid System。

Yahoo ad流行的尺寸

在设计网站之-初，根据原型业务部门的反馈并且与设计师等沟通后，需要对网站页面进行统计与规划，布局由为重要，这将是以后网站可持续发展的一个根基。

可以想象一个大型网站，其广告数量是相当的惊人的，你说可以改，没问题，但是谁能去改几万张的图片！

在这里采用了20-10-33的栅格，选取几种主要的布局分别为：

200-770

440-530

320-650

这三种“二栏”布局又都可以拆分为

200-440-320

再加上嵌套的布局，可以很达到10多种，基本可以按需分配。

而其中关键的“广告位”则可以选取

770（黄金广告位）

200-200（方块）

440-120

300-250

这些广告（除黄金广告）都可以做到页面之间的通用性，展示的频率增加了，那效益自然要增加。

这里值得一提的是黄金广告位，为什么这里不设计为分两栏？因为黄金广告位的目的是为了更大的展示，而这个页面，应该是访问的最多（首页与SEO方向）所以才能称为黄金，看着舒服买家买的也爽啊~^_^~哈哈

Yahoo的前端工程师Nate Koechley说过前端工程师是企业的价值的体现，将价值最大化。

题外话：

理解是一个团队的最关键一点，大家之间因为专业的差异会变得陌生，分工越细使得分化越利害，这不是一个良好的团队。

在理解业务与开发人员之间的问题之后，需要大家都必须了解对方的角色，当然这需要时间的考验。

不过，对于小型网站来说其实并不需要这么复杂，这样会增加开发成本，但是对于大型网站，其页面不尽相同数量之多，开发人员也多，这样一个协调的“标准”是必须的，只有这样才能保证设计的质量，如果大家都可以熟练的应用那么在合作之间可以减少很多不必要的摩擦，使得开发的过程变成一个快乐的过程。

也许这些文章您也感兴趣:

• 前端MVC – PSD设计篇
• 前端开发常见问题（非js）与解决方案

如果熟练应用的话，可以在很短的时间内把业务思路整理清晰。

为什么需要原型？

我认为这是个非常有趣的问题，原型的开发无疑要加长整体的开发时间，并且在这段开发时间内很不稳定，会经常改动，变动之大，可能几次需要从头再来。

原型可以使业务流更加紧凑，更容易发现业务中的遗漏，可以减轻开发的迭代次数，减少开发与测试时间，更可以减少版本迭代数这个比较关键，是保证质量的前提（向老板汇报时不希望总是Bug吧！）

如何应用原型？（原型的开发步骤）

制作原型的工具很多，Axure只是其中之一，Microsoft Expression Blend 3、Visio与Balsamiq Mockups甚至是Word与PPT等，太多了。

但是我觉得Axure并不适用于原型的第一阶段。其原因在于操作Axure绝对比拿一支笔与一张纸要费事的多的多！！！

第一阶段：整理需求

首先我们需要一个比较清晰的思路（功能），并对其进行总结与规划。

第二阶段：数据可视化

工具：纸笔或Balsamiq Mockups等。

要求：能快速描绘与设计出需求方提出的基本意思，整理并图形化。

简单的草图可以让思维快速变换，并且印象深刻。非常适合在前期头脑风暴与第一期草图（内部供稿）使用。

在这个期间需要交互人员不断的与用户或需求部门的相关人员（统称超级用户super user）进行迭代并确认相应的模块是否已经基本健全，并且有预留一定的宽展性。

经过不交互人员与超级用户（super user）不断的交流后，一个草稿就基本完成。

在这里值得一提的是Microsoft Expression Blend 3用来制作前期交互草稿非常棒

这个SketchFlow Map对整理整个结构有非常好的作用：

有时间还要好好再研究一下~

第三阶段：高精原型制件（业务测试）

已经有前面的简单可视化分析，进一步就可以制作出具有高交互与精度的原型来让一些用户（user）测试一下。进而再收集数据确定业务流程。

由Axure制作的原型可以达到比较高的仿真度，这样可以让用户有比较良好的体验，这些收集得来的数据可以再一步分析，精确业务流程并与对其进行合理的简化与优化。达到真正为用户着想的作法。

最后一步：迭代（基本完成）

以上所有的参与人员都是由前端组成员包括UI设计师、交互设计师等所有组员完成的成果，其中全程合作将是保证整个原型开发的顺利进行的关键。由其是交互人员与超级用户之间的交流更是重中之重，是原型成败的关键！

至此原型的开发应该可以告一段落。整个开发可以画做这么一张图：

是一个不折不扣的循环式开发。

不论对于Server端开发还是对Font End开发都是非常有好处的，实现一种理论上的MVC开发。但是其时间也是比较长，所以不是适合所有项目，一些小型项目或者对业务与其他方面都非常熟悉并团队较小每个人对业务已经可以达到行云流水一般，直接进入敏捷（XP）开发会更有效率。

欢迎大家指正与交流！

Y.Jiajia’s email: will.yuan[a]ymail.com

也许这些文章您也感兴趣:

• 前端开发手册之需求分析
• 互动对于新的互联网至关重要
• javascript 函数备忘 – indexOf
• 开发流程中的可用性之一
• 开发流程中的可用性之二