所謂原型雀久，無非就是一座溝通之橋，是交互設(shè)計(jì)師與PD趁舀、PM赖捌、網(wǎng)站開發(fā)工程師溝通的最好工具。作為產(chǎn)品面世之前的框架矮烹，僅僅利用模塊越庇、元素、線框來表達(dá)勢必會造成溝通效率低下的問題奉狈。與其浪費(fèi)時(shí)間去一一詢問細(xì)節(jié)卤唉，倒不如直接在原型中進(jìn)行批注和審閱，一站式的將產(chǎn)品的概念和構(gòu)想以最簡單明了的方式展現(xiàn)給開發(fā)者或設(shè)計(jì)師仁期，同時(shí)及時(shí)獲得逆向反饋桑驱，使整個(gè)更新迭代流程事半功倍。
那么跛蛋，最原始的原型批注及審閱方式是什么樣的呢碰纬？
在Axure中，相較于使用Axure自帶的批注功能问芬，更多人習(xí)慣于自己動手制作需要的批注控件悦析。我在一篇瀏覽量近一萬的文章中曾見過這樣的批注審閱demo，如下圖：
?
這款demo已經(jīng)屬于自制批注控件中比較優(yōu)秀的了此衅，但筆者認(rèn)為强戴，這并非我們需要的一站式審閱批注解決方案亭螟。理由如下：
1. 控件制作流程繁瑣，在Rapid Prototyping的大趨勢下骑歹，我們沒有理由浪費(fèi)如此多的時(shí)間來制作一個(gè)批注控件预烙。想象一下吧，當(dāng)你還在忙著按照網(wǎng)絡(luò)上的教程制作批注控件的時(shí)候道媚，別人的原型可能已經(jīng)經(jīng)歷好幾次迭代了扁掸。
2. 審閱者必須安裝有Axure軟件。這個(gè)要求看似不高最域，但往往你并不了解甲方的習(xí)慣谴分。對很多新人來說，即便你的原型做的出色镀脂，可能一次下載就讓你喪失了被肯定的機(jī)會牺蹄。何況你還得寄希望于甲方能理解你制作的控件的邏輯。
3. 新人難以上手薄翅。對剛接觸Axure的產(chǎn)品經(jīng)理來說沙兰，能做出一款原型已屬不易，很少有人能騰出時(shí)間和精力來自制批注控件翘魄，而套用別人的控件又有著邏輯錯(cuò)誤等隱患鼎天。
基于以上3點(diǎn)，我們大概可以歸納出一種合格的審閱批注方式的輪廓：制作簡單暑竟、對審閱者要求低训措、對新人門檻低。
?
一向以上手門檻極低和快速原型設(shè)計(jì)為名的Mockplus給出了令人眼前一亮的答案光羞。雖然審閱與批注只是其強(qiáng)大團(tuán)隊(duì)協(xié)作功能的一小塊，但你同樣可由此一窺Mockplus的簡潔與高效：
1.無需控件自制怀大，一鍵通知審閱纱兑，多種批注組件支持。
?
2.無需軟件安裝化借，急速網(wǎng)頁審閱潜慎，社交軟件型溝通機(jī)制。
?3.無上手門檻蓖康，新人友善度Max铐炫。
在這樣的審閱體系中，審閱者無需費(fèi)心勞力地一個(gè)個(gè)地去hover那些小小的批注點(diǎn)蒜焊，更無需在冗長的標(biāo)注中苦苦尋找對應(yīng)的序號倒信。原型→批注→審閱→溝通→批注→迭代，就是這么簡單泳梆。原型設(shè)計(jì)鳖悠，快是第一要務(wù)榜掌。我們應(yīng)該思考的是時(shí)間。是把時(shí)間更多的花在設(shè)計(jì)上乘综，還是花在因?yàn)楣ぞ邚?fù)雜而造成的障礙上憎账？????
