原型設計法
- 2. A simple vector wireframe
使用線框稿的好處
以線框稿來呈現與規劃產品,最大的特色就是快速並節省企業資源。尤其使用目前市面上好用的工具,諸如:UXPin、Balsamiq
或是 Axure,製作上更加方便迅速。不過,必須在設計流程中合理適時的使用它。
在產品設計的前期,若要有效準確的收集開發者、客戶或使用者等回饋,線框稿是最好的方法!怎麼說?因為人們可以更專注
於功能面、資訊架構面、使用者體驗、操作流程、使用性及使用者介面等的討論。避免視覺設計的干擾,而無法達成或混淆
收集回饋的目的。此外,若是需求改變也可以很快的做出調整,而不需要直接修改原始碼或是視覺設計。
互動式線框稿 (或稱可點擊式線框稿 Clickable Wireframe)
有時候,設計師希望提高線框稿的擬真度、強調介面設計的某些部分或讓使用者更快理解以利進行測試,設計師會快速的製
作可互動的線框稿,也就是可點擊式線框稿。
初次與關係人或客戶介紹設計時,互動式線框稿將會是相當有用的。當這些人問說按下這個按鈕會發生甚麼事情?
提報者可以在互動式線框稿上馬上操作,讓他們看到結果。這樣的方式肯定可以讓他們印象深刻並快速進入操作的情境中。
Interactive prototype
designed in UXPin
以線框稿簡報時須注意幾點
非專業的關係人 (如顧客或非技術領域的管理者等) 在觀看線框稿的時候,可能在心中會產生疑問,例如:到底這是不是最終
設計?與最終設計之間的關係為何?
- 3. 這就是為什麼我們必須花點時間來解釋線框稿的定義,以及它在產品設計流程中的所扮演的角色與意義。
在與不識此概念的關係人提報之前,提報者更需要自己釐清線框稿的目的與概念,才能有效的溝通並達成目的。
Quick hand-sketched wireframing of an app’s user flow by Fernando Guillen
原型 (Prototype)
原型與線框稿不同的地方在於,原型是屬於中到高度擬真來呈現最終使用者介面的方法。運用原型的目的即是模擬使用者與
介面之間的互動,例如說按鈕按下後會出現的操作方式與呈現等。簡單來說,就是模擬一個產品完整的體驗。
原型的視覺要素與特質
就視覺設計而言,原型比線框稿更加的接近於最終產品的樣貌。原型雖然看起來像最終的產品,但它不具有可運作的要素 (例
如程式碼與數據庫等)。在原型表達上應該有下列要素:基本的色調可先被設定、關鍵的內容需被呈現、資訊架構應該被建立
與互動的效果與方式。
使用原型的好處
為什麼在開發流程中使用原型這個工具非常重要?因為原型通常會對真實的使用者進行測試,來挖掘產品的問題。如此一來,
就可以在前期提早發現問題並修正,節省許多後期修改的時間與成本。對設計與開發團隊而言,它絕對是一個相當棒的驗證
工具。此外,讓使用者在原型上進行一些必要的任務往往可以得到讓團隊驚訝的洞見。
原型不需要藉由編碼的方式來產出,現在有許多良好的工具可以幫助設計師以快速且低成本的方式製作,作者推薦了一些好
用的工具(UXPin,Proto.io,Balsamiq,Moqups,Mockingbird,Axure,Protoshare,InvisionApp。原型經過使用者測試後,設計
師可將產品的設計做精準的修改,而不需要浪費開發團隊的時間與精力。
設計流程
了解設計的本質以及線框稿與原型的不同,僅是進入使用者體驗設計的門檻。更重要的是,你能不能讓整個產品開發流程有
更高的凝聚力、效能與效率。
建議
1.當進行線框稿的製作時,可以先規劃一些共用的元素。到原型階段時,就可以更輕易的針對這些元素做設計了。
2.確保線框稿做完後,需與關係人與團隊成員討論,在得到回饋後進行修改。
3.利用好用的軟體工具來提升繪製的效率。
- 4. 參與原型開發的最佳人選是那些未來實際使用這些應用程式的人員,因為這些人擁有最多成功實作的經驗,而且他們也是最
知道自己所需的人選。
投資原型開發工具能讓您快速地將螢幕設計擺放在一起。由於您可能不想 要保留編寫的原型程式碼(快速編寫的程式碼很
少值得保留),而且您也不應該太擔心如果原型開發工具所產生的程式碼,與您進行開發所想要使用的 程式碼其類型有所
不同。
如同您在買車前想試車一樣, 您的使用者應該可以在應用程式開發之前也測試一下。除此之外,透過親自參與原型的作業,
他們可以快速地確認此系統是否符合他們的需求。一個好的方 式是通過運用一些使用案例劇情(use-case scenarios)所建造
的原型,請他們把它當作是真的系統一樣去工作。
在開發原型之前,您需要理解原型 所要支援基本的業務。換句話說,您必須將 UI 原型架構在需求之上。因此越能瞭解業
務,就越有可能構建出支持該業務的原型。
在原型開發過程之初,隨著對業務瞭解的深入,會拋棄許多已做過的工作。所以,在可能不會保留的程式碼上花費大量的精
力,往往是毫無意義的。
假如您不可能實現(deliver)該功能,那麼就不要對此功能進行原型開發。
使用者介面專家知道如何開發易於使用的介面,而您有可能在這方面不擅長。如果您從來沒有上過有關人因工程(human
factors,)方面的課程,那最好把 UI 原型開發留給這方面的專家來做。
對於 UI 原型開發讓大多數開發人員擁有共通抱怨的是,當他們的使用者說「非常好,今天下午安裝它。」時,發生這種情
況在於使用者無法理解系統需要耗費幾個月的時間在這一點上作業。這種情況的產生原因很簡單:從使用者的觀點來看,一
個功能齊全的應用程式是由功能表緊密連繫一連串的螢幕和報告。遺憾的是,這確實是原型看起來的樣子。為了避免這種問
題,您應該指出原型就如同建築師用來描述房屋設計所建造的塑膠模型一樣,它並非工作模型。
在如何對這些使用者介面項目命名時要小心謹慎,必須努力維持名稱的一般性,所以不要暗示太多有關實作的技術。例如,
在使用案例中,我不願意使用" UI23 Security Login Screen"這樣的名稱,因為它暗示我想用圖形使用者介面(GUI)技術來
實作這個主要的 UI 項目。我喜歡用"UI23 Security Login"這樣的名稱,它不會暗示任何類型的實作技術。