業(yè)界 NG 率：90%

如果把 wireframe 畫得如此精美，你將立即面臨三個負面后果：

但實務上，小型項目花太多心力去做這些事基本上是缺乏成本觀念的表現(xiàn)，在使用者數(shù)量達到一定門坎前，數(shù)據(jù)分析的母體也是小得可憐，并無統(tǒng)計的參考價 值。因此，小型項目其實可以將功能拆分 Release，先做出來再觀察使用情形并修正細節(jié)（雖然有一點危險，但比起讓項目永無結束之日，總是較適當?shù)倪x擇）。

嚴謹執(zhí)行設計流程

建議：如果你是就讀設計科系的大學生或研究生，我會建議你選修計算器概論、基礎數(shù)據(jù)結構，這些都會對 UI 設計非常有幫助。

但事實上這種刻板印象除了阻礙你進步以外可說是一點用都沒有（而且不見得是正確的）。

了解工程實作的基本原理

調整前

將拍攝格式設置為JPEG，相機會在拍攝的同時處理畫面顏色與影調，然后將文件壓縮保存。盡管我們依舊可以使用Photoshop對這樣的照片進行處理，但是很有可能讓壓縮導致的色塊變得更加明顯。如果在拍攝時，和我們的例圖類似使用了錯誤的白平衡設置導致畫面色彩不夠自然，那么就需要耗費更多時間校正偏色。

業(yè)界 NG 率：80%

1. 正確稱呼 UI 組件

許多人認為創(chuàng)造力和邏輯是左右半腦分開管轄的、設計師和工程師使用的是不同部分的能力，所以大家各安其份做好自己的工作就好——我負責光鮮亮麗地畫圖，工程師就負責用超大聲的同刻鍵盤在黑色的屏幕上編寫外星文。

在設計的 wireframe 階段，主要目標是讓大家對于畫面上「有哪些對象」取得共識，而不是這些對象「該長什么樣子」，那是 mockup 階段才要注重的，因此將 wireframe 畫得過于精美是一件非常奇怪的事情，例如這樣：

先以原生 UI 組件表意

有彩色稿的外型構造，卻沒彩色稿的色彩系統(tǒng)輔佐，導致大家無法完整理解你「精心設計」的 UI 對象。

啟動Photoshop，執(zhí)行“文件>打開”命令，在彈出的文件瀏覽器窗口中找到你想要修飾的RAW格式照片。教程中使用的是.DNG格式文件，它會自動在CameraRaw中打開，我們將在這兒完成照片的全部調整工作。

又例如 Status Bar：

我看過太多設計師為了設計感而給 Status Bar 著上前景色（Foreground），讓它變灰甚至變成彩色，又指責開發(fā)者這么單純的事都辦不到，其實 Apple 在文件里寫得很清楚，這個東西你就只有黑或白色可選，像這種就是你不該做的效果。

之前和一些公司合作的過程、以及和朋友聊天的時候，我發(fā)現(xiàn)一個團隊在設計流程上草率帶過的情形比想象中還多。一般來說我會建議中小型項目采取以下流程來執(zhí)行設計：

有些講得一口好設計的人會不食人間煙火、一味地倡導要從使用者調查研究（User Research）、Persona 開始做起，然后實作 n 多個原型（Prototype）才開始讓開發(fā)者動手，后續(xù)再做數(shù)據(jù)分析??等工作，好像全世界只有自己知道這件事一樣。

更多影樓遠程數(shù)碼后期修片教程盡在全影網。

聽起來像外星語？白話來說，許多設計師毫無意識到某些視覺效果在工程實做面的可行性、也沒有考慮到各種裝置的運算負荷能力，而設計了大量會讓開發(fā)者面有難色的稿子，好不容易做出來了，發(fā)現(xiàn)算圖卡頓得要命，又要回頭改稿，得不償失。

這樣一來，畫面上都是大家平常使用 App 時有看過的形式，看得懂畫面的時候，就能夠專心探討這些功能是不是產品所需要具備的。

身為設計師的你，應該要...

2. 有些效果就是做不出來、很難做、不該做

這個流程是容許微調的，我在 Yahoo 實習時常看到非常大型的設計流程，而在其他小型團隊工作時則多會采取上述較簡易的版本。

以 iOS 為例子，在 Apple 的接口設計規(guī)范文件里，每個畫面構成的組件都有正式的名稱，我們看看：

將拍攝格式從JPEG換成沒有壓縮處理的RAW格式之后，我們就能等待拍攝完成再對影調和顏色進行精確調整，省去了拍攝時的顧慮。RAW文件中額外的圖像信息能給我們帶來更加完美的處理結果。

數(shù)碼后期

這玩意兒叫做「Segmented Controls」，而不是「那個長得像膠囊的選單」，如果能夠使用正確的術語來溝通，將能夠省下非�？捎^的解釋時間。如果你想了解得更多、更精確，將前述的規(guī)范文件讀熟以后，建議你再繼續(xù)研究 UIKit Catalog。



對設計沒概念的客戶、PM 或老板會忘記我們是在 review 畫面上有哪些對象，反而在這時就開始跟你檢討設計細節(jié)，等你接著做彩色稿時，才突然講說之前有哪個功能忘記擺放上去。

RAW格式為上

好了，如果你是設計師，希望這篇文章能夠幫助你在設計的溝通討論上更加順暢、省時；如果你是 PM 或開發(fā)者，也可以順便學習、或將這篇文章轉給你的設計師參考。

我們表達一件事情若要表達得精確，就應該試著減少話中的「詮釋空間」，而代名詞的使用非常容易造成設計討論上的時間浪費，例如「這個」、「那個」之 類的詞匯，在專業(yè)討論上應該減少使用；取而代之，你應該使用本篇文章第一節(jié)所提到的精確名詞來表達，或是詳細描述你所指的外型。

所以設計師懂工程實作原理要做什么？該懂哪些部分？很簡單，你不需要學會怎么寫 code，但你至少需要懂得：

3.裁剪畫面

2.裁剪工具

少用代名詞

其中第二點是本節(jié)的重點，在你的 wireframe 里，應該使用系統(tǒng)原生的對象來構成畫面，例如這些東西：

要如何微調呢？基本上不建議省略其中的步驟，但在上面綠色箭頭處可以減少迭代的次數(shù)來達到省時的目的，而這部分就會稍微考驗到產品設計師、PM 的經驗和 gut feeling 了。

在拍攝玩耍的小孩時，我們經常會使用相機閃光燈為陰影區(qū)域補光，另外還會根據(jù)現(xiàn)場的光線條件將白平衡從日光調整為陰影，使畫面看上去更加溫暖。但是當小孩子從陰地方走到太陽下的時候，上述設置突然就變得不合時宜。想在小孩子玩得正開心的時候抓住他們最自然的表情，本身就已經很難，更何況還要為相機的設置手忙腳亂。

我們將告訴大家如何使用CameraRaw編輯器提亮畫面中位于背光區(qū)域的小孩面部，在不出現(xiàn)瑕疵的情況下最大程度還原細節(jié)。這個過程中大家還會發(fā)現(xiàn)，校正畫面色偏、還原自然色彩其實只需要點擊幾次鼠標就能辦到。

最普遍的例子：自從 iOS 7 引入帶有模糊效果的設計語言后，大家似乎都染上了高斯模糊的癮。但這樣的效果非常耗費系統(tǒng)資源（原理及時間復雜度），就連 iOS 也到了來年的 iOS 8 才心不甘情不愿地開放使用 UIBlurEffect API，免得第三方 App 一堆模糊效果拖累系統(tǒng)效能；而在 Android 上官方更沒有提供像 iOS 如此方便的 API 可用（有錯請不吝指正）。

這個溝通技巧不難做到，但如果沒有人指出，是很難自己發(fā)現(xiàn)的。

浪費時間，徹底的浪費時間。

1.打開文件

請避免在非必要的狀況下急著在 wireframe 里畫一些從來沒有人看過的「創(chuàng)新 UI」。一個好理解、直覺的設計是所有細節(jié)相輔相成的，在 wireframe 的階段缺少了顏色和動態(tài)效果的輔助，更不該冒險呈現(xiàn)特殊的對象外型，也就是說，你的 wireframe 頂多做到這樣就該收手：

在開始調整照片的顏色與影調之前，有必要先對畫面構圖略作改進，省得我們把精力耗費在最終可能被裁掉的區(qū)域上。從上方工具欄中選擇裁剪工具，在畫面上單擊右鍵，勾選顯示疊加設置選項，在裁剪時為我們提供必要的構圖指導。

巴別塔的故事大家?guī)缀醵悸犨^，會造成溝通問題的原因很簡單，就是講的「語言」不同，而非思考方式不一樣——無論是什么領域，要成為佼佼者，都必須具備高度的創(chuàng)造和想象能力，而設計更是非常講求邏輯的行為。

業(yè)界 NG 率：接近 100%

業(yè)界 NG 率：60%