創(chuàng)建網(wǎng)站視覺稿（mockup）有很多種方式。當(dāng)然這并沒有所謂“最好的”方法，但依據(jù)部分UI和UX設(shè)計師的風(fēng)格與偏好（以及設(shè)計流程），我們可以總結(jié)出幾個相對比較好的方法。

本文將介紹幾個視覺稿工具、圖表設(shè)計工具，以及與原型十分近似的編碼的視覺稿的優(yōu)缺點(diǎn)。

01. 使用專門的工具

使用UXPin或者M(jìn)oqups 、Balsamiq 這樣的解決方案，能夠?yàn)槟闾峁﹦?chuàng)建視覺稿所需要的一切，讓整個流程變得簡單。這些工具的存在，就是為了讓創(chuàng)建過程盡量簡單，這樣你就可以把時間和精力花在風(fēng)格

UXPin這樣的工具能讓你輕松快速地創(chuàng)建視覺稿

資深專家和初學(xué)者都喜歡使用視覺稿工具，初學(xué)者在意的是它們的簡單易用，專家欣賞的是專門針對高級需求定制的設(shè)計。

比起用于線框圖和視覺稿的其他非設(shè)計類工具（比如Keynote ），Moqups和Balsamiq的功能更為強(qiáng)大，但也僅限于低保真設(shè)計。當(dāng)然，如果原本的目標(biāo)就是快速創(chuàng)建低保真線框圖，這些工具是非常實(shí)用的。

視覺稿工具其實(shí)大部分是針對線框圖的。通過內(nèi)置協(xié)作，UXPin提供了數(shù)十個元素庫來節(jié)省時間，這樣就可以通過簡單的拖拽和自定義來創(chuàng)建視覺稿。

02. 使用平面設(shè)計軟件

有的設(shè)計人員習(xí)慣使用Photoshop、Sketch或者Illustrator這樣的工具，尤其是那些對于那些可以精準(zhǔn)控制到像素的工具非常熟悉的人。如果你追求的是高水平的現(xiàn)實(shí)主義和視覺保真，平面設(shè)計平臺是很好的選擇。

平面設(shè)計軟件中，你可以訪問無數(shù)的高度界定的顏色，因此，如果你被要求使用預(yù)設(shè)的配色方案--比如說由于品牌形象的限制--那么這些軟件可能是你最好的選擇。除了顏色選擇之外，這些軟件還提供更多的視覺工具，可以幫助用戶解決一些細(xì)節(jié)問題。

然而，使用這一類軟件的缺點(diǎn)是當(dāng)開始編碼設(shè)計時，可能會遇到難以轉(zhuǎn)換的問題。在Photoshop中正常的功能可能并不總是適用于代碼（諸如字體、陰影、漸變效果等元素），這可能會在原型設(shè)計階段花點(diǎn)時間來找出解決方案。

學(xué)習(xí)如何在Sketch中創(chuàng)建視覺稿

如果你設(shè)計的是一個樣式復(fù)雜的頁面，最好能在設(shè)計視覺稿的過程中敲定具體的視覺細(xì)節(jié)（這種情況下，Photoshop和SKetch這類的工具能為你提供更多的選擇）。

看看Hubspot上最美主頁的名單，你就會理解為什么早一點(diǎn)處理視覺細(xì)節(jié)會更好。類似的，如果你正在接洽的是一個挑剔的、難以取悅的客戶，向他們展示一個美觀大方的視覺稿可能會幫你獲得客戶的青睞。

在Photoshop或Sketch中創(chuàng)建的視覺稿可以拖放到免費(fèi)的UXPin應(yīng)用程序中

值得一提的是，Photoshop或Sketch中創(chuàng)建的視覺稿可以通過UXPin拖拽至原型設(shè)計階段。這能讓你輕輕松松幾個點(diǎn)擊就能將操作所有圖層，并確保你不需要從頭開始做原型。

如果視覺不是你唯一的優(yōu)先考慮，使用一個能處理線框圖、視覺稿和原型的工具會更有效率。除非你追求的是最右的視覺效果，那么使用平面設(shè)計軟件來做視覺稿帶來的麻煩要比便利多--所有一定要定期與開發(fā)人員聯(lián)系，因?yàn)檫@些工具并不是為了協(xié)作而設(shè)計出來的。

03. 視覺稿編碼

對于初學(xué)者來說，如果你的職責(zé)更多的是設(shè)計人員，并不擅長編碼，那么這個選擇顯然不適合你。編碼視覺稿并不是一個默認(rèn)選擇。

大多數(shù)編碼工作都可以等到原型開發(fā)階段（如果是HTML/Javascript原型）或者更晚（如果使用原型設(shè)計工具）。盡管有其復(fù)雜性和潛在的障礙，但許多知名設(shè)計師都主張在視覺稿階段就引入編碼工作。

在HTML中構(gòu)建結(jié)構(gòu)，然后在CSS中進(jìn)行基礎(chǔ)布局，能夠簡化整個開發(fā)流程。至少是在理論上。很多人會爭論，說在視覺稿階段集中精力做視覺方面的工作能夠節(jié)省將來花在決策和結(jié)構(gòu)上的時間。但那些支持在早期引入編碼的人則認(rèn)為，如果代碼先行寫好，后續(xù)的一些數(shù)學(xué)上的變化，比如大小的調(diào)整等，就會很簡單。

Ash Maurya擁護(hù)HTML/CSS路徑來創(chuàng)建視覺稿

編碼模型的大支持者之一是Spark59的創(chuàng)始人兼首席執(zhí)行官Ash Mauria。在描述他喜歡的創(chuàng)建視覺稿的方式的時候，他擁護(hù)HTML / CSS路徑，并提出了一些不錯的觀點(diǎn)：

可行性：僅僅為了好看而設(shè)計的“華麗的”視覺稿在轉(zhuǎn)換為代碼時比較困難，由此會造成時間和精力的浪費(fèi)。漸變、字體與效果等元素--在其他工具中很容易實(shí)現(xiàn)--在編碼時可能會很難處理，甚至無法重現(xiàn)。從代碼開始能讓你能馬上知道自己能做什么不能做什么。

快速迭代：Maurya表示，通過簡化迭代流程編碼實(shí)際上能夠節(jié)省不少時間。當(dāng)然，也有人認(rèn)為這拖延了設(shè)計決策，實(shí)際上增加了工作時間。

最少的浪費(fèi)：“在產(chǎn)品交付的最終技術(shù)以外的其他任何產(chǎn)品中創(chuàng)建視覺稿都會造成浪費(fèi)。”因?yàn)檫@個視覺稿最終都會在HTML / CSS里，Maurya建議增加保真。

但就像我們先前說過的，視覺稿編碼并不是常見的策略，而原因并不是編碼工作的難度。過早地開始編碼可能限制你的創(chuàng)造力及進(jìn)行實(shí)驗(yàn)的意愿，因?yàn)槟銜?dān)心創(chuàng)意在代碼中的可行性，而不是它看起來會多好。

何時引入編碼工作取決于你。只要你先了解設(shè)計流程的輕重緩急，并及時告知開發(fā)人員你制定的優(yōu)先排序。