Axure 相關的問題最近被問了不少，大多都不是產品需求相關的，而是和交互、原型相關的，所以今天我們就圍繞交互領域，來對 Axure 進行細致的解讀和掃盲。

一、“做交互”應該怎么理解

多數人對 Axure 的認識有誤，并不是因為不知道 Axure 有哪些功能，可以實現哪些產出，而是壓根沒有搞清楚在真實項目中做的交互需求到底是什么。需要先對“做交互”這個概念有清晰的認識，才能正確理解 Axure。

在常規(guī)項目中，交互相關的產出包含兩個大類：

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

第一類可交互原型，就是可以直接上手進行操作，模擬真實線上交互效果的可交互界面。第二類產品交互方案，則是要確定產品交互方式、流程、邏輯的說明，也可以稱為交互文檔，需要借助界面圖形和文本注釋。

原則上產品交互方案可以囊括所有內容，可交互原型也是交互方案的組成部分之一，但在實際執(zhí)行過程中，可交互原型的價值點往往是非常“扭曲”的，必須要單獨來理解它。

在項目流程里，交互線框圖、可交互原型都是為了提前試錯而存在的，產品經理還是設計師可以用最小的成本對交互的方案進行探索和評審，減少設計稿做完以后再大改的幾率。

但是，實際項目中很多可交互原型的輸出并不是用于試錯，而是為其它需求服務，比如下面這些情況：

1. 客戶看不懂原型圖和說明，要做出擬真效果才能點評交互和視覺上的問題，所以要用最終的設計稿做個可交互原型。
2. 要給領導檢查方案的，領導不看文檔，只看可以直接操作的效果，需要制作可以在會議上直接演示的可交互原型。
3. 公司過去一直有用可交互原型進行講解和評審的習慣，所以遵循傳統(tǒng)做出來。
4. 要做給投資人看的，可交互的形式看起來比靜態(tài)頁面更有說服力，所以要盡量按高的規(guī)格來設計和制作可交互原型。
5. ……

上面這些情況，都是為了給非產品團隊成員模擬產品上線后的效果，換句話說是用可交互原型的方式來展示一個產品的“開發(fā)先行版”。

上周社群里還有同學分享了更離譜的經歷，在外包公司設計都還沒開始做，但老板和客戶說開發(fā)好了，讓她用 Axure 做個可交互的演示給客戶現場演示……

這些使用場景不能說沒有價值，畢竟能搞（hu）定（nong）領導、老板、客戶也是功德無量，但它們的價值點和為了輸出交互方案是不同的。

這就需要解釋交互方案存在的意義了，很多人以為交互方案只是一套可交互或連過線的線框圖，但復雜的項目或流程，靠這種簡單直白的圖例是說不明白的。

比如我之前做過一篇 AppleWatch 官方購物頁面的交互改版，在一個頁面中，包含了四個步驟和各種不同的控件、組件交互邏輯，光看下面的圖例，能看明白嗎？

只能一頭霧水對不對，或者你看懂的部分（還不一定理解正確），只是交互內容中的一小部分，完整的說明可以進原文鏈接查看。

所以針對復雜的交互，必須要為它們添加足夠的文字說明和不同的狀態(tài)圖例，通過補充各種信息來表達交互的邏輯。

這么做的價值，就是讓團隊成員能真正看懂交互方案，而不是存在大量的留白讓開發(fā)和測試腦補，最后實現的結果和預期南轅北轍。同時，站在設計的角度，這個細化的過程會幫助我們查缺補漏，更深入的思考業(yè)務、產品、體驗。

這兩種交互的產出面向的目標和價值導向是不同的，就會影響我們后續(xù)選擇的工具和實踐方式，所以每次打開軟件之前，先思考你面向的需求到底是哪一種。

二、Axure 在交互方面的應用

Axure 作為一個原型工具，能活躍到那么多年到今天還有人用，除了行業(yè)慣性以外，是有它自己的優(yōu)勢和護城河的。而我們必須要理解它到底有什么優(yōu)勢，能在 Figma、即時、墨刀等云端工具盛行的今天還能活下來。

除了基礎的設計、布局、頁面跳轉功能之外，Axure 最大的優(yōu)勢其實就兩個：

1. 數據的存儲和處理
2. 條件、函數、表達式
3. 基礎控件的交互

1. 數據的存儲和處理

數據的存儲和處理，指的是 Axure 為每個文件增加了變量和數據庫的應用。

變量是一個開發(fā)術語，是一個基礎的數據容器，可以記錄一條固定類型的數據。比如有一個變量叫用戶名，記錄的數據類型是字符串，它的值可以是一個基本的用戶名，比如我的 ID —— 酸梅干超人。

為什么一個原型軟件里要加變量？因為交互的操作涉及到很多關鍵數據的處理，而這種處理沒辦法用設計樣式來表現。

比如我們做了一個注冊流程里，包含填寫用戶名，你現在填寫的用戶名要保留到后面的歡迎、個人主頁。那么這個數據就必須有地方保存下來，并且可以跨組件、頁面應用到其它頁面中。

除了這類直接輸入的數據外，還包含各類內置的數據，比如記錄日間、夜間模式的布爾值，根據選項切換的商品折扣數值等。

變量的重要性對于擬真的交互來說非常重要，所以 Protopie 中也提供了對應的功能，即使 Figma 也在近期上線了 Variable 設置面板。

除了變量外，還提供了更復雜的數據容器 —— 中繼器數據庫。這是一個簡化版的關系型數據庫，我們可以手動填寫也可以導入大批量的數據。

這個數據庫的作用有很多，最直觀的應用場景就是套用在 B 端表格組件中。因為這么實現表格填入的數據是引用的，所以我們用交互實現各種擬真的操作，比如搜索、篩選、排序、翻頁，甚至是多條件相加的組合結果。

對于數據的存儲和引用是 Axure 最重要的功能，也是它的核心優(yōu)勢，確保了復雜數據應用的需求只有它能實現而其它交互軟件做不到。

2. 條件、表達式、函數

既然數據有了，只是機械的存取就太枯燥和浪費了，所以要更好的利用數據，就引入了對數據更復雜的處理和應用方法，即條件、表達式、函數。

條件就是在觸發(fā)交互時進行的判斷，并根據不同的依據給出不同的結果。比如點擊登錄按鈕，判斷用戶名、密碼框是否為空，用戶名和密碼的長度、格式是否正確，并給出對應的結果。

表達式，則是用來進行數據處理的公式，最簡單的表達式就是加減乘除，比如計算訂單總價、商品折扣，我們就可以用變量結合表達式的方法進行計算和輸出。

函數則是一些內置好的方法，比如獲取字符串長度、當前時間、滾動距離、鼠標位置等等。可以結合條件判斷進行使用，比如在 APP 界面中，頁面滾動超過一定距離切換頂欄樣式，就可以使用 scrollY > 200 和 scrollY < 200 的條件判斷并設置兩個不同的觸發(fā)結果。

以上三個功能，進一步強化了 Axure 在數據應用方面的優(yōu)勢，完全模仿開發(fā)的邏輯處理方式實現更擬真的交互效果。

也可以說，Axure 就是一個 LowCode 低代碼編輯器，讓你用可視化圖形界面直接制作一個可交互的網頁（預覽的模式）。

3. 基礎控件的交互

最后一個基礎控件的交互，即自帶元件中直接內置了基礎的交互事件和屬性設置。比如輸入框、選擇、下拉菜單、樹狀圖等，都已經內置好交互的行為和方法，只要添加就可以直接在預覽中進行操作。

這在一些比較初級的交互場景中可以節(jié)省我們大量時間，并且已經編輯好的可交互元件，還可以組成獨立的元件庫在其它項目中使用。

Axure 的另一個優(yōu)勢，就是網上有非常多成套的元件庫素材，可以直接下載并引用，加快制作的效率。

四、Axure 的問題和缺點

上面三點，是 Axure 的看家本領，也是它的核心優(yōu)勢，但這并不代表它是一個完美的交互工具，所以我們還要來講講它有哪些問題。

這里我可以用一句話總結 ：

除了上面三個優(yōu)勢外它只有缺點……

作為一個原型工具，就算做線框圖也是要有設計和排版過程的，而它的操作效率并不高，遠遠無法和設計類軟件相比。也就是搭建基礎頁面樣式的速度慢，要占用大量的時間。

同時，Axure 最難受的一點，在于畫布的設置，一個頁面只能在側邊創(chuàng)建一個 Page，而不像普通設計軟件使用 Page / 畫布 / 畫板 的結構進行管理，導致項目頁面數多時則側邊的列表非常長，很難找到指定頁面。

而且作為付費軟件 Axure 的價格很昂貴，如果只用“學習版”，那么不能直接應用官方的團隊協(xié)作和線上分享，只能直接導出傳輸或者用第三方工具上傳，這個工作流和云協(xié)作的模式是脫節(jié)的，毫無效率。

雖然 Axure 的核心功能很強大，但也不是無所不能的。比如前面分享的蘋果手邊頁面交互，想要完整的實現這套交互幾乎是不可能的，只能做一小部分，那實現不出來的部分還是要用文字注釋。

還有很多頁面、組件會有不同的狀態(tài)，這些狀態(tài)不是依靠用戶的操作觸發(fā)的，比如斷網、運營推送、下單中斷貨等，這些狀態(tài)要設計出來，但它們又沒辦法被置入到操作的流程里，那別人怎么看見它們？

所以項目就會呈現出一部分頁面有完整的交互，但是另一部分頁面、事件、交互在演示中不可見的尷尬問題。對于需要根據交互方案進行設計、開發(fā)的其它團隊成員來說，演示模式就顯得很雞肋，因為看不全。

很多交互還是產品的新人，會以為做可交互的原型看起來很酷炫專業(yè)，能動的東西其他團隊成員也會喜歡，這是非常錯誤的認識。

因為自己操作會有各種遺漏，狀態(tài)還顯示不全，所以直接看靜態(tài)的模式遠比手動操作準確，而 Axure 的頁面列表又非常復雜，看起來麻煩找起來也麻煩，這是越復雜的 Axure 文檔越沒有人看的主要原因之一。

同時，還有個最致命的問題，就是交互和設計在工作流里分不分家？

如果交互設計和界面設計分拆，由不同人負責，有非常嚴格的規(guī)章流程約束，那么各做各的沒什么問題。

但這種模式效率低下，多數團隊會把它們都合并到 UI 設計師的職責范圍內。那我們就要面對 Axure 的另一個缺陷，圖層無法遷移進設計軟件內（或者各種 bug）。

不管我們在 Axure 內做出多精美、完整的原型，都只能停留在 Axure 內，進入到視覺設計階段還是只能老老實實重新造一遍輪子，這是一種對時間精力的巨大浪費。

而且最嚴重的問題，在于最終設計稿和原型交互不統(tǒng)一，那么開發(fā)參照誰的？

以前經常提到，最好的交互文檔里的圖例得用最終設計稿，代表最終的結果。如果兩者分割那么前面的交互文檔就沒有參考價值，直接作廢，那么花那么多時間做的意義在哪里？

所以，如果目標是輸出產品交互方案，且交互和設計都是一個人來完成，那么就不建議使用 Axure 來制作，直接使用設計軟件即可，對于實際項目來說只要交互的表達做清楚，你一個可交互事件都不做也沒有任何影響。

如果你的目標是為了評審，應對領導，一定要做出非常擬真的效果，那么增加額外的工作量是無可避免的，老老實實打開 Axure 去完成。

結尾

自從 Figma 等云端軟件興起，Axure 雖然還有人用，但在全球范圍內的使用比例是逐年下降的，說到底就是因為 —— 不好用。它像 XD、Sketch 一樣完全邊緣化只是時間問題，我們沒必要死守著“祖宗”的規(guī)矩不放。

同時，上面的結論對于產品經理還是交互設計師來說也適用，只要你的面向場景中不需要進行擬真的交互操作演示，那就不是必須要用 Auxre 來制作產品文檔還是交互文檔。

軟件是為目標服務的，而不是我們?yōu)檐浖铡?/p>

我們下篇再賤！