本節書摘來自異步社群《axure rp8 網站和app原型制作 從入門到精通》一書中的第1章，第1.2節，作者 金烏，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
典型的設計過程和需要付出的努力程度，見圖1。
當然，實際的努力程度将取決于每個具體項目的複雜程度和整個團隊間溝通協作的效率。不過，圖1給我們列出了在每個不同的階段所需的傳遞物都有哪些。
我們來進入細節，仔細檢查每一步的設計過程。我會解釋每個階段的目标，提供一些有用的提示和常用的技術，并且描述應該在什麼時候進入下一個階段。
1.2.1 研究
設計的第一階段不是設計，而是詢問一系列問題（研究），見圖2。這聽上去可能會令人驚訝，不過靜下來思考兩分鐘，你會認識到設計之初本該如此。
如果要盡可能快地開始設計，總會面臨壓力，而壓力主要來自效果。成熟的設計師、開發人員和項目管理人員都清楚研究時間是整個過程中必要的部分。事實上，這是開工的序幕。但是，當遇到以下這些情況時，即使是經驗豐富的專業人員也經常忘記第一步的重要性。他們會陷入将要設計出偉大産品的激情中（市場潛力巨大，想要盡快進入市場以尋求優勢），以至于忽略某些看上去很簡單但實際上卻至關重要的研究。在開始動工前，獲得幾個關鍵問題的答案是至關重要的。
如果是建立全新的網站或app，問題如下。
誰會使用這個網站或app？
使用者想要完成什麼任務？
網站或者app的制作者（老闆、投資人、客戶）想用它來做什麼？
網站或app中要用到什麼技術（指紋、聲音識别、nfc近場通信等，是否有技術限制需要考慮） ？
使用者為什麼選擇使用你的網站或app而不是别人的？
是什麼内容支援使用者完成目标任務或需求？
如果是重新設計現有網站或app，找到下面問題的答案是很有價值的。
哪些現有功能或複雜性正在阻礙使用者，或者說對使用者體驗産生了負面影響？
使用者或者發行者（你）發現增強哪些附加功能（或增加新功能）對下一個版本有幫助？
要找到上述問題的答案，需要掌握一些研究方法。我們的研究工作可以采取競争性分析的形式，通過采訪預期的終端使用者來確定産品具有正确的功能。
下面是一些最常用的研究技術和方法。
卡片分類
焦點小組
使用者調研
投資人訪談
設計原則
建立人物角色和使用者資料
情景調查
啟發式教育
競争分析
研究的重要性
研究的數量和品質也會直接影響到使用者的需求，還會影響到完成設計所需要的時間。
為了描述這個問題，請參考圖3和圖4。
圖3顯示了這個過程應該是怎樣工作的。在設計工作開始之前，即便沒有完成所有的研究工作，也要完成絕大多數必要的研究，這意味着一個相當明确的設計周期，設計師要明确并清晰地認識到所有需要解決的問題。第一回合的設計通常都需要一些改進，這樣安排便于随時對照項目時間表，随時進行調整，讓整個團隊成員都感覺到項目的每個環節處于可控範圍内。
圖4描述的是錯誤的設計過程，在設計前未進行充分研究，導緻項目延期。這是我的個人經驗總結，客戶（投資人、老闆）通常都不能一次性把功能和需求考慮周全，是以在第一個設計周期時可以進行适當的緩沖。向他們詢問一些必要的問題，而且在這個環節他們通常也會給出更多細節。如果看不到第一回合（階段）的設計，他們很難回答我們提出的問題。一旦他們看到第一階段設計草圖或者線框圖，他們就會變成資訊的源泉。在設計之初，有依據的步步推進是符合設計邏輯的，完全勝過空洞的想象和抽象的描述。
當通過研究得到有價值的結果很少時，就應該建立一些草圖。是以，制作這些草圖要快、要簡單，要確定讓客戶（老闆、投資人）參與這個過程。如果在沒有擷取充分資訊之前就開始第一輪設計，那我們很快就會意識到，這是在浪費時間。
在設計網站或app時，有太多需要考慮的内容。在設計過程中，如果客戶較晚地引入某個（些）功能或需求，那麼目前所有的設計可能都要廢棄，再重新制作。通過研究的徹底執行和對研究結果的書面化記載，我們能減少自己的一些痛苦，并在這個過程中甄别出客戶與使用者對産品的真實需求。然後，我們将結果呈獻給客戶和團隊，征得他們的同意并敲定最終設計方案。確定從一開始就讓每個人都參與進來，可以有效減少後期意外變動的數量。而且，當客戶在後期提出修改時，他們會明白這些請求會影響到當初所敲定的預期。這樣，如果要對時間表進行調整，就可以很自然且融洽地進行商讨。
在靈活環境中設計
一些設計師可能會發現，在設計較大的綜合性解決方案時很難與使用靈活開發方法的開發團隊合作。靈活是一個疊代的開發方法，試圖通過減少文檔數量和其他開銷來加快開發團隊的工作效率，這是一種與瀑布式開發相對的方法。瀑布式開發方法是指在産品投入市場前已經将大部分或全部産品設計完畢，這種方法需要大量的讨論和文檔，嚴重減緩産品的開發過程。雖然瀑布式方法仍在使用，但它已經是昨日黃花了，因為它的效率低下、不夠靈活。
較小的項目，在研究的初始階段不會發現太多問題。然而，大型或者複雜的項目可能是一個挑戰。在靈活環境中設計，通常要求我們開個好頭。在開發團隊需要之前，我們就要将研究結果和設計結果傳遞給他們。研究越提前，我們就有更多的時間來審查和優化工作内容。
總而言之，研究的數量和品質将直接影響和關系到我們建立的解決方案的品質。倉促的設計解決方案，不研究關鍵細節（如市場競争分析、目标使用者和使用者需求等），都意味着我們隻是在猜測成功的可能性。當然，這種情況一定要往壞處想，也就是僅憑猜測設計出的産品不可能取得成功。
不管使用什麼方法，在開發和設計方案中保證研究的時間是至關重要的。
**
1.2.2 資訊架構**
在讨論完研究階段的大量問題後，我們過渡到設計過程中的資訊架構部分，見圖5。
雖然将步驟分解成不同的階段，當要改變焦點時，自然要對研究持續一段時間。目前還沒有必要在每一步之間劃清界線。根據項目的範圍和複雜性，項目設計過程中的任何一個時間點都有不同的階段。但下面清單中的第一點是例外。我們的初始研究應該旨在獲得足夠的資訊來制定一個全面的（使用者想要在網站或app中想要完成的）任務圖。
這個階段的目标如下。
建立網站或app的進階地圖。
在每個頁面上标出發現的任務。
定義支援每個任務所需的内容。
審查并測試設計。
完善設計方案。
将使用者體驗模式規範化、文檔化。
介紹開發流程
這一階段的努力緻力于制定網站和app的結構。項目越複雜，在進入下一步之前，研究定制頁面結構和任務流就越重要。如果要建立一個簡單的網站或app，那麼對徹底調查和工作流程文檔的要求就會降低很多。無論如何，這是一個好習慣，它能幫助我們将計劃傳達給客戶和團隊成員。如果我們要建立一個複雜的網站、網站app，或其他app，這絕對是至關重要的，我們要首先制定任務流和使用者嘗試完成任務時的互動。
我們應該考慮建立一個完整的任務流程圖和産品的站點地圖，這是主要問題之一。在某些必要情況下，可以根據目前已經完成的研究，單獨制作這張地圖。某些情況下，我們要排除噪音意見，這樣有助于我們拿出建議性的解決方案。不過，我建議應該與客戶/投資人和團隊重要成員一起展開一場頭腦風暴。因為重要成員們在同一個房間裡共同讨論解決方案時，可以加快制定速度。
要列出常用的使用者體驗方法的原創者是誰是比較困難的。不過通過網絡搜尋可以得知，流程圖最初是由frank gilbrethsr[1] . 發明的，并于1921年遞交給美國機械工程師協會。frank是一個特别迷人的曆史人物，他像虛拟世界中的使用者體驗設計師那樣改善現實實體世界。他的圖表方法已經被很多不同的行業應用和修訂。第一個用于使用者體驗設計的标準流程圖方法是由jesse james garrett[2] 于2000年發明的。
定義流程圖中的形狀
如果在網際網路上搜尋流程圖形狀的意義，我們會得到成千上萬個結果，但是對形狀和線條的定義會有所不同。采納更深層次的視覺語言可以極大擴充我們的資訊量并将其融入我們的互動圖中。話雖如此，我們不必完整地采用這些圖示語言。熟悉行業中的标準流程圖是再好不過的（如标準模組化語言uml這是另外一門更加專業的領域，不屬于本書講解範圍），不過我們自定義對其進行修改也是可以接受的，隻要能清晰容易地傳達你想傳遞的資訊即可。了解任務流建立的基本原則，可以幫助我們順利熟悉并掌握這些圖示。
下面是一些常見的流程圖形狀和它們的含義，見圖6。
下面是一個簡單流程圖示範，見圖7。
這個流程圖表達的是，當使用者安裝一個app時的預期體驗，這裡的主要任務是确定使用者已有賬戶或建立一個新賬戶。
從這張圖中我們可以看出，每個矩形代表一個頁面或任務。最開始的部分是下載下傳并安裝app。文檔的讀者隻需跟着箭頭訓示就可以檢視使用者的可用選項以及他們做出決定和輸入資料之後的後續步驟。
這裡我們可以看到，當使用者被要求輸入一個已有賬戶時的體驗分支。如果他們已有賬戶，直接輸入并登入後進入使用者控制台。如果沒有賬戶，他們會被要求建立一個新的賬戶，然後他們被送到該app的教學頁面（引導頁），這裡可以看到多個頁面的教程，使用者可以選擇跳過教學直接進入使用者控制台。這裡的虛線代表一種暗示作用，觀看app使用教學是使用者的首選路徑（希望使用者這樣做），但這一步是可選的（大多數情況下，使用者體驗一款全新app的耐心是有限的，他們希望盡快使用app來完成任務或滿足他的某種需求，如果你的app不能讓使用者得以滿足的話，也許一分鐘之内使用者就會将你的應用解除安裝掉）。
這雖然隻是衆多經驗中的一個小片段，但我們掃上一眼就能體會到它傳達了多少資訊。做出分支決定是非常重要的，我們提供的選擇越多，地圖就越複雜。如果每個問題都引出更多問題，體驗的複雜性就會以指數增加。像這樣添加幾個分支問題的話，使用者體驗便難以使用文本文檔解釋清楚。即便能解釋清楚，也要花費過多的時間和腦力勞動來閱讀和了解。
曾經有一位同僚（項目經理）給我一份功能規範文檔（來自客戶），裡面的每個功能都使用文字描述，而且很詳細。雖然不是一個特别長的文檔，但我們花了半天時間來讀懂它并試圖了解它描述的過程，可惜到最後也沒有完全了解他試圖表達的過程。我們最終決定放棄繼續研究文檔，直接約見客戶面談。經過幾番讨論後，我們了解了他的目的并在談論過程中得到了一個明确的任務流。之後我們在一頁紙上繪制出了他想要的任務流，砍掉了80%的文本，并使用一個超輕量級且容易了解的文檔敲定了客戶的最終需求。
過渡到線框圖
當項目的客戶（投資人、老闆）看過我們的任務流程圖并同意這正是他們想要執行的任務，我們就該進入線框圖階段了。
線框圖是産品的基本藍圖，用來描述網站或app在每個頁面（螢幕）上的核心功能。這些線框圖會随着我們的改進越來越詳細。不過，在第一個版本中我們隻用到黑白的輪廓和形狀來暗示導航、文本、按鈕和圖像等元素的位置。這些線框圖應該勾勒出我們對整個産品的看法，表達出最初的産品設計理念。
下面附上一個網站首頁的初稿線框圖，見圖8。
如你所見，這是一張非常簡單的線框圖，可以看出，該頁面的内容所支援的任務是：幫助使用者找到他們想要的産品并了解更多資訊。
為了支援這項任務，我們建立了幫助使用者通路不同商品的“入口”，如圖中的導航和主推商品的輪播幻燈。但目前我們還不知道文本應該描述些什麼，導航欄應該包含什麼，還有圖像應該是什麼樣子。所有這些還需要更多的讨論和探索，是以我們目前隻使用一些占位符，繼續向後推進。
如果是對已有網站或app進行重新設計，這一步會變得更容易。不過，如果這是産品的第一個版本，我們不應該在一開始就考慮太多細節，這樣會擾亂我們的設計步伐。隻需想象一下頁面中需要支援任務正常執行的内容是什麼樣子，然後将其落實到線框圖中就可以了。
當我們對線框圖逐漸增加細節進行疊代時，線框圖的保真度會随之增加。随着線框圖的不斷完善，我們将越來越清晰地看到應該在哪裡增加功能或添加新的内容。我們還需要定義最優化導航模型并對内容進行分類。
現在應該與開發團隊碰面詳細介紹目前項目計劃的詳情，包括一些特殊的技術問題或比較少見的功能需求。此時，我們應該弄明白網站的優化方案中是否包含跨平台（桌上型電腦、平闆電腦、手機或其他移動裝置），也就是響應式設計。現如今，這已經成為建立網站的标準方法了。也就是說，我們要考慮在不同尺寸的顯示器螢幕上，頁面的内容和布局應該怎樣轉變。不過，随着移動裝置的興起，越來越多的設計師都在追求“移動優先”的設計方法，也就是先建立一個針對移動裝置進行優化的設計，然後再設計桌面優化版本。無論你追求哪種設計方法，在設計線框圖階段你都要考慮到響應式設計。不過，客戶需求第一，在與客戶進行詳細溝通得到确認後再執行。
最近幾年，有很多關于響應式設計與自适應設計孰優孰劣的話題。筆者建議廣大讀者不要盲目陷入無休止的争論中。牢記，目标是滿足使用者需求，而不是讨論哪項技術更勝一籌。在設計初期，使用自适應設計可以更高效地制作出目标效果與客戶進行溝通，這可以節省大量時間和精力。
可用性測試
雖然這一步經常在制作出模型之後進行，但現在是時候測試一下設計的可用性了。不管我們是使用紙原型、可互動截圖還是其他方法，盡早審查我們的想法是非常重要的，這樣可以幫助我們節省更多時間來修改。如果等到完整的模型制作出來或者完全開發完畢再進行測試的話，我們很難再去修改核心功能。如果一定要修改的話，很可能意味着我們要全部重新設計，這是極大的資源浪費，是項目中所有人都不希望遇到的糟糕情況。
1.2.3 視覺設計**
當團隊成員和客戶（投資人、老闆）對我們設計的任務流、導航和頁面布局達成共識後，就該進入設計流程的視覺設計部分了，見圖9。
到這裡，通常是建立模型（使用photoshop、adobe illustrator、sketch或其他軟體），并使用axure制作可互動模型的時候了。在此階段，應該嘗試制作代表終極産品的像素級模型了。所有的内容和圖像應該定義好并放在合适的位置上。應該強調的是，這裡所說的像素級概念是在采用響應式設計（或自适應設計）的前提下，增加網站的互動性。
視覺層的應用
如前所述，使用者體驗設計師是一個多學科的職業，一些公司發現通過招聘内容架構師可以更容易地将設計過程劃厘清晰。然後将内容架構師制作的檔案傳遞給視覺設計師，讓視覺設計師設計出視覺層。
當同一個設計師制作線框圖和視覺設計時，他可以更容易地提高線框圖的保真程度，讓同一個設計師進行視覺設計也将會對産品設計進行自然延伸和優化。然而，如果這裡的工作是分開的（由不同的設計師來做），建議給視覺設計師多留一點空間來探索視覺解決方案。一個較好的方法就是，不要标注線框圖中的部件位置、尺寸、顔色等屬性，以便讓視覺設計師有足夠的發揮空間。
在這個階段更改内容是很常見的，在優化模型時會更新文本和圖像。但是，在視覺設計階段要改變功能或增加其他特性的話，會浪費大量的時間和精力。因為在建立模型時很難再退回到線框圖階段，這意味着線框圖和模型都要重新設計，也就是你和視覺設計師兩個角色都要重新再來一次。如果是創業團隊中優化産品方案，這是很好的流程，不要嫌麻煩。但如果是個人顧問的話，這會浪費掉你太多時間和精力，你不得不重新規劃項目時間表。
如果一定要對資訊架構做出較大變化，應該立即停止模型設計，重新設計一組線框圖并與團隊成員（尤其是投資人、老闆）共同探讨，并且要在争得團隊全體人員的同意後，再重新制作模型。
1.2.4 傳遞
當我們将模型和内容都準備好後，就可以進入設計過程的傳遞階段了，見圖10。
這個階段基本分為三個任務。
優化網站或app中使用的圖像。
建立規範文檔，幫助開發人員建構設計。
評估開發完整的工作，以确認它比對設計。
最後一步是最困難的。開發成果和設計方案之間可能會有一些明顯的視覺差異。即使我們在規範文檔中注明了邊距、字距、行距和其他屬性，事情還是會略有不同。這是因為在photoshop（或其他設計工具）中，對設計的控制級别要大于在浏覽器中。雖然html5和css3提供了更多的控制，但有些細節仍然達不到你在photoshop等設計工具中的預期效果。
這是一個相當普遍的問題，我們可能将所有注意力都集中到最終結果上。我們應該讓團隊中的全體成員認識到，這是大家共同的責任，以確定最終開發出的産品與我們設計的模型盡可能保持一緻。畢竟，開發人員都是按照我們提供的文檔和模型工作的。有許多人對于産品細節和細微差别持有強硬的觀點（在網際網路浪潮中對産品細節吹毛求疵是正常現象），不過一旦産品進入開發階段這些現象會逐漸變淡。先推出最小化可行産品投入市場，接受廣大使用者的回報，然後再對産品進行調整以及細節優化。
解決這一問題的訣竅是，在設計過程的一開始就将開發人員包括在内。因為設計師與開發人員之間似乎天然存在一道屏障（尤其是當設計師完全不懂開發的情況下），畢竟開發人員“說”的是一種完全不同的語言，并且在設計過程的不同階段才融入戰鬥。盡早将開發人員包含在内，是大有好處的。
此外，我們應該確定讓開發人員（或開發團隊代表）盡早參加項目讨論，這樣便于他們決定應該使用何種技術開發項目。在讨論設計使用者體驗過程中想要的功能和特色時，也應該與開發人員共同商讨，便于他們擷取足夠的資訊來确定使用何種技術。他們會提出适當的建議，比如會遇到何種限制（如消耗開發團隊大量精力僅是為了華而不實的特效，而且某些特效會造成移動裝置硬體性能嚴重消耗導緻卡機情況發生），或者有哪些替代選擇，便于我們及時處理（筆者建議，無論是視覺設計師、使用者體驗設計師、項目經理、産品經理，都應該至少熟悉一種主流程式設計語言，熟悉并不等于可以開發産品，但這可以幫助你更深層次地了解産品，也可以更融洽地與天才程式員們溝通協作，目标是要讓項目的設計過程保持在可控範圍内）。
除此之外，在後續的設計回顧中也應該包括開發人員，這将幫助他們了解為什麼要做出某些重要決策，以及這些決策的重要性。在頭腦風暴和設計回顧環節要包含一個開發團隊負責人，這樣可以幫助我們讓整個團隊對項目在不同階段的認知保持同步，避免擾亂開發團隊的安排。
所有這些都可以幫助防止設計和開發出現大幅改動或溝通不暢而導緻的嚴重問題出現，讓整個團隊從一開始就清楚項目中任何階段的任何變化。