咱們心心念唸的原型批註審閱方式多是這樣的...

所謂原型，無非就是一座溝通之橋，是交互設計師與PD、PM、網站開發工程師溝通的最好工具。做爲產品面世以前的框架，僅僅利用模塊、元素、線框來表達勢必會形成溝通效率低下的問題。與其浪費時間去一一詢問細節，倒不如直接在原型中進行批註和審閱，一站式的將產品的概念和構想以最簡單明瞭的方式展示給開發者或設計師，同時及時得到逆向反饋，使整個更新迭代流程事半功倍。

那麼，最原始的原型批註及審閱方式是什麼樣的呢？

在Axure中，相較於使用Axure自帶的批註功能，更多人習慣於本身動手製做須要的批註控件。我在一篇瀏覽量近一萬的文章中曾見過這樣的批註審閱demo，以下圖：

 

 

這款demo已經屬於自制批註控件中比較優秀的了，但筆者認爲，這並不是咱們須要的一站式審閱批註解決方案。理由以下：

 

1. 控件製做流程繁瑣，在Rapid Prototyping的大趨勢下，咱們沒有理由浪費如此多的時間來製做一個批註控件。想象一下吧，當你還在忙着按照網絡上的教程製做批註控件的時候，別人的原型可能已經經歷好幾回迭代了。

2. 審閱者必須安裝有Axure軟件。這個要求看似不高，但每每你並不瞭解甲方的習慣。對不少新人來講，即使你的原型作的出色，可能一次下載就讓你喪失了被確定的機會。況且你還得寄但願於甲方能理解你製做的控件的邏輯。

3. 新人難以上手。對剛接觸Axure的產品經理來講，能作出一款原型已屬不易，不多有人能騰出時間和精力來自制批註控件，而套用別人的控件又有着邏輯錯誤等隱患。

基於以上3點，咱們大概能夠概括出一種合格的審閱批註方式的輪廓：製做簡單、對審閱者要求低、對新人門檻低。

 

 

一貫以上手門檻極低和快速原型設計爲名的Mockplus給出了使人眼前一亮的答案。雖然審閱與批註只是其強大團隊協做功能的一小塊，但你一樣可由此一窺Mockplus的簡潔與高效：

1.無需控件自制，一鍵通知審閱，多種批註組件支持。

 

 

2.無需軟件安裝，急速網頁審閱，社交軟件型溝通機制。

 

 

3.無上手門檻，新人友善度Max。

在這樣的審閱體系中，審閱者無需費心勞力地一個個地去hover那些小小的批註點，更無需在冗長的標註中苦苦尋找對應的序號。原型→批註→審閱→溝通→批註→迭代，就是這麼簡單。原型設計，快是第一要務。咱們應該思考的是時間。是把時間更多的花在設計上，仍是花在由於工具複雜而形成的障礙上？

更多設計類相關乾貨（文章及經驗教程），盡在：UI/UX專業博客