所謂原型，無非就是一座溝通之橋，是交互設計師與PD、PM、網站開發工程師溝通的最好工具。作為產品面世之前的框架，僅僅利用模塊、元素、線框來表達勢必會造成溝通效率低下的問題。與其浪費時間去一一詢問細節，倒不如直接在原型中進行批註和審閱，一站式的將產品的概念和構想以最簡單明瞭的方式展現給開發者或設計師， ...
所謂原型，無非就是一座溝通之橋，是交互設計師與PD、PM、網站開發工程師溝通的最好工具。作為產品面世之前的框架，僅僅利用模塊、元素、線框來表達勢必會造成溝通效率低下的問題。與其浪費時間去一一詢問細節，倒不如直接在原型中進行批註和審閱，一站式的將產品的概念和構想以最簡單明瞭的方式展現給開發者或設計師，同時及時獲得逆向反饋，使整個更新迭代流程事半功倍。
那麼，最原始的原型批註及審閱方式是什麼樣的呢？
在Axure中，相較於使用Axure自帶的批註功能，更多人習慣於自己動手製作需要的批註控制項。我在一篇瀏覽量近一萬的文章中曾見過這樣的批註審閱demo，如下圖：
這款demo已經屬於自製批註控制項中比較優秀的了，但筆者認為，這並非我們需要的一站式審閱批註解決方案。理由如下：
1. 控制項製作流程繁瑣，在Rapid Prototyping的大趨勢下，我們沒有理由浪費如此多的時間來製作一個批註控制項。想象一下吧，當你還在忙著按照網路上的教程製作批註控制項的時候，別人的原型可能已經經歷好幾次迭代了。
2. 審閱者必須安裝有Axure軟體。這個要求看似不高，但往往你並不瞭解甲方的習慣。對很多新人來說，即便你的原型做的出色，可能一次下載就讓你喪失了被肯定的機會。何況你還得寄希望於甲方能理解你製作的控制項的邏輯。
3. 新人難以上手。對剛接觸Axure的產品經理來說，能做出一款原型已屬不易，很少有人能騰出時間和精力來自製批註控制項，而套用別人的控制項又有著邏輯錯誤等隱患。
基於以上3點，我們大概可以歸納出一種合格的審閱批註方式的輪廓：製作簡單、對審閱者要求低、對新人門檻低。
一向以上手門檻極低和快速原型設計為名的Mockplus給出了令人眼前一亮的答案。雖然審閱與批註只是其強大團隊協作功能的一小塊，但你同樣可由此一窺Mockplus的簡潔與高效：
1.無需控制項自製，一鍵通知審閱，多種批註組件支持。
2.無需軟體安裝，急速網頁審閱，社交軟體型溝通機制。
3.無上手門檻，新人友善度Max。
在這樣的審閱體系中，審閱者無需費心勞力地一個個地去hover那些小小的批註點，更無需在冗長的標註中苦苦尋找對應的序號。原型→批註→審閱→溝通→批註→迭代，就是這麼簡單。原型設計，快是第一要務。我們應該思考的是時間。是把時間更多的花在設計上，還是花在因為工具複雜而造成的障礙上？
更多設計類相關乾貨（文章及經驗教程），盡在：UI/UX專業博客
