互联网产品交互设计的相关流程是什么,最好详细一点

谈一谈互联网产品设计阶段的工作流程

关于互联网产品设计阶段的工作流程，近几年好像有了一个标准的模式，大家都按照这么一个大概的流程来工作，又好像没有标准，每个团队又不尽相同，有的简单粗暴，有的复杂细致 。之前工作过的几个东家工作流程都不是很合理，产生了很多经验教训。最近在馒头商学院回炉改造，又讲到这块，自己总结了一下感觉比较合理的工作流程，希望给一些小伙伴参考和启发。

目前大部分的公司遵循的产品设计工作流程，涵盖工作岗位从产品经理，交互设计师，用户研究员，视觉设计师，前台开发，后台开发，测试，运营等等，当然具体到每个公司的人员配置不同工作环节也会有些出入，每个环节细分起来还有很多工作。下面说下产品经理和设计师为主要执行者的工作环节，开发运营阶段就不多讨论。

一、需求分析 

需求分析是一个烧脑的工作阶段，这个阶段需要产品经理，用户研究工程师，交互设计师，甚至公司各路大佬，市场、运营等各路人马参与，做大量的研究和提炼工作。一般通过用户分析，需求整理，竞品分析，核心流程设计，技术分析，商业市场分析等这么几个步骤，最终梳理出需求规划。工作流程顺序不一定，更多的是在交叉进行。 

1、用户分析

一切产品都是建立在用户需求之上，一个产品必须能满足用户需求才有存在的价值，用户需求需要被发现和感知。规划产品时，不可绕过的第一步工作就是用户分析，用户分析其实很复杂，大公司会有专门的用户研究工程师来负责，但一般公司都是由产品经理或交互设计师来完成的，而且没有太多资源和时间，但简化的用户分析也是有用的，一般做用户分析的目的：确定目标用户，详细了解用户的目的和行为，用户的问题，用户使用场景以及当前用户问题的解决方案等等。简单有效的方法就是做几次用户访谈，通过访谈其实可以了解足够多，如果资源和条件足够，调查问卷，焦点小组都是常见的方法，如果已有用户基础，可以进行用户数据分析，精确了解用户行为，也有很多开放平台如百度指数进行数据查询。产出物有用户画像，用户故事板，用户研究报告等，不管产出什么，最重要是脑子里有清晰的目标用户形象。

2、需求整理

需求整理之前需要做需求收集，收集的方式有很多种，数据分析，思维导图梳理，用户研究，竞品分析，个人经验等等。收集一系列需求后，开始整理筛选，去掉不合理的需求后，按功能框架，用户量，使用频率，开发难度，用户习惯，商业价值，数据表现等等方面分析排序和分类，产出物一般就是需求池，需求池会伴随产品的整个生命周期，需要细致和认真的去维护。

3、竞品分析

现在做一款产品大多数已经有竞品，做好竞品分析能达到事半功倍的效果。产品层面的竞品分析就从用户需求、产品功能，交互流程视觉展现等进行分析和对比，总结出优劣势和机会等。个人觉得不应包含市场格局，公司战略之类的，商业层面的竞争关系可以放在商业市场环节去分析。做竞品分析目的是了解竞品，更好制定竞争方案，同时学习竞品优秀的地方，但别照抄，哪怕微创新一下也好。产出物是竞品分析报告的等文档。

4、核心流程

产品能满足最主要的用户需求是什么，需求分析阶段需要团队人员明确核心流程，统一方向。流程中包含角色，任务，信息流向等几个关键点，产出物一般是泳道图。

5、技术分析

在核心流程制定后拉着技术负责人共同探讨一下，了解下研发成本，产品设计人员要有个意识，在设计流程阶段会有很多讨论和评审，尽量拉上技术负责人，这样后期会省很多麻烦。

6、商业市场 

做某一行业的产品，必须深入了解行业，商业市场分析是一个很大的话题，很多公司都是大佬们决定的，更多是产品经理在执行。目的是明确产品的商业价值，为高层做决策参考依据，获得人、钱、资源支持等。分析的角度很多，主要是了解行业，市场，竞争，用户等，预估成本和风险，不同的行业，公司，阶段侧重点不一样，需要具体问题具体分析。产出物是商业需求文档（BRD）和市场需求文档（MRD）等文档，个人觉得最重要的环节其实是项目汇报宣讲。

二、交互设计

需求都梳理好了之后就进入到了交互设计阶段，这是一个产品成型的阶段，产品从抽象的需求转化成具象的界面，需要产品经理和交互设计师配合完成，当然大部分公司都是产品汪流着泪自己完成。

1、信息架构

这里说的信息架构简单理解就是信息分类，产品由哪些功能组成，将相关功能内容组织分类，明确逻辑关系，并平衡信息展现的深广度，引导用户寻找信息，这一步要把导航规划好，最好的产出物就是一个思维导图的表格。如下图：

2、业务流程

业务流程是一个产品功能设计的基础，是一定要画的，流程确定了，后面的工作才能顺利进行，否则会出现产品功能实现摇摆不定，反复修改的状况。确定好产品中的角色，角色的任务，阶段，按信息流向把流程绘制出来。一般绘制完业务流程，产品需求文档（PRD）也该成型了，PRD文档的写法不多做讨论了，主要其实是给开发做参考依据，把产品层面的逻辑表达清楚就可以。业务流程举例：

3、页面流程

页面流程是业务流程延伸，要以用户为中心的思路来整理，按用户使用页面的顺序进行组织，把页面结构和跳转逻辑梳理的更清楚，并确定每个页面的展现主题。如下图：

4、低保真原型

低保真原型就是验证交互想法的粗略展现，不用精细，因为在这个阶段会有很多更改，需要不断的评审和讨论，最好就是纸和笔手绘，也可以用Axure或sketch做一些简单的草图，好用的软件还有mockups。如下图：

5、高保真原型

高保真原型要将详细的页面控件、布局、内容、操作指示、转场动画、异常情况等等都详细表达出来，给视觉和开发详细参考，也是交互设计的最终定稿，高保真原型可以显著降低沟通成本，具体高保真到什么程度也得看团队习惯和时间，有的团队会无限接近视觉稿，模拟真实的产品交互操作，有的则还是以黑白灰为主，把交互细节都展现出来，特别需要颜色体现交互的的地方才加一些颜色提示。如下图（来源于网络）：

6、交互说明文档

很多公司都没有专门的交互说明文档，因为时间原因一般就是在原型旁边的注释说明，不管单独的文档还是原型注释，目的都是要把交互逻辑和交互规则表达清楚。当然还有的时候，如果项目出现了一些状况，不用被开发说你的交付物不全，成为背锅侠。写交互文档要站在以开发为中心的思维上，想想开发看着说明能不能理解交互逻辑和规则。

三、视觉设计

1、视觉概念稿

正式视觉设计之前，挑几个典型页面设计不同的风格稿，等评审确定视觉风格后，再进入下一步工作，避免推翻重做的风险。 

2、视觉设计图

视觉设计也是一个很复杂的工作流程，影响一个产品展现在用户面前最直观的印象，需要延续用户体验设计原则和良好表达产品风格。视觉设计之后还需要建立标准控件库和页面元素集合等视觉规范，使团队的工作统一化，标准化。如下图：

3、标注切图

web的视觉设计完成后，需要给设计稿做标注，方便前端工程师切图，标注的内容主要是边距，间距，控件长宽，控件颜色，背景颜色，字体，字体大小，字体颜色等。移动端的设计稿不仅需要标注，还需要切图，把页面控件拆分成小图片，方便开发实现。切图要注意的就是不同分辨率，比如ios的切图就分为1倍图，2倍图，3倍图来适应不同分辨率。切好的图片按照页面和模块名称或以不同分辨率进行分类放入不同文件夹。

四、工作流程的开展形式

实际的工作环境下，下游的人不会按部就班的等上游的人完成所有工作，才开始进行自己的工作。在复杂的项目中，会将大项目拆分成不同的周期版本，按不同版本配合工作，如产品经理完成第一周期的工作后交付给交互设计师，交互设计师在进行第一周期的工作时，产品经理已经进入第二周期，然后所有上下游人员都这样顺延工作，提高效率。这来源于敏捷开发的工作思想，当然中间还有很多高效快速的工作方法，这里不多讨论。

还想跟大家说一个小的思路，就是让下游的人在做工作时候都提前一个阶段或者两个阶段参与上游工作，不要等着上游有了输出物后才开始工作，花几个小时时间，会让自己的工作思路更清晰，减少很多沟通成本和撕逼。比如在做核心流程时拉着开发负责人一起探讨，开发心中有数，等交付原型时，不用产生太大分歧。之前所在团队在需求分析阶段会多次拉着测试一起讨论，每次花一两个小时的时间，省去的是测试阶段几倍的沟通时间。

标准化工作流程主要是为了规避问题，提高效率，不是为了标准的工作流程去做工作，每个公司的流程都被人员配置，项目周期，甚至公司文化影响着，不论什么样的流程，能够达到工作目标的流程就是好流程。

产品研发流程简介
　　下两副图是产品研发简化流程图，交互设计环节被增加在提出需求与视觉设计之间，可以直观看到交互设计起到了承上启下的作用，但实际上交互设计师做了什么，如何与其他岗位更好的合作，下面将进行详细的解说。在此之前，我们先记住交互设计的本质：规划交互行为方式，设计达成行为的最有效形式。
　　没有交互设计的研发流程
　　有交互设计的快速研发流程
　　产品研发的六个层次
　　产品研发可以分为上图的六个层次，其实也就是《用户体验的要素》中提到的五层理论再加上一个实现层，这样拆分后，可以比较清楚的分析出产品由抽象到具象的过程，了解各个岗位的职责。下面将详细分析每个层次都做什么，交互设计师在各个层次的职责和作用：
　　战略层
　　内容：定义产品的方向、概念、定位、目标等;
　　一般是老板们高瞻远瞩，产品经理们深思熟虑绞尽脑汁，用研、市场、交互等同学出谋划策，就不多说了。
　　范围层内容：策划产品的规则、入口、功能、内容
　　负责人：产品经理
　　合作者：交互设计师
　　输出物：需求文档
　　在需求定义阶段，产品经理常会犯个错误——依靠描述用户行为和界面形式来表达需求：
　　产品经理往往必须借住自己对形式的观察和设想，或者从用户的角度描述其操作过程，才能明确自己想要的需求，甚至必须借助自己画的图来表达需求。为什么这么说，看看电脑里自己或别人的需求文档就知道了，如图示(这些都是产品经理交给交互设计师的需求文档中的)：
　　需求说明示例一
　　需求说明示例二
　　产品经理依靠描述用户行为和界面形式来表达需求，有三个坏处：
　　1. 你写的或画的不一定合理，这方面交互设计师更专业;
　　2. 交互设计师得按照文档想出一副画面或故事，绕着弯去研究你到底要啥，期间还得不断找茬;
　　3. 你浪费了自己的时间，说严重点，你浪费了定义产品需求的时间，偏了重点;
　　所以需求文档中，最好不要完全借助用户行为和界面形式的描述来表达需求，而应明确写出产品功能、目标等等，可以加上参考图辅助理解。如果产品经理们真的很难表达，或不确定自己要什么，最好就和交互设计师一起先讨论，交互设计师可以帮助你分析其他产品为什么要这么设计、或者你想要的一个未曾见过的功能可以怎么表达，讨论好了再制定需求，甚至直接出功能和内容列表都可以。
　　产品经理在范围层的重心，一定得放在怎么做才能实现产品战略目标了。
　　结构层
　　内容：需求的内容规划、主任务的用户行为操作流程、界面结构或信息架构
　　负责人：交互设计师
　　合作者：产品经理
　　输出物：流程图、架构图等
　　流程图
　　架构图
　　交互设计师在这个层面要梳理需求，找出用户的主要任务，定义好任务操作流程，规划好界面结构、各自功能、连贯性，期间要不断预测和规划功能的表现形式和用户使用细节。在此过程中，交互设计师可能会发现一些需求不合理之处，产品经理也可能会根据流程图、信息架构图等等，发现一些无法达到产品目标的问题，例如某个功能多余、入口过于分散、结构不够简单等等，二者一起完善需求、优化方案，力求主线清晰简单。
　　框架层
　　内容：产品的基本形式，包括布局、控件、位置、大小、一些操作细节;
　　负责人：交互设计师
　　合作者：产品经理、视觉设计师
　　输出物：静态线框图、可演示低保真原型等
　　交互原型图一
　　交互原型图二
　　在这一阶段，交互设计师就开始绘制用来表达行为的形式了，确保所用形式可以很好的让用户知道重点是什么、下一步要做什么、怎么做、不常用的功能去哪找等等，交互设计师这一阶段要做到：
　　1. 主任务流程突出明确简单，其他任务完整易懂;
　　2. 满足可用性要求(易学、易见、易用)、用户体验优秀、连贯;
　　3. 逻辑正确完整、极限情况处理完善;
　　4. 可扩展;
　　5. 符合产品所在设备系统及平台的设计规范，例如windows的控件规范、iPhone、安卓的设计指南等等，不要轻易创造不规范的控件;
　　6. 视觉设计师可以在此基础上美化发挥;
　　这也是为什么会出现交互设计师这一岗位，因为产品经理或视觉设计师都没有通常精力来做这些，或者从未做过甚至从未考虑过这些。
　　交互原型图输出时，产品经理就可以预测视觉稿是否能达到产品定义时期望的效果，查看交互图中的对内容和功能的侧重是否能满足产品需求了，审核并提出建议;但有的产品经理会要求交互设计师如何设计，例如说"我就要XX这个样子的"、"我不能接受这种布局"等等，这个时候，请产品经理认清自己和交互设计师的专业职责，让专业的人做专业的事，大家应该一起各抒己见、向用户、成本、时间妥协，讨论出对于用户和产品而言最好的方案，而不是让对方服从自己主观的想法。
　　此外，若视觉设计师在此阶段就参与讨论，对产品会更有帮助。视觉设计师要对产品非常熟悉、了解细节始末，实时关注交互原型图的进展，提出建议，将更有利于产品快速开发、减少后期因"交互原型图美化后不好看、不生动、界面太挤"之类的原因而修改交互稿。例如对于"锻造"这个过程，交互设计师设计成了A+B+C=D这种长条形布局，而做效果图时，视觉设计师才说难以体现游戏感，希望能画个炉子，在炉子的周围摆上材料，炉子中间为锻造成品，这个时候又要交互设计师重新设计就浪费精力和时间了。
　　另外，如果该项目较为重要，最好在主要界面交互原型图输出后，主动邀请权威角色评审，以免后期才得到意见，再修改就来不及或重复工作。
　　表现层
　　内容：产品外观、企业形象、视觉情感;
　　负责人：视觉设计师
　　合作者：产品经理、交互设计师
　　输出物：效果图、动画等等
　　在表现层，视觉设计师会根据交互原型图进行绘制，在交互图的基础上，可以对布局、控件的形状、形式进行微调，设计图标按钮等等，此时交互设计师应该实时关注，以确保图形及色彩的认知效果，以及是否有不太合适的更改，或未达到预设的地方;
　　若交互原型图已经经过了全员评审，视觉设计师或其他任何人最好不要再轻易修改交互相关内容，因为交互原型图中的可能每一个元素都是交互设计师经过讨论、深思熟虑后设计的，或者环环相扣、连接着更多的行为和内容，牵一发则可能动全身。如果想要修改，最好先想想或问问交互设计师为什么要这么做，提出更优化的方案。
　　上图为玩家列表的交互原型图和效果图。交互图中蓝钻、年费、昵称的位置格式是QQGAME的蓝钻规范，昵称上限为24位字符，如果按照效果图摆放，一个是不符合平台规范，另外在列表中也会因为实际昵称长短不一，导致蓝钻、年费图标显得较乱。欢乐豆数字上限为9位数，为容易阅读加上顿号分割，效果图没有预留上限位置，也去掉了顿号。
　　虽然不建议在交互原型图经过了全员评审后又修改方案，但实际上，在效果图发出后，往往仍会因为各种"觉得不好看"、"看起来很挤"、"达不到产品目标"等主观或客观原因要修改效果图乃至交互原型图布局甚至改动功能，这种风险因素很难避免，只能尽量弱化，特别是权威角色若未持续保持关注、在大型评审时可能会提出颠覆性意见。我的建议是交互设计师输出主要界面的原型图且通过全员评审后，视觉设计师马上输出对应效果图，效果图评审通过全员后，交互设计师再去全面补充剩余的交互原型图，这时候若要修改，成本就会小很多。
　　当然，在讨论过程中交互设计师也要尽量坚持自己认为正确的设计方案，或寻求折中方案，不要轻易因为大家都说"不好看"而妥协选择影响用户体验的方案;而视觉设计师也要尽量提高自己的预估能力、提前发现潜在设计风险，尽可能的避免正式做效果图时才发现相关问题;同时，交互设计师也应该尽可能的提高美学素养，更多的了解视觉设计。
　　什么时候写《产品设计文档》?
　　待主界面效果图通过评审后、视觉设计师开始补充剩余的交互原型图时，交互设计师就可以开始着手写交互说明。如果提前写了，一旦效果图有修改，就要跟着修改各种逻辑和细节，挺伤脑细胞的，也浪费时间、容易遗漏。待效果图完成后，将需求文档、交互说明、效果图合并为产品设计文档(合并这活可以由产品经理或交互设计师来做，另一方来审核即可)，交与开发。
　　为什么要合并成一份《产品设计文档》?
　　看看开发、测试同学每次要对着需求文档、交互原型及说明、效果图三种输出物来工作是有多崩溃就知道了，另外一份文档更新和同步起来也比较方便。在更新时，效果图和交互内容的更改由交互设计师维护，其他需求内容由产品经理维护，互相知会。
　　实现层
　　内容：设计审核、开发、测试、发布等;
　　负责人：伟大的程序员
　　合作者：产品经理、交互设计师、视觉设计师
　　输出物：活生生的产品
　　其实实现层不仅仅是开发过程，在前期产品设计阶段，开发人员也需要时刻参与审核把关，确保开发成本和时间合理，及时提出"无法实现"、"耗时"、"漏了XX"等问题，避免后期才提出要改动或修补交互方案。
　　不能边设计边开发(前端)
　　我们现在的开发阶段常常在交互方案还未确定时就启动了，其实这是对产品设计很不好的(当然，仅仅是开发底层或后台等不太影响)，因为：
　　1. 一旦开发将用户行为过程、界面布局写入了代码，再修改就较为困难、代价高，而事实上此时一切用户行为和形式都还未被完全确认;
　　2. 给了设计师较大的时间压力，可能会影响设计思路、逻辑的严密性、方案的质量;
　　因此，建议开发同学最好是在产品设计完全完成后，才启动前端开发。最早也应该在主界面效果图确认之后，期间任何未确认的东西先不要急于实现，或者和交互设计师确认后再实现。
　　此外，PM要监督和帮助下面两点的实施：
　　1. 如果一名交互设计师需要同时跟进多个项目(理想状态下当然不推荐这样)，可能无暇随时跟进、不能及时的发现版本问题，而产品经理是时刻盯着项目的，所以常常遇到这种状况——开发同学遇到交互问题(如方案无法实现或细节不完整)，不问交互设计师而去问产品经理，或者产品经理发现交互问题后自己提出解决方案，等到交互设计师审核版本时发现这个解决方案不合理，要修改已经代价颇高了。因此，开发过程中，遇到任何产品设计相关问题，PM或开发人员最好拉上产品经理和交互设计师一起沟通解决。
　　2. 应该严格仔细的按照产品设计文档进行开发，不要弄错一个流程、写一个错别字、弄错一个图标、错位一个像素，因为后期的每次找茬都是令人崩溃的，而且还不一定能遇到这个错误。虽然"细致"这是个传统美德，但还是不知道有多少开发GG伤害了交互妹纸的心。
　　研发流程步骤总结之前我们这边的研发流程是需求写完经过需求评审后，交互设计师输出全套交互原型图、交互说明文档，经过开发评审，美术再投入进来，前端开发再正式启动。这个流程的应用过程中出现过非常多的问题，主要问题在前文中已经提到，经过和其他交互设计师、项目组成员的讨论，我在自己参与的几个项目中进行了流程优化，效果不错，新流程的具体步骤为：
　　产品设计阶段(此阶段每一步都需要通过全员评审尤其是开发的评审)：
　　第1步：产品经理输出功能内容需求列表，期间与交互设计师密切讨论;
　　第2步：交互设计师输出主任务的用户行为操作流程、界面结构或信息架构，期间与产品经理密切讨论;
　　第3步：交互设计师输出主要界面交互原型图，期间与产品经理、视觉设计师密切讨论，通过全员审核;
　　第4步：视觉设计师输出主要界面效果图，期间与产品经理、视觉设计师密切讨论，通过全员(尤其是权威角色)审核;
　　第5步：交互设计师补充剩余交互原型图，视觉设计师补充剩余效果图，通过全员审核;
　　第6步：交互设计师输出交互说明文档，通过开发评审;
　　第7步：产品经理将需求文档、交互说明文档、效果图合并为产品设计文档;
　　正式开发阶段：
　　第8步：开始正式开发，期间与产品经理、交互设计师密切讨论(此过程最好不要有大的变更);
　　第9步;测试阶段，交互设计师等各种角色提出细微修改建议(理论上此过程不能出现任何变更);
　　……
　　理想的研发流程VS快速研发流程
　　理想的研发流程
　　实际上最理想的产品研发流程是在开发前制作出可操作的高保真原型(既不是效果图也不是用axure简单演示的原型，而是主线任务完整的、至少可以进行可用性测试的原型，详见《启示录》一书)，并不断进行可用性测试、专家评估，循环修改，然后按照最终确定的原型进行开发，再不改变任何内容。这样可以极大程度的免去需求变更导致开发重做的可能，并且预防因赶时间而放弃迭代修改，此外还可以免去阅读冗长拗口的说明文档，但更重要的是，将发出的产品已经有了相当有把握的验证。
　　像苹果、以及国内有些重视用户体验的网站就是采用的这种理想的开发流程。但网站类产品胜在可以快速实现前端DEMO、输出高保真模型，而国内的软件市场就很少有这么做的，基本上都要求产品快速产出，尽快去真实市场占个坑，再去验证和修改，根本不会给产品设计相关人员这么多时间和成本去仔细设计和验证。所以快速研发流程实际上是最常用的，虽然不算最完美，但却很快速，在架构和平台比较成熟的公司比较适用。
　　对比之下，快速研发流程中显示出一个很严重的风险，在版本出来之前谁也不知道真正的体验是怎样的，所有的过程都是依据经验的预测，如果版本出来后才发现问题，小的还可以改改，大问题根本来不及改正。所以评审和经验就显得尤为重要，这也造成了这种流程中，各种角色都保守异常、纠结致死，更是鲜有创新突破，只敢在小地方微创新一下。
　　因此全新的软件产品最好用理想研发流程，除非改起来非常简单，而快速移植类或系列产品可以用快速研发流程，但坚决不能边设计边开发，产品经理和设计师们必须提前足够的时间先启动。
　　The End
　　最后，祝每一个项目组都找到自己心仪的交互设计师，祝每一个交互设计师的脑细胞都能更强壮!没有交互设计师的项目组，那就让你们的产品经理们担负起交互设计师的责任吧

在建设网站的时候考虑用户的体验，前期要去划分网站。因为要根据用体验去做网站，只要把用户伺候好了，才能给网站带来流量。用户就是网站的全部，不能为用户解决问题的网站基本都是垃圾网站。
1、内容
网站运营，内容为王，这是非常重要的一点。一般用户来网站都是有目的来的，主要是想找到自己想要的内容，解决自己的问题。所以在更新内容或写文章的时候, 要在用户搜索的问题去想用户需要什么样的内容，然后根椐用户的问题去满足用户。当能解决用户需求的时候，才能带来更多的流量，
2、速度
网站的访问速度直接影响网站的好坏和影响力。一般来说，网站打开速度最好保持在5秒以内,不超过10秒，如果超过10秒，用户没有耐心等的而就会直接关闭网站，访方另外一个站，网站的营销力就大大降落，而且对搜索引擎的信任也会减少。可见，提高网站速度的重要性非同小可。所以各位站长在选择稳定服务器，不然的话打不开网站或网站打开慢是没有好处。
3、功能
所谓功能上的用户体验，主要是指网站的各种功能是否能让用户一看就知道怎么使用，操作的简便性、功能的易用性是最为重要的。不能让用户去研究这些功能怎么使用，还操作太麻烦，这些是网站的致命伤，因为用户进来是寻找答案的，不是研究你网站功能的。所以网站建设的工能要简单，易懂，能让用户以最短的时间完成操作。
4、设计
网站要想吸引用户，给用户带来好的体验，首先要有一个好的设计风格。因为浏览者刚刚接触到一个网站时，他对网站的第一印象很大程度上是由网站的设计风格所决定的。如果浏览者感觉整个网站的风格很有特色，就会很有兴趣继续浏览，从而对网站有一个更加深入和全面的了解。反之，如果网站设计地非常乏味，浏览者根本不会深入浏览，而是直接把网站关闭了。所以一个好的网站设计风格是至关重要的。
页面设计原则：http://www.wzyunying.com/post/272.html