在互联网产品领域，Axure已成为产品经理、产品设计师以及交互设计师的必备工具，从某种程度讲，Axure帮助我们建立低保真模型，便于与用户的需求验证，也帮助我们构思交互细节，使前端和开发人员更容易理解我们的产品；但从另一方面讲，Axure绑架了我们的思维，让很多产品经理和设计师养成了“无Axure不设计”的恶习，忽略了用户故事、功能规格和信息架构，甚至走入“为了用Axure而用的误区”，导致了资源的大量浪费和产品的硬伤。因此，提醒为Axure着迷的产品经理：在熟练使用2B铅笔前，请不要打开Axure。
自我监测是否对Axure着迷
喜欢开始设计产品时就打开Axure的产品经理通常有一些共性：
熟练掌握Axure或对Axure充满了敬畏；
信奉细节至上，认为Axure完全可以替代PRD；
喜欢通过Axure实现复杂交互或精细化原型并取得成就感。
保持最新版的Axure，常泡Axure专业社区；
很少使用铅笔和白板进行沟通；
符合其中的3条，可以说你处在高速成长中；不过如果5条都符合，说明你应该调整一下自己的侧重点，否则你将偏离Axure原型工具的初衷而陷入细节，导致视野受限或沟通不畅，甚至造成产品和项目的失败。
清醒认识Axure在产品设计流程中的位置
必须承认，不同公司、不同组织结构和不同岗位对“正确的产品设计流程”有着千差万别的认识。但我们依然可以引用AJAX之父Jesse James Garrett在其《用户体验要素》中提到的5个层级来达成一些共识：
不同角色应该关注的产品层级：
BOSS与产品负责人先解决战略层问题；
产品负责人或产品经理解决范围层问题；
产品经理带队搞定结构层问题；
产品经理带领产品设计师或交互设计师，设计框架层；
界面美术设计师根据框架层设计表现层。
到这里，争议出现了，有人认为在结构层，应该使用Axure出交互设计原型，我想这个误解也是Axure被滥用的根源所在。
交互设计不等于使用Axure设计原型中的交互界面
我知道这有点绕口，并且有些扯远了，但不得不说，大多数产品人并不能很好的理解交互设计与设计交互界面有什么联系，并且绝大多数产品团队在结构层几乎断档。
用户界面是交互设计的结果的自然体现，但是不能说交互设计就是用户界面设计。交互设计的出发点在于研究人在和物交流（dialog）时候，人的心理模式和行为模式，并在此研究基础上，设计人工物的可提供的交互方式，来满足人对使用人工物的三个层次的需求（usefulness, usability and emotionality）。从这个角度看来，交互设计是设计方法，而界面设计是交互设计的自然结果。同时界面设计不一定由显意识交互设计驱动，然而界面设计必然自然包含交互设计。
我们期待未来的人机交互能早点实现，不过对目前互联网产品而言，交互设计的步骤包括：
用户调研
概念设计
创建用户模型
创建界面流程
开发原型并进行可用性测试
很显然，使用Axure设计快速原型，应该放在交互设计的整体工作结束后，也就是框架层设计时进行。
不过，我没有一点贬低Axure的意思，因为在框架层中，Axure的widget元件、交互动作能够很方便的绘制网站的界面、导航、甚至细节的信息元素。并且能够快速生成可交互原型与需求方和项目组内进行沟通。在某些敏捷团队中，Axure原型的确可以代替PRD使用。
产品结构层设计，请先拿起你的2B铅笔
面对结构层的抽象，请不要灰心，2B铅笔是你克服困难的终极武器，记住，要用2B铅笔。因为2B铅笔软硬度适中，涂抹均匀，价格便宜，韧性好又容易擦拭，无论考试还是素描都是很好的选择:)
当需求范围已经相对清晰时，请先拿起笔，把产品的蓝图画出来。通常对一个网站而言，你需要构建一副整体信息架构蓝图，也就是网站的主要网页和层级关联。记住，只有当你相信自己用2B铅笔画的信息架构草图是大家想要的，否则不要着急用工具进行美化。
对于网站中复杂的功能流程或对于软件产品而言，你需要通过UML（统一建模语言）描绘更加具体的概念模型。
将构思映射在纸上，提高沟通效率
用铅笔勾勒蓝图或流程，目的是提高沟通的效率。拿起2B铅笔，用10分钟将头脑风暴或范围讨论后的思路花在纸上，尽快与BOSS或团队成员确认，是结构层最重要的事情，没有唯一。
我见过太多的产品人员，包括我自己也曾经常犯类似的错误：妄图一开始就使用电脑辅助设计程序，优美的将信息架构或流程图画出来。甚至跳过这一步，直接使用Axure话线框图。这个错误的可怕之处在于：你搞得自己很忙很苦逼，结果做出来的是无法得到认同的垃圾。更可怕的是，在面对你看似完美的图标或线框图时，BOSS被你忽悠住了，然后你们投入了整个团队的开发资源，用了几个月开发了一堆垃圾出来。
如果说80%的产品失败在需求阶段，我可以说80%的需求失败，是没有用2B铅笔沟通而很2B的用软件沟通。你完全可以10分钟画一个简单的网站结构或核心功能逻辑，然后与领导充分沟通，尽可能的把问题暴露出来，并尽快优化甚至推翻重做。否则你将深陷网站界面和细节交互的泥潭，而忽略了产品真正的核心价值所在。记住，需求被砍掉不是耻辱，做垃圾浪费资源才是最大的耻辱。
用白板统一意见
如果说用2B铅笔绘制草图是产品项目的大脑，那么白板就是产品项目的心脏，对敏捷团队尤其如此。无论是在范围层的头脑风暴或敏捷故事中，还是在结构层设计时对更加详细的蓝图或流程进行确认时，需要将构想画出来，并且可能需要边画边讲。如果你对此已经轻车熟路，你可以在简历中写上自己善于沟通了。
使用工具将结构层存档
到目前为止，你的产品规划应该已经符合了领导的构思，同时也赢得了架构师的支持。非常好，你只需要用Visio将其画出来，就可以插入需求文档了。虽然visio有一些问题，但我认为它依然是描述结构层最好的建模工具，不是因为它有多强大，恰恰相反，它够简单。
也许ROSE类工具更加强大，但你不是开发者，更不是架构师，认清自己的角色，对产品经理而言，Visio的UML工具和网站总体设计图已经能够满足结构层的需要，不要被复杂的工具左右自己的思路。当然，如果你使用MAC，OmniGraffle毫无疑问是你最好的搭档。
在框架层，开始低保真模型的设计
终于从抽象到具体了，你可以偏执地继续装B手绘
不过大多产品经理会选择Axure作为快速原型工具
Balsamiq mockup也是不错的选择，总之，这一阶段你需要设计产品的低保真模型。但千万不要自娱自乐并深陷细节。因为你需要基于低保真模型进行又一轮沟通，如果条件允许，最好进行一次可用性测试。
你需要将领导、团队、甲方甚至扫地大妈的意见综合考虑，对低保真模型进行优化调整，并不断完善，以形成可以存档的产品交付物。对不同的团队，你有几个选择：
敏捷小团队：直接基于Axure进行开发；
矩阵式项目组：将低保真模型做成高保真模型，并尽可能完善交互细节，便于交付UED或美工进行设计；
跨业务或外包：为了预防变更，需要更多前期可用性测试。并尽可能完善说明和注释信息，输出word等存档。