Axure做为原型开发的软件，经过一段时间的应用，感觉的确非常强大，不论从模块划分、特效、基础搭建、多人协助等都比较出色。
如果熟练应用的话，可以在很短的时间内把业务思路整理清晰。
为什么需要原型？
我认为这是个非常有趣的问题，原型的开发无疑要加长整体的开发时间，并且在这段开发时间内很不稳定，会经常改动，变动之大，可能几次需要从头再来。
原型可以使业务流更加紧凑，更容易发现业务中的遗漏，可以减轻开发的迭代次数，减少开发与测试时间，更可以减少版本迭代数这个比较关键，是保证质量的前提（向老板汇报时不希望总是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

视频&PPT
Nate Koechley: "Professional Frontend Engineering" @ Yahoo! Video

Professional Frontend Engineering
View more documents from Nate Koechley.

由Yahoo前端工程师Nate Koechley演讲。深入的讲解了什么是前端工程师。
前端工程师需要了解的领域与相应的技能、为什么需要高级前端工程师。
整个谈话的四个部分:

透视历史
我们的信念与原则
知识与最佳实践区
为什么这是所有事项?

Y.Jiajia：前端工程师不仅仅是来写HTML\CSS\javascript的，更多更重要的角色需要从整个行业入手，使我们的网站前端战线更安全、更友好，这些都是需要前端人员考虑的事项。

网页设计背景
网页设计是从围绕以屏幕为基础的用户交互工具的软件图形用户界面设计发展而来。 
网页设计包括更广泛的设计实践领域，并吸收多学科的技术与知识，虽然它无法在这些学科各自的范围界限内被完全理解。

设计的定位
设计来源于许多各类的社会活动、并成为它们之间的媒介。设计与艺术有着本质性的不同，而两者又不断相互作用。
 
注：限制条件
1.显示器 2.浏览器 3.现代技术

网页与软件的不同
软件毕竟是带有明确任务的、关注文件处理领域的工具（是一种“带来”的模式）。 而网络在应用方面更为广泛。一般来说，内容导向性经任务导向性体现得更多，因此建立的客户服务模式不是“带来”，而是转向，也就是说用户可以运用动态链接获取不断更新的信息网页。这一点与图书馆学和信息设计学有相近的实际意义。
网页设计与交互体验
“适合人体”原则-大约在二次世界大站时期演化为人体工程学（人性因素），其驱动力量来源于我们在与机器设备的接触中所遇到过最复杂、最困难、最危险的挑战：驾驶飞行器。
“适合思想”原则-传统的交互方式来源于物质实体，而电脑科学则依靠于设计。 如：开车的有开车的思维模式，来帮助他们了解车辆的行驶趋势，这与电脑的优势在于，车内的发动机，传动装置和驾驶杆都是实体。
在电脑方面则需要有一套思维模式来适用从Hotmail到Google等许多不同的系统。这些系统有一个共同点，都在电脑里运行并且目前来讲都是基于键盘与鼠标。
对于表单的设计，如果一次出现多于7项时会开始下降，基于这点原因AT&T公司的贝尔实验室研发了3+4的电话号码构成模式，并最终被确认为美国能用模式。
一切都要得益于自然世界的经验，人类与数字处理系统的交互也按类似的步骤实现。 在人机交互中，基本上当某个软件用户对一个操作的反应等待时间超过1秒，他便会感到不适。从这一点出发，就是一个需要前端解决的重要问题，也是上网体验的一个重要因素。
最好的交互体验在哪里可以找到？
游戏设计！
玩家的动作与屏显反应之间的系统是创造非凡游戏体验的关键（即使对于非操作者而言）。—-街头霸王II 销售额接近美国大片 这就是为何Wii为何如此的成功！
暴雪娱乐的副总裁Rob Pardo在游戏开发者大会GDC2009上表示微软和索尼应当适应型的游戏方式和游戏机制，并做出相应的改进。他建议两家公司学习任天堂，改进自己的游戏机。他说道：“如果（索尼和微软）不能适应新的游戏方式和游戏机制，那就不要推出新的游戏机了，要不我们得到的只能是糟糕的游戏机。”
Rob Pardo也点出了《魔兽世界》至今没有登陆家用机平台的原因。这些游戏平台设计时就没有考虑某一些类型的游戏。“有很多我们开发的这类型游戏（大型网游）没办法在游戏主机在运行，就是因为这类设备不支持。RTS游戏在游戏主机上表现不佳也是这个原因。要是我是主机开发商，我会坐下来好好研究如何让我开发的主机能够支持所有的游戏。那才是一个真正酷的主机。
网页设计项目工作流程

 
部分内容节选自：What Is Web Design。

转自Microsoft Corporation
GOMS
GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符 (Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。
*不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、下几秒钟？
*操作符是指软件允许用户采取的操作。
*方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。
*选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。
卡片排序
卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。
卡片排序用于：
*展示用户对于任务范围的总体模型。
*展示用户如何对项目进行分组或分类的。
*展示用户对项目之间的关系和相似性的看法。
*将用户的概念模型转换为设计。
反复可用性测试
对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。
您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。
在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。
如 Jakob Nielsen 所述，反复的可用性测试包括：
1.用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。
2.情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。
3.简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知测试人员”。
4.启发式评估 — 基于基本可用性原则来评价界面。
开发阶段
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。
在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。
真实代码测试
让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。
可用性实验室测试
在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。
注意：   作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用性测试。
稳定化阶段
当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增强功能应被记录下来，以备下一版本使用。
基准测试
对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状态。
要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用性可以较低，可记录下来在将来的版本中再作改进。
为下一版本做准备
将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许多相同任务。例如，您将进行：
*竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有关竞争产品的数据作比较。
*现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建的软件来找出存在哪些问题，可在下一版本加以解决。
*关于事件的工具化版本研究 [...]

转自Microsoft Corporation
用户/受众分析
了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的？”，例如：
*计算机使用经验
*年龄
*接受培训的程度
*用户群之间的社会关系
*特殊要求（可访问性）
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。
规划阶段
规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft Visual Basic® 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。
根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。
用户情况
创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。
任务分析
任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。
一些要考虑的问题和活动：
*此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。
*创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。
*在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”
*与产品设计者一起创建情节串联图板或顺序简图。
启发式评估
启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困难而且成本更高。
如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
1.每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比较。
2.评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案中违反的相关可用性原则。
3.一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。
认知性遍历
认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！
根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，需要以下四个条件：
1.对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。
2.对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。
3.一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。
4.指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期要求合理执行这些步骤。

转自Microsoft Corporation
简介
可用性测试为您带来的好处
    简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。
    本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。
    在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。
  使用反复、周期性的设计过程
    反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：
    *及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。     *综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。     *及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。     *反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
    多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。
    相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。
    螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。
    构思阶段
    产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。
    在构思阶段，通常进行下列可用性活动：
   环境研究
    基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design [...]