结合个人经历 浅谈如何用好Axure

　　需求确认：和需求方确认我所理解的是不是他所想要的

　　表达想法：在产品会议上更好的告诉大家我想干什么

　　完善逻辑：在制作原型Demo时，要让它能帮我说话，传递功能需求，我至少要让这个Demo能跑起来吧？这个过程对于产品功能的完整，逻辑的清晰来说，可谓事半功倍；另外，Axure能让分支流程、异常流程更加生动，比流程图可生动多了。

　　沟通顺畅：没有仿真的Demo，让我同技术开发的同学去沟通，简直是鸡同鸭讲；此处为褒义，因为开始我没有技术功底，将需求点转为开发逻辑，即转为开发同学能听懂的很难。

　　完善交互：最终的皮，还是需要UED同学帮忙的，至少我要能说清涉及哪些元素；逐步的开始深入易用性、功能引导性，我需要和UED同学沟通具体元素的展示方式，位置等；

　　提前测试：在测试部门同学准备测试用例的时候，参照Demo他们能更快更早的发现潜在问题或逻辑不完善；甚至在开发过程中，有时测试同学能很快指出开发同学的问题点，因为和Demo不一样，至少在我所经历的项目中，没有发生到最后才发现开发出来的和需求严重不符的情况。

 

　　全页面时期：这个时期能把需求、功能或产品的大概样子描绘出来；只是在RP文件中用很多页面来表达需求,除了页面跳转外几乎没有什么交互命令；曾经有输出的Demo文件打包压缩后近4M的经历……

　　层层重叠时期：开始会用Dynamic Panel了，会简单的在当前页面实现内容切换了，控件也丰富了起来；这个时候也开始浅尝类似于开发同学看到自己的程序运行起来的那种快感了吧。现在想来，在没有Dynamic Panel Manager的时候，我的逻辑能力是何等强大啊！PS：其实那时候连同一Dynamic Panel使用多个States切换都不会！！！！！！

　　山寨开发时期：会用变量了！为了能使Demo在演示的时候能达到逼真的功能效果，绞尽脑汁去组合交互命令和变量。我想这一步已经类似开发同学的工作或逻辑了吧，只可惜我用的不是代码，是Axure，所以很山寨……

　　话说那个时期的原型已经能做到一个模块功能保存或条件不同影响其它模块功能点或显示了。现在看来很浪费时间，不过这段时间对于我个人来说帮助很大，特别是对开发逻辑的理解方面。

　　山寨UED之路：说来惭愧，因为喜欢折腾，各类工具软件，媒体处理都能整两下；除了用Captivate制作过整套CRM产品的视频教程外，甚至还三脚猫得给人做过Flash广告；可惜样样不精，Axure RP其实也是如此，像输出开发文档和多人协同SVN之类我都没用过；加上岁月蹉跎，现在好些已经操练不起来了。

　　可是，一钻起牛角尖来就想做极致；以至于输出的原型Demo除了点起来像真的以外，视觉上和最后上线的产品也相差无几 –_-||| 其实这个过程是相当浪费时间的……不过这次山寨为下个时期打下了基础；

　　交互设计之路：通过山寨UED的过程，体会到了视觉、布局对产品功能的影响；往往一个生动的图标、巧妙的按钮位置处理、页面展现的顺序等等影响整个产品功能的价值体现；印象最深刻的，在功能布局怎么看怎么不顺、引导混乱的时候，简单的分隔线和背景变换让局豁然开朗！

 

 

　　1. 先把Axure各个控件（Widgets）了解清楚，知道每个控件最基本的功能都是哪些；

　　2. 掌握控件对应的常用交互命令及组合使用方法；比较经典的案例如锚点效果制作、Tab切换效果制作。最好是从单个效果开始，不要一开始就去追求涉及变量或过于复杂的交互。

　　3. 找一个比较熟悉的网站，山寨一个出来！比如“开心网”，尝试一下自己能否用Axure制作一个从登录到使用具体应用的Demo；这个过程中不需要追求极致，比如Flash效果之类就算了。

　　山寨的目的是让你跟着需求走，什么叫需求？需求就是知道用Axure要去干什么，最后要做成什么；只有这样才会有逻辑性的去考虑用什么样的控件去做什么，是用层还是用页面实现内容的变换、哪些具有共性的可以用Master、变量需要在什么时候通过哪个点击去赋值又在哪个地方去调用，等等等等……

　　光看官方网站的Axure实例、个人分享实例，只会让你知道：“哦，原来可以这样用！”，永远也不会让你知道“为什么要这样做”！更学不会活学活用；要知道显示效果相同的原型Demo，它们对应的Axure RP源文件很可能大相径庭！