网站设计规范分享及探讨 - UCD大社区

需求 & 设计

saidy — 2010-09-08 11:06:25

需求与设计，往往是一个项目实施过程中，争议最大的两个环节。需求总是提得很突然，而且变更太频繁，设计没有理解需求要领，产出没有时效性，双方沟通太困难等等问题。究竟是谁的过错呢？我一直认为，一个巴掌是拍不响的！互相的体谅、总结经验和不断学习、面对现状、解决问题，才是最重要的。

《需求与设计》主要是针对友商网这两年来“专题需求”的发展情况，做的一个小小总结。希望也能给到大家一些或多或少的感悟。

《需求与设计》点击下载：need-design（PPS）

基于Axure的PRD写作思考

kent.zhu — 2010-08-11 08:56:47

本文想说的事情是，那个叫PRD文档的家伙只是个称呼而已，PRD的问题不在于如何写而在于如何被传递与执行。这里简单介绍一下我基于axure rp的一种新的PRD写法。（友情提醒：从来不用axure，认为他笨重无比的人请路过。）

从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。

长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、….

Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！

个人认为，一个PRD文档需要包含以下的内容：

1、概述
1.1、名词说明：文档中涉及到的名词
1.2、产品概述及目标
1.3、产品风险预估
1.4、产品开发进度：产品开发阶段及责任人与时间节点
2、使用者需求
2.1、使用者需求描述：定义用户是谁
2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分）
2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化
3、功能需求
3.1、功能总览
3.2功能需求分解：界面分解及交互说明和用例
4、非功能需求：与该产品相关联的辅助产品等
5、上下线需求：产品的生命周期
6、运营计划：产品的上线后的反馈与改进

整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子：

在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件）

同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。

1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。

2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示）

3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。

4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。

下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分）

Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、….
A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题

Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？
A:没人说不可以这么玩。还是那句话，个人习惯。

Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？
A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。

Q：按照你的写法Axure好像是万能的了？
A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。

既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。

文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。

浅谈交互设计规范

Jason Liu — 2010-08-09 22:52:06

当产品规模大了之后就需要多个产品设计师协作完成整个产品，由于不同产品设计师之间的设计理念、设计方法、设计习惯的不同，协作完成的产品往往会导致产品一致性差，质量参差不齐。

这个时候会需要一份交互设计规范来规范和指导产品设计，从而保证产品设计的一致性，提升整体产品质量。

本文就来说一说交互设计规范应该包含的一些内容：

一、页面信息规范

页面信息规范主要指页面的静态信息应该遵循的规则，包括：

1.标题规范

用于规定整个产品中所有不同层级不同功能的页面应该使用的标题的规则。

2.新窗口链接规范

用于规定页面链接是采用新窗口打开还是本窗口打开的规则。

3.图片规范

用于规定图片信息是否带有alt title值，这些值又取自那里。

二、交互信息规范

交互提示规范主要用于规定在交互过程中交互的方式及其信息提示，包括：

1.预先信息提示

所有交互进行前需要提供充分给用户的预先应该知道的提示信息。

a.表单提交类

表单提交的步骤，每个表单项的要求需要给出提示信息。（如密码要多少多少位。搜索框鼓励输入什么内容。）

b.谨慎类操作

一个操作对用户来说需要慎重操作的。如扣除金币等。需要预先提示。（如：扣除金币的操作需要预先提示扣除金币数目，以及当前金币是否足够。等等。）

c.差异化规则

当一个功能的规则与用户习惯的规则具有一定的差异或比较复杂时，需要给出提示。或者给出帮助链接。

2、操作信息提示

所有交互进行中需要提供操作相关的提示。

a.操作确认提示

一个操作涉及数据删除，等需要谨慎操作的操作需要给出删除确认提示框。

b.操作错误提示

当用户的操作不符合操作的规则，需要给出操作提示。（如评论字数为0或超过限制字数，搜索框未输入内容时提交）

3、结果信息提示

交互进行后给出结果反馈是应该给出适当的提示

a.查询类结果

任何信息列表、查询结果，当对应信息无结果的时候需要给出有无结果状态提示。

b.保存类结果

一个表单是用户提交保存数据的。如设置个人资料。提交保存后需要给出提示。成功绿色、失败红色、普通灰色。

c.附加类结果

一个表单是对其他数据进行附加的，如评论等。提交成功后应直接跳转到操作产生的结果展示部分。（如提交评论后应该直接展示给用户他提交的评论）

三、通用控件规范

当有一些功能会被多个模块复用的时候（如标准评论框、标准好友选择器等），需要把这些功能提炼出来设计成通

用控件被多个模块共用。

有了页面信息规范、交互信息规范、通用控件规范就能保证页面信息的一致、交互方式及提示的一致、通用功能模块一致。从而保证产品的一致性，并提高产品质量。

先写这些欢迎补充。

产品UI设计流程

小威 — 2010-08-10 22:25:03

本篇是为杰妞同学写的产品UI设计流程，其实对于产品UI设计流程特别是对于大型的互联网公司的要求特别高，经过不断的挑“刺”后才得以面世，得到的设计稿件完全与最初版本不同，商业类的产品会让产品和商业气息相兼容，与UI设计师的最初思想完全不同，而UI设计师会将自己的风格带到产品中来，会给产品灌输一种“性格”，该产品特有的“性格”，一般公司只将把UI设计流程分为四个简单的阶段：分析、设计、配合、验证。

1、分析阶段
需求分析、用户场景模拟、竞品分析（聆听用户心声）。
需求分析：对于一个产品来说，必然有对用户需求的分析内容，更多的是从MRD与PRD获得，或者从产品需求评审会议上得到需求分析的内容，当然可以直接与产品经理交流获得相关产品需求。如果说设计原则是所有设计的出发点的话，那么用户需求就是本次设计的出发点。
用户场景模拟：好的设计建立在对用户深刻了解之上。因此用户使用场景分析就很重要，了解产品的现有交互以及用户使用产品习惯等，但是设计人员在分析的时候一定要站在用户角度思考：如果我是用户，这里我会需要什么。
竞品分析（聆听用户心声）：竞争产品能够上市并且被UI设计者知道，必然有其长处。这就是所谓三人行必有我师的意思。每个设计者的思维都有局限性，看到别人的设计会有触类旁通的好处。当市场上存在竞品时，去听听用户的评论，哪怕是骂声都好，别沉迷于自己的设计中，让真正的用户说话。

输入物：MRD、PRD、市场需求文档、市场调查报告、竞品分析文档（或其一或全部）

输出物：设计初稿（或许只是几个简单的界面）

2、设计阶段
设计方法采用面向场景、面向事件驱动和面向对象的设计方法。面向场景是针对该产品使用场所等模拟，模拟用户在多种情况下产品使用的模拟。面向事件驱动则是对产品响应与触发事件的设计，一个提示框，一个提交按钮……这类都是对事件驱动的设计。面向对象，产品面向的用户不同对于产品的设计要求不同，不同年龄层的用户对于产品的要求不同，产品的用户定位将对UI设计师影响因素。

输入物：交互文档（高保真原型）

输出物：设计终稿（所有的设计稿）

3、配合
UI设计师交出产品设计图时，更多的配合开发人员、测试人员进行截图配合。配合开发人员对于PSD格式的图片切图操作，对于不同的开发人员的要求，切图方式也有不同，UI设计师需配合相关的开发人员进行最适合的切图配合。

输入物：设计终稿

输出物：设计修改稿（设计稿切片）

4、验证
产品出来后，UI设计师需对产品的效果进行验证，与当初设计产品时的想法是否一致，是否可用，用户是否接受，以及与需求是否一致。都需要UI设计师验证，UI设计师是将产品需求用图片展现给用户最直接的经手人，对于产品的理解会更加深刻。

输入物：产品

输出物：产品（面向用户最终版本）

产品UI设计中夹杂着许多设计原则要求，统一公司UI设计流程，使UI设计师参与到产品设计整个环节中来，对产品的易用性进行全流程负责，使UI设计的流程规范化，保证UI设计流程的可操作性。UI设计师应该分析公司产品的特点，制定符合产品生命周期的UI设计流程。每个产品的生命周期中，UI设计师应该严格按照流程，完成每个环节的职责，确保流程准确有效的得到执行，从而提高产品的可用性，提升产品质量。

建议：UI设计师有自己的风格，同样有自己的个性，建议在时间充裕时，UI设计师做二套设计稿，一套适合企业的，一套适合自己的，当老板对企业那套设计不满意时，将适合自己的一套展示给用户，或许会有不同的效果哦！

相关话题：网站设计规范分享及探讨源地址：http://www.537520.com/?p=650

广州UCD书友会21期看法

userhabit — 2010-07-23 11:05:38

本博客参加了2010年7月18日在广州市网易大厦一楼沉毅会议厅举办的广州UCD书友会。这期书友会的内容有：

1. 网易用户体验设计中心高级设计师杨烽亮给大家分享了《网易网站及相关产品设计规范》；
2. 网易用户体验设计中心高级设计师谢守熠给大家分享了《网易FLASH设计规范》；

本人因为第一次参加这种活动，所以并没有做好充分的准备及发言，只是针对活动形式提了一些建议性的观点。

不过，亦有收获。

针对《网易网站及相关产品设计规范》的想法：

各大门户网站都开始了自己的规范改版，网易也不例外。从网易高级设计师给大家展示的一些材料上来看，网易在加强用户对页面的“留意”方面上下了不少功夫，而且很明确地分析了用户的浏览习惯，并根据浏览习惯调整了页面的设计，布局等等。这些调整已经逐渐开始应用，相信对网易的规范性建设非常有利。

设计师特别提到了用户在浏览门户首页的时候有一个“F”型的浏览习惯，那就是在载入页面后，前面的字符行会左右都看，但是看到下面，就会只看左边的了。于是网易根据用户的这种习惯，特地把下面的字符行的重点（网易是分三栏，于是乎把左边那栏放一些比较不重要的东西，中间栏放置重要的新闻及链接）向右偏移了，从而增加了用户对于页面的浏览重点有平均。这对于用户本身及网站本身都是有好处的。

针对《网易FLASH设计规范》的看法：

设计师首先说明了FLASH的应用条件，他说，一般的广告还是以图片为主。我认可这种观点，因为图片载入方便，比较不容易出错，占用系统资源也小。后来他提到了微软新技术 Silverlight 与 FLASH 的对比。他接触 Silverlight 比较早，是在2007年，在当时 Silverlight 的技术还尚不成熟。在他看来，在当前，FLASH 还是相对Silverlight 较有优势。

不过我认为，新技术Silverlight 除了要装插件以外，它的体验也是不错的，腾讯QQ的产品“滔滔”中就有一项Silverlight 的应用，我在操作上感觉它非常流畅，不会有 FLASH 的响应问题，操作的感觉有点类似 js。希望这项新的技术可以继续改进发展。同时也希望 FLASH 也能继续优化自身。

7月杭州.UCD书友会后记

simx.leizi@gmail.com(稻草) — 2010-07-19 16:27:05

7月杭州.UCD书友会话题：网站设计规范分享及探讨

老地方，老朋友，聊着同一个话题.
可惜今天@Betacafe的网络太杯具了，没能上twitter,微博与其它兄弟城市互动。

一些小的总结：
什么时候应该开始有规范？
1. 不宜为了规范而规范，太早的定规范，应该要早些做积累
2. 不宜太急，为了规范而规范，做到团队内的经验传承。

制定规范的目的是？
1. 规范设计的基本准则；
2 .为了团队，跨部门的高效的沟通；
3. 方便以后的维护；
4. 团队经验的传承。

哪些规范是必要的？
1. 公司，产品的VI，视觉规范； (标准 )
2. 一些经过几代人的经验总结； (推荐)
3. 一些业界比较不错的设计解决方案。(参考)

等等等等.
不是说一定要有规范就好，没有规范就不好.
还是那句"平衡"，
Do things right 和 Doing right things

上图

认真

某XX哥的虾米

故事二...

Y笑

上PPT

Flash动画

在线播放

不以规矩不成方圆（UCD广州书友会第21期总结）

胡晓 — 2010-07-19 16:25:35

古人云：“不以规矩不成方圆”，这“规矩”就是规范。“木受绳则直”，人也一样，生活中的各种规范不断地提醒我们，指导我们，纠正我们。在网站迅速的发展，规模一天比一天大，频道越来越多，子网站、子品牌越来越多、团队日益庞大、跨部门越来越多的时候，在设计上面会出现很多这样的现象，比如：文案、标识、LOGO、图片尺寸、按钮、ICO大小、颜色等等到处出现不统一，带来的问题是出品效率低、沟通成本高、重复返工多、作品质量不高、品牌形象受损、商业利益受损。

首先，本期书友会再次出现“爆棚”。报名40人，实际上来了50多个，门口都站满人，无法打开了。今天的嘉宾准备内容很有分量：

网易用户体验设计中心高级设计师杨烽亮给大家分享了《网易网站及相关产品设计规范》；
网易用户体验设计中心高级设计师谢守熠给大家分享了《网易FLASH设计规范》；

说到规范的梳理、定制，估计很多公司和朋友有有做过。制定规范容易，不过如何制定适合自己公司的规范，并按照要求去执行好，估计并不是每个童鞋都能做好的。如同“道理是这样，但事实结果是难以想象的”。如何制定规范，这只是有了需求之后的一个方法问题，是比较容易解决的。我反而比较倾向和大家多探讨如何能够执行好的问题。比如：

方案制定应该从那些方面去考虑执行层面的问题？
方案制定好后，但业务部门提出质疑，不情愿，并抗拒执行怎么办？
如何保证让大家都理解这个规范，并执行这个规范？
怎么样的方案可以保证规范可以一直优化下去？
怎么样提高规范在公司全体成员心中的认可度？

其次，书友会参与成员结构开始和以往有比较大的区别。我们将各个领域的朋友都邀请了进来，代表有如：

业界（目前为主导，都是各大企业在职员工，业界精英等）；
教育界（广美、轻工、广工等有副院长、讲师、学生等来参与）；
社会、政府（广州互联网协会等）；

最后，畅谈书友会。很多朋友都谈了自己对书友会的看法，建议，以及不解，个组织都耐心的和大家解释，并说明现有情况。我重申了书友会的组织原则，也说了一下以后的做法：

书友会不是培训、不是讲座，而是交流会，嘉宾与参与者对等。不做特殊照顾，来这的都必须是带着问题，建议、疑问、疑惑而来的，需要相互分享、畅谈。我们绝对不欢迎沉默者，希望大家会后多写博文。
书友会每月固定聚会不会对参与个人收费；
书友会以后会提高参与门槛，比如要求提前发问题列表，会上发言、提问、分享，会后写博文、心得体会等。

结尾的时候广州互联网协会秘书长周维亚老师做了一些分享，肯定了参与成员的朝气与热心、积极向上的学习、提高专业技能。同时也抛出了一个问题：“我在书友会是一个什么角色？我能为书友会做些什么？”，很令人深思，感谢周老师，我也要好好思考。

本期会后心得我最早看到是海晴的博文，一个很漂亮、很优秀的女孩，很高兴认识她。《广州UCD书友会21期 —— 又一次幸运的邂逅》

本期书友会照片：

本期更多精彩照片：
http://www.flickr.com/photos/hu_xiao/sets/72157624402804871/

现场PPT文档：

《网易网站及相关产品设计规范》杨烽亮Popout

View more presentations from top idea.

相关话题：网站设计规范分享及探讨源地址：http://hx.okvi.com/?p=1315

广州UCD书友会2010年7月话题回顾

bluesnail — 2010-07-19 16:06:55

广州UCD书友会第21期在台风“康森”过后的18号（周日）举行，这次万万没想到的是参与的人数又一次刷新了广州书友会的历史。因为话题的原因，本期来参与的人数明显上升不少，来了差不多50多号人，因为会议室只能坐下40位，所以后来的同学只能站着。

说到本期话题网站设计规范分享及探讨，对于这样的一个网站设计规范，在大互联网公司都有一套自己成熟的规范和流程。但相对于一些小的互联网公司，这方面比较欠缺或者没有。本期书友会我们请到了网易用户体验设计中心的两位高级设计师，杨烽亮和谢守熠为大家做这方面的分享。

特邀嘉宾分享环节：
1.《网易网站及相关产品设计规范》，网易用户体验设计中心高级设计师杨烽亮；

杨烽亮同学一开始就抛出为什么要做这样的一个规范的介绍，从不同的角度说明了网站统一设计规范对于产品、技术、运营的利弊。

统一整站的用户体验
更高效的合作分工
设计资源的复用性更容易

杨烽亮同学继续介绍到相关规范的内容，包括导航、页面布局、logo规格、字体格式大小、颜色、按钮、图片尺寸等等一整套的ui/vi内容。

后面提到了执行规范比制定规范难多了，除了来之内部的执行压力外、更多的是销售与网站规范的冲突。针对上诉的问题，其实从不同的角度换位思考, 所有的问题在规范的前提“有的放矢”去执行。

最后在互动提问过程中，大家都很有针对的提起问题，我们的杨烽亮同学很热心的为大家一一作答。由于本期嘉宾的ppt涉及到一个公司的部分隐私，不便于分享出来。如果想继续希望了解这方面的内容，请关注网易的杨烽亮同学。
2.《网易FLASH设计规范》，网易用户体验设计中心高级设计师谢守熠；

在这个话题的环节由于便技术一点，所以此时的活跃度比之前的要地点。但谢守熠同学做的ppt很漂亮，分享的思路很清晰。从flash 制作的技术角度介绍了规范的要点。

flash制作的场景的要领
flash多个独立动画路径定义
xml数据的格式规范
flash导出成avi/MPEG-4时的问题

与会嘉宾分享环节：

这次我们请来了很多业界的朋友，包括

周维亚老师广州互联网协会秘书长

刘毅讲师广州美术学院

胡克设计学院院长广东轻工职业技术学院

刘再行讲师广东轻工职业技术学院

他们的参与让我们有了更多的支持，他们給了我们很多的建议，同时得到他们的认可也是我们没想到的。后续我们将把我们的“设计之旅”更多的同广州的大企业结合起来，在书友会主题不变的前提下，做的更开放。

最后我们和参与的同学更多的交流起来，倾听大家对书友会的建议。大家提了不少很好的建议，同时我们也很希望书友会这个平台給到大家的时候，也需要大家的回馈。借用周维亚老师说的这句话：“我在书友会是一个什么角色？我能为书友会做些什么？”。

最后大家的合影：

产品在流程中损耗

王云 — 2010-07-19 10:35:29

一台F1 赛车由发动机、变速器、变速器换档杆、消声器、后车翼、后轮毂支驾、轮毂、油箱、车手座椅、方向盘、后视镜、刹车盘、悬架三角支架、轮胎、底盘、散热器、前轮毂支架、安全螺母、前车翼等配件组成，在一个赛季的比赛中，这些配件不断的损耗、被替换，伴随车手完成赛季比赛。

我觉得产品上线运营就像赛车一个赛季，在赛前我们要做好充分的准备，在比赛中，要不断的超越对手才能取得胜利。

如果一台F1赛车在比赛前就漏洞百出，那在开赛后它只能是一台老爷车，在维修站呆上再长的时间，它也追不上呼啸而过的其他赛车。（当然无论多好的车子在比赛中也会出状况，在维修站里花最少的时间，抢先1 秒，就会离胜利更近一些。）

开赛前的准备和测试，让赛车配备了最好、最合适的配件来达到最高的效率。那产品在上线前，它是否已经有了最好的配备？或者说它在配置过程中，是否已经有了损耗，这个损耗能否降到最低？

来看看我们的产品在上线前的流程吧。

产品经理需求调研、制作BRD——BRD评审——项目启动会——featurelist、DEMO——featurelist评审——交互、视觉设计——产品经理制作PRD——PRD评审——前端HTML ——HTML评审——技术开发——预发布——上线运营——改进

在这个流程中，损耗肯定存在，因为过程中不同的同事经手，产品经理往往注重需求是否被满足、页面大体效果及交互过程有没出现逻辑问题，可是真正涉及到页面中的布局、结构、视觉表现、对比、对齐、重复、亲密性等细节往往需要视觉设计师与前端设计师的紧密配合。

比如：

1、该模块在视觉稿中，默认2行显示，前端也实现了2行，同时在行间距、字体颜色都做到了和视觉稿的一致性。可是真正到上线运营后，2行并不能够满足运营的需求。（这个情况我们该怎么办？对，很简单，做字数限制，超出的做截断，可是要改这个需要走一遍流程，而在这之前没人晓得这里会放多少文字，以为2行都有多了）

2、列表页也同样存在这样的问题，上线前产品经理到交互再到视觉，已经把标题长度留的够长了，结果上线后用户写的标题长度超出，导致标题2行显示，其他用户反映看着就觉得特别累。（该问题在于上线前我们没有考虑在这里做字数截断，类似这种问题很常见。）另外，在上线前，HTML给到技术部。技术部忙完，测试忙完，上线了。怎么背景的灰色没了，用户大喊白背景下看我们的列表眼睛很辛苦。（技术拿着前端稿子开工的时候，把背景色遗漏了，结果技术没发现。视觉设计师根本不晓得这页面啥时候就已经在线上了。）

3、页面中任何模块的存在，其实都是有对齐的，我觉得可以理解为，X轴和Y轴注定了这个模块的坐标。1个地方没对齐都会让页面变的错乱。前端在制作HTML过程中，有时候并不知道视觉设计师在考虑位置时是依据哪个模块做的对齐，结果HTML出了问题，但是前端并没看出来。（我觉得前端HTML出来后，视觉设计师还是非常有必要跟进每一个细节）

4、产品经理拿着HTML，到技术那边，突然发现漏了个啥小东西，技术一加，其他模块一套，产品经理手一挥，完事了。上线后设计师要哭了，连对齐都没有了。

……

各种情况都有可能发生，页面从视觉稿到线上的效果，就在这个过程中慢慢损耗了，所以视觉稿往往比线上效果好很多。

以上提到的问题有的已经改进，有的已经有了更好的解决方案。

写这篇文章并不是想把责任归给谁，而是让大家反思如何提高团队的默契度，降低损耗，让我们的F1离胜利更近一些呢？

相关话题：网站设计规范分享及探讨源地址：http://blog.19ued.com/?p=962