转载：来自Richard推荐的两个国外Axure RP案例

写在前面： 很高兴有访问我Blog的朋友能通过页面上的“e网打进”联系我； 很高兴他们都在学习Axure； 很高兴我能帮助他们解决眼前遇到的使用问题； 希望他们在使用Axure制作出原型后也很高兴！   更希望他们制作的原型能让它的受众也很高兴，他们通过原型更加了解需求，很快知道下一步该如何配合。   关于可乐：     一名半路出家的产品设计师，代码认识我，我不认识他；     “出家前”的工作只涉及到销售、渠道、市场、运营和服务，技术方面顶多可以去应聘个网吧网管（仅限于规模在四五十台机器左右的），如果我肚子里那些能算技术的话……     Axure伴随着我一路成长至今一年有余，对我产品设计师的生涯来说，可谓功不可没！好像是从4.X版本开始入门的。   从工作内容的深入来说，Axure扮演了以下重要角色： 需求确认：和需求方确认我所理解的是不是他所想要的 表达想法：在产品会议上更好的告诉大家我想干什么 完善逻辑：在制作原型Demo时，要让它能帮我说话，传递功能需求，我至少要让这个Demo能跑起来吧？                这个过程对于产品功能的完整，逻辑的清晰来说，可谓事半功倍；                另外，Axure能让分支流程、异常流程更加生动，比流程图可生动多了。 沟通顺畅：没有仿真的Demo，让我同技术开发的同学去沟通，简直是鸡同鸭讲；                此处为褒义，因为开始我没有技术功底，将需求点转为开发逻辑，即转为开发同学能听懂的很难。 完善交互：最终的皮，还是需要UED同学帮忙的，至少我要能说清涉及哪些元素；                逐步的开始深入易用性、功能引导性，我需要和UED同学沟通具体元素的展示方式，位置等； 提前测试：在测试部门同学准备测试用例的时候，参照Demo他们能更快更早的发现潜在问题或逻辑不完善；                甚至在开发过程中，有时测试同学能很快指出开发同学的问题点，因为和Demo不一样 ：）                至少在我所经历的项目中，没有发生到最后才发现开发出来的和需求严重不符的情况。   从Axure的功能点掌握来说，可乐经历了以下过程： 全页面时期：     这个时期能把需求、功能或产品的大概样子描绘出来；     只是在RP文件中用很多页面来表达需求,除了页面跳转外几乎没有什么交互命令；     曾经有输出的Demo文件打包压缩后近4M的经历…… 层层重叠时期：     开始会用Dynamic Panel了，会简单的在当前页面实现内容切换了，控件也丰富了起来；     这个时候也开始浅尝类似于开发同学看到自己的程序运行起来的那种快感了吧 ：）     现在想来，在没有Dynamic Panel