通常，我们可以通过以下几种方法来创建高保真交互原型：

　　● 将界面效果图嵌入HTML，通过map和area标签，在图片上添加热点链接，用以响应用户的点击。

　　● 使用Photoshop或Fireworks将界面效果图快速切片，并直接生成HTML静态页面，实现简单的响应功能。

　　● 如果你的前端能力OK，手头够快，不妨代码伺候，直接上HTML、CSS、JavaScript，或使用Blueprint CSS和IxEdit这样的前端框架。

　　● 使用更专业的原型工具软件，如Axure RP或Serena Prototype Composer等，创建原型并导出成为可交互的页面集合。

　　最后一种，希望不会与你的价值观产生冲突…我们可以直接使用Dreamweaver、Microsoft Expression Web或Adobe Muse等软件的所见即所得（WYSIWYG）设计模式来快速创建原型。反正目的在于快速制作并测试原型的交互方式；再说高保真原型的代码通常也不会被用作接下来的前端或后台开发。

　　用户测试

　　通过用户测试，我们可以直接和有效的洞察到产品在用户行为、界面可用性、用户期望与功能契合程度等方面的表现。本文所侧重的原型阶段的测试，更是可以帮助我们在项目初期就能达到以下几方面的目标：

　　在产品进入开发流程之前，发现并解决那些需求和功能设计合理性方面的问题。

　　辨识并去除那些多余的功能，节省接下来的开发成本。

　　尽早发现结构布局和交互方式等方面的问题，在接下来的迭代过程中，有针对性的优化用户体验，提升最终产品的用户满意度，推动产品在市场中口碑的树立。

　　用户测试的大致方式及流程其实并不复杂：选择合适的用户作为测试对象，向他们提出一系列需要使用app原型来完成的目标，记录他们的行为及口头陈述反馈。需要花些时间和心思去琢磨的的是整个测试工作的计划与执行过程中的细节问题。

　　当然，你可以雇用那些可用性测试方面的专业代理，由他们打包搞定所有的问题，比如用户选择、任务设计、会话时长的规划、调查结果分析等；只要你的团队有足够多的经费预算用来支付外包费用。

　　幸运的是，有一些实践性强、成本低廉的方法和原则可供我们参考借鉴，自己解决问题。另外，虽然多数的第三方代理在专业水准方面值得信赖（并且价格昂贵），但他们毕竟无法像我们自己一样可以从头到尾的了解我们的产品和需求，他们最终提供的分析报告往往无法达到能够指引我们立刻采取反应措施的程度。

　　测试规模

　　每轮会话的时常最好不要超过45分钟，目标任务保持在5个以内；否则，疲劳因素会导致用户希望结束测试，进而影响其行为。

　　如果测试会持续一整天，那么每轮测试会话之间要留有20到30分钟的间隔，让你和团队相关人员有时间对前一轮的测试情况进行讨论。

　　参与测试的用户数量取决于你的应用产品的规模级别。对于一些最小可用产品的原型，测试用户的行为上有很强的关联性，重要的问题基本都可以在前面两轮测试中很清楚的呈现出来。对于复杂的应用，test subjects are more likely to identify unique issues， with diminishing returns as the total number of test users increases. Jakob Nielsen suggests that five users offer the best insight before diminishing returns kick in significantly.（“…随着测试用户数量的增多而产生收益递减的现象。Jakob Nielsen建议，在收益递减的效应变的显著之前，5名测试用户可以带来最好的测试效果。” 不敢断译，求各位观众的帮助和指正。）

　　对于复杂的应用，由于每位用户在测试中都可以有她独特的发现，那么随着用户数量的增加，这种独特性会降低，重复的发现会增加，这样我们花的时间，金钱和精力就用在发掘重复的issue上了，这不是理想的效果，经过研究5个人的数量刚好。

　　计划筹备

　　选择测试任务

　　我们未必可以测试到app的方方面面，在时间和各种资源条件有限的情况下，可以尽量选择最重要的、使用最频繁的功能，来设计测试任务。

　　好的任务描述文案读起来应该更像剧情脚本，而不是简单的引导说明；对比下面两种风格：

　　“查找一种沙爹酱的替代品”——不是非常给力。

　　“今晚，有位朋友会来你家用餐，他对坚果过敏。看看有什么方法可以相应的调整一下食谱？”——很好，具有很真实的情景感和带入感。

　　记得自己先把这些任务过一遍，确保在正式开始测试之前，原型本身不会出现明显的错误和问题。