Windows Phone應用的設計過程
這里有一個我在使用的Windows Phone應用的設計過程。其中許多設計過程階段是傳統的，我嘗試從Windows Phone應用特別的視角來闡釋。
這篇文章是關于end-to-end的過程，所以會保持其高視角，并在下面的文章里詳細的探索每一個步驟。比如，下周我們會從理念與概念開始，關于講故事（storytelling）、草圖（Sketching）、故事板（storyboard）與低保真原型(low fidelity prototype)。這篇文章會是系列內容的軸線。但是并不確定會不會基于反饋重新定義（refine）某些階段，以及增加更多的示例。
圖表自下向上讀……
Windows Phone設計過程與其它的網站、移動app或任何設計沒有本質不同。所有的設計師重視設計過程，用他們自有的方式調整、完善設計，并改變適用于每一個項目。沒有項目是相同的，因此非常重要的是以指南（guidelines）理解設計過程而不是規則（rules）。保持靈活性（flexible）。
理解“設計”，設計不是按快門（one-shot）這類活動。你不能憑借一次嘗試既確定設計，而是像創作雕塑作品，有一個迭代過程。藝術家拿到一組大理石，他們不會從細節開始，如眉毛、指甲或者頭發。而是第一步先塑造整體的感覺，主要的體感與大塊。接著第二步定義更多的特性區塊，如手臂、胸、頭與腿。隨后有第三步、第四部與第五步。達到刻畫小細節的程度需要經過許多步驟。用戶體驗設計同理。你不能從細節開始，最終會讓你自食其果。應用程序流程（Application Flow）需要在視覺設計（Visual Design）前定義。我看到過許多類似事情的發生，他們嘗試跳過一些步驟走捷徑，而缺乏設計探索（design exploration）最終得到的是隨后項目中的暴怒。
應用主題（App Theme）
我們從應用主題開始。這個是第一個可能產生分歧的點。我只是知道應用主題對于創建接下來的階段非常重要。我注意到當開始app設計過程我們通常有兩個選擇。1，已經有一個我們想做的、非常清晰的idea；2，我們有一個目標，基于現有的API與Web Service。但兩個途徑在我看來都是錯的。如果你有一個清晰的idea，你知道你決定了自己與團隊的解決方案，但還沒有通過探索驗證。如果你決定創建一個app基于現有的API或者Web Service，你會最變成另外一個Twitter、Yelp！或者Foursquare 客戶端或者另一個從Yahoo獲取數據的股票軟件！金融或者另外一個從CNN獲得內的RSS聚合器……從Marketplace上搜索CNN你就知道我正在說什么。即使這些app有好的體驗。相信我，他們無法突圍或者為用戶做出貢獻。不要想APIs或者RSS Feeds。想想用戶體驗。所以替代的思路是”哇哦……CNN的RSS Feed是可用利用的“ ”我們如何為用戶在獲得最新與關聯且重要的新聞的體驗做出貢獻？”盡快思考這些，越早為自己與團隊打開一個新世界的探索。不再是RSS閱讀器，現在你有一個更高的目標，史詩般的任務來幫助用戶獲得更多關聯且重要的新聞。因為對象是寬廣的，解決方案是不具體的，這才是想要的點。你保持開放，所以你會探索并擁有革新的idea。替代基于APIs的思考，而基于體驗思考，如跑步體驗、進餐體驗、航行體驗，詢問自己與團隊，你如何為你的用戶做出貢獻提升體驗。注意這并不是必要地意味著解決全部的體驗……它意味著只是解決X或Y部分的體驗，用戶趨向難以發現的地方或者你看到一個機會可以幫助用戶發揮全部潛能。在隨后的開發過程中，你會選擇你會選擇API或RSS Feed從任何源，但是起點一定不是技術解決方案。最流行的Twitter或Foursquare客戶端都是成功的因為它們將體驗放在第一位——而不是API。
現在如果你已經有客戶端的app服務于特定的產品服務，或你正在移植iPhone或Android app到Windows Phone，請做好準備，針對主題進行重新定義（refine）。在許多的情況下，受制于預算或委托人，你需要直接跳到信息架構（Information architecture）階段。然而真誠地說，即便由委托人雇傭你移植一個iPhone/Android app到Windows Phone，請依然做好主題、理念與信息架構的重定義準備。事實上這不是一個壞消息，一旦你進入了信息架構與交互設計（Interation Design）階段，會得到最好的Metro設計語言：Pivots、Panoramas、App Bar、List View、Typography、布局與動畫。當從其它平臺移植app，你的工作會變成：1，理解這些平臺上的當前信息架構，并用Metro翻譯它們到正確的屏幕、內容視圖與導航。基本的事情是理解當從iPhone與Android遷移時，你不能遷移UI。你遷移的信息架構。通過思考與實踐，你會預防錯誤的轉化過程……如當人們嘗試從iPhone遷移返回按鈕（通常是屏幕左上角的按鈕）到Windows Phone……你在Windows Phone上不需要一個屏幕上的返回按鈕，因為我們有一個硬件的返回按鈕。所以，遵循思考“遷移IA”比“遷移UI”要更合適。#p#
理念與概念（Ideation & Concept）
現在你有一個主題或者任務，到了為其產生idea的時間~理念與概念階段非常有趣！——就像是在玩游戲。頭腦風暴（Brain storming）的游戲，草圖游戲講與講故事的游戲。在這個部分有三個關鍵階段：1，頭腦風暴；2，探索；3，合并（Consolidation）。概況來說，在頭腦風暴階段你產生了大量的idea，在探索階段你詳細分析與研究許多idea（但不是全部），在合并階段你決定哪些idea會繼續向前變成app一部分。只有少數的idea會存活。
完全自由的頭腦風暴
這個階段的目標是產生關聯任務的大量idea，如“貢獻酒店預訂的體驗”。想象力（Imagination）、妄想（delusion）與古怪（craziness）是在這個點上都是好的技巧。讓自己有玩的心態，思路跳出思維框架。有需多具體的頭腦風暴練習如Subject+Verbs+Objects與擴展思路的Alternate Worlds、Impossible Scenarios與In Other‘s Shoes。我們會在下一篇文章討論所提到的技術。這些游戲你可以與團隊一起參與，如果你是獨立開發者你可以跟朋友一起參與。這個階段的目標不是強迫你疑慮“你如何build或編寫這個或那個”。也不是關于這些東東長什么樣。它是關于產生idea的。在接下來的幾個階段，這些idea會落地執行。后面，就像我們知道的，有百萬個非常好的idea，但是只有一個或者兩個會被恰當執行，并且成功。#p#
探索分析/審查/測試 Exploration Dissect/Inspect/Test Ideas
在探索階段你會得到頭腦風暴中脫穎而出的idea，并需要了解更多關于這些idea的內容。你可以通過分析、審查與測試來達到目的。這個點idea剛剛出生，它們就是孩子，沒有完全的發展或成熟。然而這些idea只是頭腦風暴的一部分，也許許多瘋狂的idea在頭腦風暴過程中已經滅了——但是有一些依然存在。你可以肯定會發現你或團隊中其它人會堅信、接受并深深愛上這些idea——他們的孩子。我冒險地說這不是好事情，但同時，你需要愛上已經確定的idea，這樣你就可以把其它idea推得遠遠兒的。有些時候idea需要發展來完全的證明。如果你太快地放棄了一個idea，也許你會失去一個好的機會。幸運的是這個階段我們有4個非常有用的工具，允許我們探索我們的idea并發現優秀的種子：草圖、故事板、簡易原型與講故事。這些工具幫助開發人員與設計人員針對idea進行測試。
擁有草圖能力可以幫助你維持更多的抽象概念。故事板可以幫助你像接近皮克斯或夢工廠動畫師一樣講故事。你使用手繪與故事板展現idea的用戶體驗情景，如何通過app來提供幫助與做出貢獻。這是一個可視化的方式。原型是一個全新世界可以探索，當前重心在簡易原型。這里有幾種方式：一個是通過紙張、便條、卡片與膠帶建立模擬原型。你可以通過手動粘貼到畫布上測試情景（scenarios） 來傳達交互。這類簡易模型需要一個向導與測試用戶。這聽起來像是落伍的活動。但是它真的不是……它是非常嚴肅的。你會驚訝，你能在一張簡易原型上用15~60分鐘而不需要花一分錢，就可以收到許多反饋。在進一級的設計過程階段不會使用簡易原型，但在這個點，這是最佳選擇。另外一個做簡易原型的方式是使用Expression Blend（或者是Powerpoint或者其它的交互工具）。這個是Design Studio的Jared Potter第一次向我展示的復合數模技術。簡單的說，你在紙上畫草圖、拍照、載入圖像到Expression Blend，在頭部的可點擊區域增加透明按鈕并關聯導航欄。Done！他稱這個是15分鐘簡易原型技術，我們會在下一篇文章中講得更多。
整合產生決策 Consolidation Make Decisions
從頭腦風暴開始得到許多idea，經歷自己與團隊的探索……在這里需要整合，非常好的idea會脫穎而出。這是一個決定哪一個idea會進入app的過程。有不同的練習會幫助你的團隊縮減列表與基于優先級排序列表。這里的目標是移除盡可能多的不明確信息。這時，idea比起概念階段進一步進化，并引發更多的用戶情景（user scenarios）或者信息情景（information scenarios）。你需要帶到下一個階段的是一個基于優先級的情景列表。
信息架構 Information Architecture
信息架構階段的目標是定義信息、任務與彼此之間的關系。用戶所擁有的數字體驗：信息與信息利用的潛力——使用信息來幫助決策、獲得關于某些事情的知識、產生信息。
信息架構是一個完整的學科。信息架構的目標是制定信息規則。
在理念與概念階段產生的用戶情景包括不定型的信息，如名字、日期、價格、圖像、溫度范圍-在信息架構階段你會帶著不定型的信息并傳遞為結構化的信息。一次嘗試是不可能完成的，它需要經歷多個過程。
我們有兩個非常有用的工具可以幫助我們定義信息框架：應用程序流程表單（Application Flow charts）與低保真原型（Low Fidelity Prototyping）。
所以在信息架構進行第一次嘗試，并通過創建Flow charts進行測試。這里有不同成熟度等級，主要是從任務流程到具體屏幕+內容視圖+導航表單。記得經典軟件工程的Flow charts嗎？這就是app flow charts，它只是一個可視化術語，我們專注在用戶流程（user flow）、體驗（experience）與交互設計（Interaction design）。一旦你拿到一個flow chart，你就可以嘗試講述用戶情景（user scenarios）的故事。你會獲得反饋與idea，用來重定義信息架構，并返回完善AI文檔。這時你可以反復通過創建較高仿真的flow chart進行測試。flow charts漸漸地變得詳細，從簡單的任務flow到屏幕展示內容視圖、導航。我不稱之為高端的flow charts線框圖（wireframes），確切的說是低保真框架。
另外一個工具是低保真原型（low fidelity prototypes）。在這個點紙質原型依然有用，因為低成本。無論如何，flow charts會漸漸地更高保真。你需要打印這些app flow chart并把類似的放在一起（不再是草稿、而是打印材料）或使用Jared在Expression Blend的原型技術，用拍攝的原型圖像替代，把app flow程序呈現在屏幕上。
在最后你會有一個獨立的IA文檔，包括組織化的信息、可靠的成組flow charts與基于app flow的低保真原型。
我注意到的一件事情是，創建Windows Phone Design Process chart后，它在IA文檔接近35%的高度，占有同樣高度的是Interaction Design（下一階段）。這些chart不代表在項目中占有同樣的時間，但是我要說它著實正確的思考了IA應有的時間。如果你明確IA，會更加游刃有余。
最近的幾個星期，我們有一篇特別的文章會關于Windows Phone apps的信息框架。#p#
交互設計 Interaction Design
我們已經定義了信息架構，也就是說目標用戶可以使用這些信息。現在我們開始針對性制作用戶界面。
交互設計是什么：創建一組用戶界面與用戶體驗元素，用來驗證良好的信息架構與用戶完成信息關聯的任務。我們希望在這個階段達到的效果是傳遞信息與任務最大化的潛力發生。即使IA可能是剛剛完善，如果交互設計不能完全執行，這時信息中發生的事情就不會完全正確地在app中體現、用戶也不能完成他們想要的任務。
依照我的觀點，交互設計默認是信息與任務的過濾器（filter）。它定義的不是信息也不是任務，而是一個工具。交互設計（或用戶界面）是在用戶與信息之間的中間人。用其它的方式描述，用戶界面（交互設計的最終形式）應該是從有罪直到證明無罪，我想這個概念關聯了許多Metro法則要點：信息是展示的核心，不是用戶界面。它是決定一個好（壞）設計定義的重要因素，無關用戶界面層是薄、無形或者笨重。我們不談論視覺設計，只是交互設計：用戶基于現在發生的關系如何面對信息與任務交互。
如果我們沒有一個Windows Phone Metro設計語言可用，這時我們需要從零開始弄明白交互隱喻。在未來的文章里我會談論如何推動Metro，并給出一些idea與如何基于Metro革新，這篇文章里會重點定義交互設計與開箱即用（out-of-box）的Windows Phone Metro設計語言。
設計模式（Design Patterns），可靠的幫助翻譯信息架構到Metro控件。信息架構與任務會賦予Pivots、Pages與Panoramas以生命。信息層與架構會賦予內容視圖（Content Views）以生命。信息與信息、任務與任務、信息與任務的關系會賦予導航欄（Navigation）以生命。IA文檔的所有內容會翻譯到明確的Windows Phone控件中。最后不會出現歧義。
讓我們回顧，基于IA文檔，選擇Windows Phone已有的設計模式，例如：search、maps、email、playlists或people hub的Contact cards。這時，如你沒有找到一個完整的設計模式，或者根本不能滿足你的IA需求。那么你可以定制一個接近或者創建全新的設計模式。當定制或創建自有設計模式，你有三個好的工具：1，Windows Phone設計網格；2，不同尺寸標準的Typography來傳達結構化信息；3，Metro控件。當然，這三個不是所有你可以可用的武器，但它們是最基本的。相信Windows Phone用戶體驗指導（UX Guidelines）會cover到你的安排。
我提議通過設計模式來設計Windows Phone app。這不是唯一的設計Windows Phone Metro app的方式。像我們前面提到的，我們會在隨后的文章里談論關于推動Metro的設計模式，但在這篇文章重心在Windows Phone Metro語言設計。如果我們明確，從我的觀點，我們可以創建自有的設計模式，可能一點都不像Metro控件庫只是隱喻接近（但仍然基于Metro設計法則）。
你可以在Photoshop format（ListView_PSD.psd）找到許多列表視圖設計模式，全景板圖（Panorama_PSD.psd）以及其它控件。我們會延伸更多的內容。
經過選擇設計模式，定制并創建設計模式，你基本上設計了app。聽起來很簡單！其實不是，事實上只是選擇了正確的設計模式，定制了它們的工作區塊。我發現Windows Phone設計工作室投入了超過2年加工與展開Windows Phone體驗與UI。設計模式是非常靈活與廣泛的。經過在Windows Phone Design Day回顧將近200個app，我相信它們當中90%使用已有的設計模式與定制設計模式。當我開始我在設計工作室的工作，我對Metro并不熟悉，我的印象是它很漂亮但所有app都看起來很像。現在我在這里寫給你的是關于再利用（re-using）已有的設計模式設計整個app做出改變？是的！我印象里6個月前，在Windows Phone中所有的都是Pivot與Panorama時代。但是我發現經過6個月，許多Windows Phone app比僅使用一個Pivot或Panorama更豐富。所有的事情是相通的。這三種類型的屏幕依次主導了app中無限量布局的可能性。這是app之間區別的地方。定制Panorama面板的可能性、Pivot頁面的無限量。Windows Phone app使用的Metro設計語言可以非常豐富與獨特。像“如果背景不是黑色就不是Metro”的迷信不是真的。請查看Mike K的這篇文章或者Core77的Windows Phone設計辯論。
其中一件重要的事情是以不同的格式生產大量設計模式：Photoshop、Illustrator、Expression Design與XAML。現在，市面上沒有大量的設計模式，所以推薦使用手機當前的內置，同時我們這邊也在大量工作更多的格式將會投入使用。
返回開始，設計模式的選擇、定制與創造階段會呈現在線框圖（Wireframes）。線框圖是灰度圖。不是色彩的！沒有品牌……也沒有panorama背景！這些線框圖理想情況下是由Expression Design、Visio、Photoshop與Illustrator創建（提醒我們應該提供Visio格式的設計模式）。
我們已經準備轉移到下一個交互設計階段：定義動畫風格與UI控件規格。實際上，這些概念會跟隨之前選擇的設計模式。最后，設計模式在這個語境（context）是交互設計模式，而不只是視覺設計模式。
動畫風格會幫助我們基于線框圖指明，會有動畫出現在從A到B屏幕的轉化過程（旋轉風格），何時顯示列表項目的詳細內容（飛出飛入Continuum）。動畫是Windows Phone app的重要部分，所以我們設計使用的動畫風格的要點規格時會非常挑剔。與此同時，UI控件規格同樣需要基于線框圖，所以開發人員知道當創建一個app時，鍵盤類型需要基于輸入的用戶體驗。或者當有通知（notifications），我們需要顯示內容A、B、C通知消息內容的規則，通知在哪里會帶你進入app。對于Loaders會發生同樣的事情……我們需要一個%的loader還是一個等待光標？
在這個階段的最后，針對完整的app，會有可靠的一組線框圖，由開箱即用的定制與自主創建的設計模式驅動。這些線框圖會包括動畫風格與UI控件規格。準備下一階段：視覺設計！
視覺設計 Visual Design
目前為止，你會想：什么，到最后才有視覺設計？！。像我之前提到的，設計過程（任何事物）不是線性的。要是像我一樣，我會開啟Expression Design（你可能會使用Photoshop或Illustrator）我會把額外的事情丟一邊并開始工作，我喜歡這樣，用我喜歡的工具并開始app設計。沒有草稿、沒有線框圖，只是漂亮或純粹的視覺震撼！——許多視覺設計師想的就是這個味兒（就像工程師直接跳到Visual Studio開始敲代碼！）
我必須承認比起一個交互設計師我更是一個視覺設計師。我肯定會依靠它看起來如何引導自己，所以我在項目的初期被視覺設計所吸引，但是我必須控制自己并記住有一個設計過程如何我跳過了，我的設計最終會非常漂亮但是不能忠實地表現app如何工作的信息架構與交換設計需求。也就是說，我們知道看起來受歡迎與我們都做過在過程的早期被客戶詢問發送給他們app的設計。明確開始的視覺設計是徒勞無功（雖然有些客戶喜歡說要的就是這個）但是更像是“售賣設計”。
盡管我們喜歡信息架構與交互設計，為用戶、商業決策制定者或市場管理者，然而一圖勝于千張AI（an image is worth a 1000 pages of IA）。一組漂亮的Windows Phone app會幫助人們購買這個app與產生更多購買，給團隊boss的進度報告會看起來漂亮。其實就是這樣。所以當IA沒有完全確定或交互設計被定義時，視覺設計引導人們在項目早期，最好的想象并最終實現。許多次人們會想這個愿景是最終的產品。但事實不是，這只是試圖展示了我們方向在哪里。問題既是團隊或客戶信奉這個早期的視覺設計做為方向。期望應該被規定，這樣在隨后項目中就不會失望，因為它后于IA與交互設計，你可以完全的認識到視覺設計。
所以，現在我們有IA與交互設計明確時間來做許多有趣的視覺設計活動，像定義調色板（color palette），設計自定義圖標、背景、整合品牌到我們的體驗與設計live tiles。
你是否知道有一個有關設計的經典對話關于是否開發人員應該做設計？自始至終，對于這點我認為一個開發人員即使沒有正式在設計方面訓練可以成功的做到。信息架構是一個系統化與結構、邏輯驅動的學科。我個人認為開發人員有正確的思維模式明確IA。交互設計需要更多的體驗，這是交互設計在過程中擅長的地方，但是一個開發人員沿著設計模式，我想他肯定可以做正確。這個階段的挑戰在于當前的設計模式缺乏與恰當的工具來實現方法、挑戰，這增加對沒有正式設計訓練的人們的困難程度。最后，視覺設計階段，我想你最好雇傭訓練有素的圖形視覺設計師。雖然有相當數量的設計教程與有版權的圖標、圖像與其它元素，但它與雇傭一個訓練有素的設計師絕不一樣。我希望我們可以在后面的文章，提供給開發人員許多實用的技巧，將基于素材的視覺設計元素變得更好。#p#
紅線與綠線 Redlines and Greenlines
什么是Redlines？什么又是greenlines？！簡單的問題。他們是交互體驗的藍圖。就像是建筑的藍圖，你可以在上面看到樓梯平面圖、側視圖、建筑正面，通過標注尺寸，門有多大、窗戶有多大、墻的厚度、水管通道經過的地方、電源出口坐標、樓梯有多高、樓梯采用的材質、涂料顏色等等……在交互設計我們同樣有我們的藍圖稱作紅線。我不確定為什么它們是紅色而不是品紅……但是我們想是因為紅色是經常看到的顏色，容易跳出來，所以UI標識尺寸容易讀。屏幕上的redlines顯示了一個app不同屏幕，頂部不同成串的測量。這些數字定義了外邊距（margin）、內邊距（padding）、元素的大小與短暫元素如狀態欄。為什么我們需要redlines？我通過Expression Blend就可以解決問題！
很久前在設計過程中我們沒有Expression Blend。我知道這會引發一個很長的討論，所以我在個系列保留了對這個設計工具的細節。我會說不管怎樣，對于設計師控制UI到不論誰拿到XAML格式的UI，redlines都是最好的表現技巧。這個人可能叫做整合者，另外一個用XAML或Blend的設計師或開發人員。不論是什么情況，拿到設計與設計app的人不是同一個人。團隊仍然可以工作。所以這個人需要一個方式用XAML產生UI與redlines幫助實現。通過redlines就沒有歧義，但是如果這個按鈕是30×150像素，距離屏幕左邊24像素，距離頂部427像素，這時這些尺寸就是位置。不需要討論。在過去，沒有redlines，設計師會設計網站并轉換JPG素材（不要使用JPG、只用PNG、沒有壓縮）給其他人產生HTML與CSS。這個過程會破壞設計，結果會與最初想象不同。Redlines表現了“契約”，一個當事人雙方都同意寫好的文檔！我們會在未來的文章討論更多的redlines與如何創建。
Greenlines是什么？Windows Phone設計工作室定義為觸摸區域。需要按鈕會說，10像素的直徑，但是它們的點擊區域會是20像素（便于用戶點擊）。Greenlines指明這些點擊區域，不論它們匹配的物體大小。Greenlines與Redlines傳遞不同的信息。
