新手扫盲帖！原型元老软件 Axure 交互功能优劣超详细对比

Axure 相关的问题最近被问了不少，大多都不是产品需求相关的，而是和交互、原型相关的，所以今天我们就围绕交互领域，来对 Axure 进行细致的解读和扫盲。

一、“做交互”应该怎么理解

多数人对 Axure 的认识有误，并不是因为不知道 Axure 有哪些功能，可以实现哪些产出，而是压根没有搞清楚在真实项目中做的交互需求到底是什么。需要先对“做交互”这个概念有清晰的认识，才能正确理解 Axure。

在常规项目中，交互相关的产出包含两个大类：

1. 可交互原型
2. 产品交互方案

第一类可交互原型，就是可以直接上手进行操作，模拟真实线上交互效果的可交互界面。第二类产品交互方案，则是要确定产品交互方式、流程、逻辑的说明，也可以称为交互文档，需要借助界面图形和文本注释。

原则上产品交互方案可以囊括所有内容，可交互原型也是交互方案的组成部分之一，但在实际执行过程中，可交互原型的价值点往往是非常“扭曲”的，必须要单独来理解它。

在项目流程里，交互线框图、可交互原型都是为了提前试错而存在的，产品经理还是设计师可以用最小的成本对交互的方案进行探索和评审，减少设计稿做完以后再大改的几率。

但是，实际项目中很多可交互原型的输出并不是用于试错，而是为其它需求服务，比如下面这些情况：

1. 客户看不懂原型图和说明，要做出拟真效果才能点评交互和视觉上的问题，所以要用最终的设计稿做个可交互原型。
2. 要给领导检查方案的，领导不看文档，只看可以直接操作的效果，需要制作可以在会议上直接演示的可交互原型。
3. 公司过去一直有用可交互原型进行讲解和评审的习惯，所以遵循传统做出来。
4. 要做给投资人看的，可交互的形式看起来比静态页面更有说服力，所以要尽量按高的规格来设计和制作可交互原型。
5. ……

上面这些情况，都是为了给非产品团队成员模拟产品上线后的效果，换句话说是用可交互原型的方式来展示一个产品的“开发先行版”。

上周社群里还有同学分享了更离谱的经历，在外包公司设计都还没开始做，但老板和客户说开发好了，让她用 Axure 做个可交互的演示给客户现场演示……

这些使用场景不能说没有价值，毕竟能搞（hu）定（nong）领导、老板、客户也是功德无量，但它们的价值点和为了输出交互方案是不同的。

这就需要解释交互方案存在的意义了，很多人以为交互方案只是一套可交互或连过线的线框图，但复杂的项目或流程，靠这种简单直白的图例是说不明白的。

比如我之前做过一篇 AppleWatch 官方购物页面的交互改版，在一个页面中，包含了四个步骤和各种不同的控件、组件交互逻辑，光看下面的图例，能看明白吗？

只能一头雾水对不对，或者你看懂的部分（还不一定理解正确），只是交互内容中的一小部分，完整的说明可以进原文链接查看。

所以针对复杂的交互，必须要为它们添加足够的文字说明和不同的状态图例，通过补充各种信息来表达交互的逻辑。

这么做的价值，就是让团队成员能真正看懂交互方案，而不是存在大量的留白让开发和测试脑补，最后实现的结果和预期南辕北辙。同时，站在设计的角度，这个细化的过程会帮助我们查缺补漏，更深入的思考业务、产品、体验。

这两种交互的产出面向的目标和价值导向是不同的，就会影响我们后续选择的工具和实践方式，所以每次打开软件之前，先思考你面向的需求到底是哪一种。

二、Axure 在交互方面的应用

Axure 作为一个原型工具，能活跃到那么多年到今天还有人用，除了行业惯性以外，是有它自己的优势和护城河的。而我们必须要理解它到底有什么优势，能在 Figma、即时、墨刀等云端工具盛行的今天还能活下来。

除了基础的设计、布局、页面跳转功能之外，Axure 最大的优势其实就两个：

1. 数据的存储和处理
2. 条件、函数、表达式
3. 基础控件的交互

1. 数据的存储和处理

数据的存储和处理，指的是 Axure 为每个文件增加了变量和数据库的应用。

变量是一个开发术语，是一个基础的数据容器，可以记录一条固定类型的数据。比如有一个变量叫用户名，记录的数据类型是字符串，它的值可以是一个基本的用户名，比如我的 ID —— 酸梅干超人。

为什么一个原型软件里要加变量？因为交互的操作涉及到很多关键数据的处理，而这种处理没办法用设计样式来表现。

比如我们做了一个注册流程里，包含填写用户名，你现在填写的用户名要保留到后面的欢迎、个人主页。那么这个数据就必须有地方保存下来，并且可以跨组件、页面应用到其它页面中。

除了这类直接输入的数据外，还包含各类内置的数据，比如记录日间、夜间模式的布尔值，根据选项切换的商品折扣数值等。

变量的重要性对于拟真的交互来说非常重要，所以 Protopie 中也提供了对应的功能，即使 Figma 也在近期上线了 Variable 设置面板。

除了变量外，还提供了更复杂的数据容器 —— 中继器数据库。这是一个简化版的关系型数据库，我们可以手动填写也可以导入大批量的数据。

这个数据库的作用有很多，最直观的应用场景就是套用在 B 端表格组件中。因为这么实现表格填入的数据是引用的，所以我们用交互实现各种拟真的操作，比如搜索、筛选、排序、翻页，甚至是多条件相加的组合结果。

对于数据的存储和引用是 Axure 最重要的功能，也是它的核心优势，确保了复杂数据应用的需求只有它能实现而其它交互软件做不到。

2. 条件、表达式、函数

既然数据有了，只是机械的存取就太枯燥和浪费了，所以要更好的利用数据，就引入了对数据更复杂的处理和应用方法，即条件、表达式、函数。

条件就是在触发交互时进行的判断，并根据不同的依据给出不同的结果。比如点击登录按钮，判断用户名、密码框是否为空，用户名和密码的长度、格式是否正确，并给出对应的结果。

表达式，则是用来进行数据处理的公式，最简单的表达式就是加减乘除，比如计算订单总价、商品折扣，我们就可以用变量结合表达式的方法进行计算和输出。

函数则是一些内置好的方法，比如获取字符串长度、当前时间、滚动距离、鼠标位置等等。可以结合条件判断进行使用，比如在 APP 界面中，页面滚动超过一定距离切换顶栏样式，就可以使用 scrollY > 200 和 scrollY < 200 的条件判断并设置两个不同的触发结果。

以上三个功能，进一步强化了 Axure 在数据应用方面的优势，完全模仿开发的逻辑处理方式实现更拟真的交互效果。

也可以说，Axure 就是一个 LowCode 低代码编辑器，让你用可视化图形界面直接制作一个可交互的网页（预览的模式）。

3. 基础控件的交互

最后一个基础控件的交互，即自带元件中直接内置了基础的交互事件和属性设置。比如输入框、选择、下拉菜单、树状图等，都已经内置好交互的行为和方法，只要添加就可以直接在预览中进行操作。

这在一些比较初级的交互场景中可以节省我们大量时间，并且已经编辑好的可交互元件，还可以组成独立的元件库在其它项目中使用。

Axure 的另一个优势，就是网上有非常多成套的元件库素材，可以直接下载并引用，加快制作的效率。

四、Axure 的问题和缺点

上面三点，是 Axure 的看家本领，也是它的核心优势，但这并不代表它是一个完美的交互工具，所以我们还要来讲讲它有哪些问题。

这里我可以用一句话总结 ：

除了上面三个优势外它只有缺点……

作为一个原型工具，就算做线框图也是要有设计和排版过程的，而它的操作效率并不高，远远无法和设计类软件相比。也就是搭建基础页面样式的速度慢，要占用大量的时间。

同时，Axure 最难受的一点，在于画布的设置，一个页面只能在侧边创建一个 Page，而不像普通设计软件使用 Page / 画布 / 画板 的结构进行管理，导致项目页面数多时则侧边的列表非常长，很难找到指定页面。

而且作为付费软件 Axure 的价格很昂贵，如果只用“学习版”，那么不能直接应用官方的团队协作和线上分享，只能直接导出传输或者用第三方工具上传，这个工作流和云协作的模式是脱节的，毫无效率。

虽然 Axure 的核心功能很强大，但也不是无所不能的。比如前面分享的苹果手边页面交互，想要完整的实现这套交互几乎是不可能的，只能做一小部分，那实现不出来的部分还是要用文字注释。

还有很多页面、组件会有不同的状态，这些状态不是依靠用户的操作触发的，比如断网、运营推送、下单中断货等，这些状态要设计出来，但它们又没办法被置入到操作的流程里，那别人怎么看见它们？

所以项目就会呈现出一部分页面有完整的交互，但是另一部分页面、事件、交互在演示中不可见的尴尬问题。对于需要根据交互方案进行设计、开发的其它团队成员来说，演示模式就显得很鸡肋，因为看不全。

很多交互还是产品的新人，会以为做可交互的原型看起来很酷炫专业，能动的东西其他团队成员也会喜欢，这是非常错误的认识。

因为自己操作会有各种遗漏，状态还显示不全，所以直接看静态的模式远比手动操作准确，而 Axure 的页面列表又非常复杂，看起来麻烦找起来也麻烦，这是越复杂的 Axure 文档越没有人看的主要原因之一。

同时，还有个最致命的问题，就是交互和设计在工作流里分不分家？

如果交互设计和界面设计分拆，由不同人负责，有非常严格的规章流程约束，那么各做各的没什么问题。

但这种模式效率低下，多数团队会把它们都合并到 UI 设计师的职责范围内。那我们就要面对 Axure 的另一个缺陷，图层无法迁移进设计软件内（或者各种 bug）。

不管我们在 Axure 内做出多精美、完整的原型，都只能停留在 Axure 内，进入到视觉设计阶段还是只能老老实实重新造一遍轮子，这是一种对时间精力的巨大浪费。

而且最严重的问题，在于最终设计稿和原型交互不统一，那么开发参照谁的？

以前经常提到，最好的交互文档里的图例得用最终设计稿，代表最终的结果。如果两者分割那么前面的交互文档就没有参考价值，直接作废，那么花那么多时间做的意义在哪里？

所以，如果目标是输出产品交互方案，且交互和设计都是一个人来完成，那么就不建议使用 Axure 来制作，直接使用设计软件即可，对于实际项目来说只要交互的表达做清楚，你一个可交互事件都不做也没有任何影响。

如果你的目标是为了评审，应对领导，一定要做出非常拟真的效果，那么增加额外的工作量是无可避免的，老老实实打开 Axure 去完成。

结尾

自从 Figma 等云端软件兴起，Axure 虽然还有人用，但在全球范围内的使用比例是逐年下降的，说到底就是因为 —— 不好用。它像 XD、Sketch 一样完全边缘化只是时间问题，我们没必要死守着“祖宗”的规矩不放。

同时，上面的结论对于产品经理还是交互设计师来说也适用，只要你的面向场景中不需要进行拟真的交互操作演示，那就不是必须要用 Auxre 来制作产品文档还是交互文档。

软件是为目标服务的，而不是我们为软件服务……

我们下篇再贱！