- 原文地址:A Beginner’s Guide to Rapid Prototyping
- 原文做者:Anant Jain
- 譯文出自:掘金翻譯計劃
- 本文永久連接:github.com/xitu/gold-m…
- 譯者:Ryden Sun
- 校對者:Ivocin
照片由 Denise Jans 提供於 Unsplash前端
從一個想法到完整的產品,過程是複雜的。每個想打造本身產品的人都應該具有原型設計的能力,經過原型得到反饋,而後不斷進行迭代。這也是 UX 設計師工做中的重要一環。android
原型設計有不少種形式,從紙上簡單的草稿到看起來像最終產品的交互模擬,都屬於原型範疇。這篇指南是寫給那些想理解原型全部相關方面知識的初學者的。ios
咱們除了會講到一些快速原型設計相關術語的含義以外,還會有如下這些方面:git
快速原型設計是一個不斷迭代的過程,將網頁或者應用可視化,以此來得到用戶,利益相關者,開發者和設計師的反饋和承認。github
當使用的好時,快速原型設計能夠經過增強多方溝通,避免製做出一個用戶不喜歡的產品,以此來提升設計的質量。後端
原型設計並非一個系統的完整功能性版本,它只是被用來幫助可視化最終產品的用戶體驗。就像谷歌 Ventures design(風險投資設計, 一種用設計入股創業公司的方式) 合夥人 Daniel Burka 說的:api
一個理想的原型應該是 「Goldilocks」(金髮姑娘,用來形容完美平衡,剛恰好)般的質量。若是原型的質量太差,人們不會相信這個原型是一個真正的產品。若是質量過高,會致使你沒日沒夜的工做,而且你完不成。你須要一個 「Goldilocks」 的質量,不須要過高,也不要太差,剛恰好就行。app
你不只能夠爲屏幕,移動應用或者網頁進行原型設計,甚至說是任何東西均可以進行原型設計。原型設計能夠極好的測試如下方面(提供了案例):框架
因此,你如今知道快速原型設計是幹什麼的了。可是你怎麼來作呢?咱們後續會講到。ide
快速原型設計包含了一個 3 步走的流程,根據需求屢次迭代:
原型,評審,改進,迭代。
一個原型一般是從一個簡單的模型開始,只涵蓋關鍵點,隨着用戶反饋的數據收集,經過每一次迭代變得更加完善,複雜。
集中精力在那些關鍵的功能,這些功能是用戶最常使用的。快速原型設計的意義是,在不須要規劃整個產品細節以前,展現一個功能是怎麼工做的,亦或是它看起來是什麼樣的。謹記,咱們的目標是 「Goldilocks」 般的質量!
一次性對整個 用戶流程 進行原型設計。比起一個界面一個界面的設計,原型設計應基於一個用戶使用場景,這個場景包含全部你想進行原型設計的區域。經過這種方法,你會獲得更精準的用戶反饋,由於你的原型會切實的反應用戶真實生活中的場景。好比,將「註冊/登錄/重置密碼」一套流程進行總體原型設計。
除此以外,要記住,心中要有一個迭代計劃。按經驗來講,製做迭代計劃時要從全局入手,而後超更細節的解決方案版本入力。隨着你不斷迭代,原型的保真度和所包含的內容,都會不斷增加。
可是稍等,什麼是保真度?
保真度是指原型與最終產品或解決方案的類似度。你能夠從不一樣等級的準確度中選擇,根據目前流程的階段和原型的目標來選擇。
佈局和設計是原型保真度中最顯眼的部分。若是一個原型從開始就保持高視覺保真度的產出,用戶會傾向集中於視覺,而不是功能細節,這會偏離早期階段原型的主要目標。
靜態原型有兩種保真度 - 草圖(低保真)和設計稿(高保真)
原型是靜態仍是必需要看起來支持全部功能(可交互)?兩個版本都有好處和壞處:靜態原型能夠更簡單快捷的實現,然而可交互版本後續可被用來作可用性測試和用戶培訓。
一個高保真的可交互的原型。 (來源)
原型的早期階段,使用統一的固定文本內容能夠有效的避免用戶從提供功能性反饋中偏離,而不是對文本內容進行評論。
然而,隨着原型設計的流程遞進,用實際內容來替代冗餘的文本,這樣用戶能夠感受到總體設計的影響。
使用實際的標籤也是一個很好的機會來測試你「複製的內容」的工做效果。複製對於文本空間和屏幕中信息是一個美妙的術語,就像咱們把「發佈」按鈕叫作「發佈」,「發表」,「發送」,「完成」或者其餘的叫法。
從低保真,到中保真再到高保真 (Source)
大多數時間,設計方案的最佳探索方式是從粗略的草圖開始,而後根據系統的複雜度和需求,遷移到更高的保真度。
有些時候,你的選擇多是由客戶需求或所關注的領域所指引。好比,若是你想評估一個界面改動所形成的視覺影像,相對於粗略的草圖,你可能會選擇一個視覺設計稿。或者若是你的解決方案時關注於消息的,你可能會決定使用真實的內容而不是統一的固定文本。
根據你的需求和方式有不少可用的原型設計工具。選擇工具以前,你要問清楚這些問題:
紙筆,Sketch, Figma, Framer, Photoshop, Illustrator, XD, Origami 等等
若是你好奇應該如何測試你的原型,能夠閱讀個人另外一篇可用性測試的文章:
**極致 UX 體驗背後的祕密:可用性測試 **:不管是一個原型仍是一個徹底成熟的產品,進行幾個月的長時間可用性測試都是很好的選擇
感謝閱讀這篇指南。這篇文章最初是做爲 Commonlounge 上的 UX 設計課程其中一部分發布的,這個平臺有不少小型課程,話題從 Django 涵蓋到 Machine Learning,可讓付出的時間獲得最大的回報。
經過在真實世界的項目上工做進行學習,而且從產業導師身上得到反饋,盡在 commonlounge!
若是發現譯文存在錯誤或其餘須要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。
掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。