交互設計師的產出物是什麼？
如何輸出設計文檔
前言：認真翻了過去一些年做過的交互設計稿，希望能寫一篇交互設計輸出的文章。一來，現在在德國出差工作，客戶對設計文檔要求很高，帶來一些思考與回憶；二來，知乎的小夥伴們要了很久要看我之前的設計稿。所以一併寫出來。：）
設計文檔輸出方式很多。交互設計輸出可以使用PPT、Axure、InDesign、AI等工具。各種工具各有好處。我自己最喜歡的組合是：
Omnigraffle、InDesign、Keynote
Omnigraffle快速搭建交互、InDesign做精細完整文檔、Keynote做設計講解與設計回顧。
先來好玩的。年輕時候的輸出。
這是我在華盛頓美國聯邦貿易局短期實習做的一個項目。簡單來說，就是政府有很多紙箱子，紙箱子裡面有重要文件，一旦出現水災怎麼辦？需要設計一個流程來幫助工作人員處理水災這個緊急情況。這是我在學校之外實際工作第一次畫稿，勉強算是交互稿吧，用的是Visio。這個時候主要是在學習如何講思路。結果美國政府的小夥伴們還蠻喜歡的……
然後到紐約實習，在愛立信移動部門工作，繼續用Visio，跟著資深設計師畫這樣的交互稿。這個時候主要是在學習如何處理複雜流程。個人不太喜歡交互設計輸出要這麼複雜。
在愛立信也開始學慣用Axure來做移動網頁的流程圖。當時是視覺設計先做好，再讓我拼成可點擊可操作的流程圖。因為Axure上手簡單、交互性強，所以我開始喜歡用Axure。
返校後研究生二年級邊讀書邊實習，在學校發展辦公室設計網站，也畫過比較土的網站結構圖。
畢業後到西雅圖AOL實習，繼續用Visio釋義流程圖。
在AOL迷上用紙張來做交互稿。當時用剪紙、塗色、拼搭來形成交互場景描述，很有樂趣。從那個時候開始喜歡Paper Prototyping。
以上是我設計輸出亂七八糟階段，嘗試了不少東西，直到正式工作開始。
記得到雅虎的第一天，老闆給了我一台MacBook Pro，說：「好了，從今天開始用Mac，設計文檔輸出工具是InDesign」。除了在學校寫論文，我沒有用過Mac，我也沒有用過InDesign，Mac系統那時候好像沒有Visio。我想，完了，這是上班第一天就要丟人的節奏。
老闆一步一步教我熟悉InDesign文檔，我第一天就開始幹活，要更新30個移動搜索的特別展示項。出乎意料，InDesign沒有想像中那麼複雜。
Mac配合InDesign，全新的交互輸出生活開始。一切都改變了。
InDesign有兩種使用方式。
第一種是直接在上面畫交互稿。設計師可以定義每個欄位、圖等元素的樣式，然後使用樣式輸出效率非常快。例如，有一個100頁的設計文檔，每個頁面有5個手機界面，整個文檔就有500個手機界面。每個界面可以復用的元素很多，例如header、footer、欄位、圖片等，每個元素都有樣式。交互輸出走樣式的方式非常快。
舉個例子，雅虎有一次設計大改。以前的搜索結果中鏈接是藍色，俗稱blue links。公司覺得在手機上，鏈接改為黑色比較好（後來又改回來了……）。所以我們設計團隊要改這個鏈接的顏色。
當時我在InDesign樣式里，把「link」這個我之前定義的樣式從藍色改為黑色，然後超過100頁文檔的所有界面里，鏈接都變為黑色了。隔壁某團隊做另外一塊垂直類搜索，用Photoshop出圖再生成設計文檔，改了一個星期……
InDesign的第二種使用方式，是更精細的設計文檔。把PSD源文件放置到InDesign文檔中，這個好處是Photoshop生成的圖片已經視覺到位，放在文檔里非常好看。
一定記得，要用Place這個功能把PSD源文件直接導入到InDesign做設計文檔的元素。好處是，例如你做好一版設計文檔，有後續迭代改動時，交互流程的改動，就在InDesign裡面直接改，如果是界面的改動，你可以直接改PSD。然後你刷新一次InDesign，InDesign里所有Place好的PSD全部都自動刷新，超級方便。所以要保持好習慣，一般我是一個文件夾里有InDesign文件，旁邊有一個PSD文件夾，為了保持指向性，文件夾別亂挪動。
師傅領進門，學藝在個人。InDesign會用了，就要思考怎樣才能用的更好。大家都知道交互流程複雜的產品，一頁InDesign很難放下很多圖。兩個解決步驟：第一，把總流程單獨拿出來放前面，展示整體流程；第二，把整個產品邏輯進行場景細分，把一個大故事講成很多個小故事，一個小故事放在InDesign的1-2頁講完。這個方法可以適用大部分To C的移動產品設計。
用了Mac後，開始使用Omnigraffle。這個工具是InDesign很好的補充。InDesign有一個缺點，維護起來需要認真有耐心，有點耗時間，雖然用熟悉了也很快，但是不適合快速建立交互模型。Omnigraffle就是快速交互設計的最好工具之一，我的最愛。後面我會講用Omnigraffle做交互設計的例子。
回到把大故事講成小故事的話題，講一些有趣的例子。
這是在ATT工作時，我老闆的設計文檔。
放大一點。
思路很清晰，看起來卻不太方便。用上述討論的方法進行場景拆解後，是這樣的，得到當時洛杉磯所有產品團隊的喜歡。：）
久而久之，就慢慢形成了自己的設計文檔風格，用起來也是很開心。InDesign文檔初建的時候，記得適應A3的尺寸。把InDesign生成的設計文檔列印出來，在各種評審會上可以保證這個設計文檔是賞心悅目的。
接下來說一下Omnigraffle做交互輸出。這個工具開始用上手就比較快，當你經過幾次項目積累了自己的控制項庫後，輸出基本是神速。
一個例子，YP iPad這個產品我記得兩周做了10次以上的創意，每次都是交互的大改，Omnigraffle幫助我快速出稿，每次更新只要半天。以下是我用Omnigraffle做的設計文檔的部分頁面。快速搭建的交互，簡單直觀，讓產品設計流程各個角色輕鬆快速理解設計思路，粗糙一些也沒有關係。
這個快速輸出的風格一直延續到我現在的工作。下面是在騰訊的時候做移動應用中心的快速輸出，產品討論加兩次改動刷新半周時間就搞定。
在華為的時候，更忙一些，所以我一般先在紙上簡單畫交互框架，再使用一樣的文檔輸出方式。華為信息安全很嚴格，設計稿就不放啦。
設計文檔可大可小。小的也許只有兩頁，但是文檔的詳細完整可以幫助設計文檔沉澱傳播很久。
例如我之前做的一個設置默認搜索引擎的簡單交互文檔，從美國跑到歐洲一年後又跑回來，一直用得很好。
大的設計文檔可以作為一個產品所有亮點、細節、記憶的真實記錄，這是雅虎搜索一個75頁文檔的部分頁面。
大文檔因為使用廣泛，更新多，一定要保證幾個點：
1，取一個響亮的名字，大家提起來會覺得開心。例如之前一個移動項目名稱叫MI5，原來意思是Mobile Interface HTML 5，暗指英國安全局軍情五處，Military Intelligence, Section 5。：）
2，一定要有Change Log，每次改動清晰說明。
3，有Table of Contents，並提供可以點擊的鏈接，方便使用者直接跳轉到指定頁面。
4，每個小故事開始的時候要單獨一頁只寫小故事的名字，打斷節奏，營造節奏。
5，設計文檔可以包括視覺Spec，甚至是前端代碼，看項目需要。
做設計文檔一定要細心，不能出錯，文字描述部分要認真校對。這也是設計文檔比較難以維護為精品的原因。
我認為：
一個產品最終面向用戶的時候，用戶看到的是成品。成品一定要是精品。我們要對用戶負責，這是責任。
在設計輸出過程中，設計文檔是過程。過程我們也需要做精品。我們要對自己負責，這是態度。
謝謝閱讀。：）
thanks,
yoyo
德國達姆安靜的加班周日中午
- 交互設計師產出物應該是交互設計稿。還應該包括或包含：
- 完整的流程圖。更多的指用戶側的流程，如果有邏輯複雜、異常流的情況下，必須要提供。
- 完整的界面規劃圖。指的是區域的布局狀態是如何，如導航位置、登錄位置、產品位置。
- 詳細到極致的界面交互設計說明。如：登錄按鈕在點擊時報錯有提示，提示分為1.2.3；如：登錄密碼框屏蔽掉中文輸入法；如：翻頁控制項使用部門標準的翻頁規則。
- 可選的：紙原型、手稿、白板交互草稿照片、故事板、心情板、調研報告、數據等。
- 再多一句：手持設備的交互設計稿需要有手勢說明、物理返回鍵說明、物理Menu鍵說明、右健說明等。
順便多發一句廣告吧：如果有哥們能達到或已經做到上面5條，可以聯繫我：cv@liuyuntian.com，最近我在給公司招人。想和我一起工作的，可以私信我。
我在這個問題下做了回答：如何寫產品交互文檔，一份好的交互文檔應該包括哪些方面內容？ - RiceMan 的回答，感覺這裡的好答案比較多，就貼過來。
先上幾張14年夏天在Amazon做智能手錶app的交互文檔圖（那時候Apple Watch還只是個謠言，Android Wear是同年夏天我快離職的時候正式發布的...）這個項目在14年11月正式發布的，所以現在可以貼一些當時的設計原稿出來~（現在回過頭看看當時有很多地方做的還是不夠好。。。）
以下總結一下經驗：
我覺得首先應該明確你做交互設計文檔的目的是什麼，是做給誰看的。通常交互設計文檔的目標受眾是：
- 大老闆、領導決策層（CEO、產品VP）——絕大多數情況下，他們不太關心交互細節，他們更關心的是這個項目是什麼，有哪些功能，他們通常看一個典型的用戶使用流程也就夠了（人是視覺化的動物，很多老闆更願意用設計師做的交互設計文檔去理解產品方向，這是設計師向上傳達設計理念和你想要推動產品方向的好機會！）
- 產品經理——你的交互設計文檔通常是產品經理手中的「產品需求文檔」(PRD)的具體化、可視化的表現。你的交互設計文檔反映了你對產品的理解，是一份非常重要的「溝通文檔」。同樣是「篩選列表」一詞，產品經理和你的腦中想像出來的畫面可能就有很大的差別。通過你在交互設計文檔中視覺化的表達，產品需求會變得更加明確和具體。
- 工程師——對具體實現你的設計的工程師來說，他們最看重的是產品交互邏輯。他們往往希望你的文檔能夠涵蓋到所有特殊狀態（空缺數據點、空白狀態、邊界極限狀態等等、失敗狀態）。在絕大多數情況下，設計師幾乎不可能在一開始就考慮到所有這些狀態，你需要和工程師一起慢慢補齊這份文檔。準確、清晰地標註交互流程和視覺元素會讓工程師愛上你！實際上，工程師很可能是看這份文檔看的時間最久，最仔細、最認真的觀眾了。
- 你的直屬老闆和設計師同事們——相比於一張張靜止的界面設計，用交互設計文檔也許可以更好地幫助你向你的老闆和同事收集反饋和意見，因為你的老闆和同事可以有一個更全局的視角來看待你的設計細節。
我整理了一下我之前做過的交互設計文檔的結構（加入了幾個我當時並沒有做，但我現在回過頭覺得應該放的東西）：
1. 項目背景——宏觀層面上的介紹為什麼要做這個項目（外鏈到產品經歷的PRD，應該包含有更為具體的市場和競品分析）
2. 平台概覽（Optional）——以下設計是針對哪幾個平台的
3. 設計、技術限制——這點很容易被忽略，但我覺得很重要，能夠幫助Stakeholder理解你在後面的設計中做的一些「看起來奇怪的決定」
4. 用戶研究發現概述——只需要非常概要的描述，可以有外鏈到具體報告
5. 產品使用場景
6. 主交互流程（主要功能）——建議同時使用流程圖和原型設計（prototype）來表達
7. 支線交互流程（次要功能）
8. 特殊狀態（空白狀態、邊界狀態、缺失數據、失敗狀態等）——我感覺這是區分剛剛初級設計師和資深設計師的一個重要一環
9. 設計標註
10. 附錄——這裡我放上了在設計過程中覺得比較有競爭力的Design Alternatives以防老闆們想看一些備案。還放上了一些針對產品未來方向的概念性設計。
加班中，為換腦子翻翻墳。
要不要長文呢？...... 算了，還是以一些圖片代替吧，大部分都是在07~08年間在之前公司建設團隊時的產物。
UE Team 內部工作流程（圖1），指導性的流程，實際操作中會有偏差，如任務緊急有些環節及review就會被跳過，大體是這樣一個流程。
圖1
UE Team 外部工作流程（圖2），簡陋版（複雜版估計看不懂了），表達出大體的意思，各方之間的職責及工作範圍。需求方要提供詳細的需求文檔（request doc），需求有變更需要被記錄（change request doc）、接受需求後進入內部流程並交付產出物給開發團隊（一堆doc，視覺都需要文檔化），開發團隊依據設計文檔交付版本，QA部依據設計文檔進行測試並反饋bug，UE繼續跟進，然後無限循環....... -_-"
圖2
產品Workflow文檔（圖3 只列出流程圖的一小角），這玩意除了我和開發其它人都不敢看，傷神！當初畫得這麼複雜也是有點報復心理 -_-" 。交互人員請多畫畫workflow能幫你理清邏輯，但別像下圖這樣。
圖3
產品spec文檔（圖4），用來殺腦細胞的，為這頭髮白了不少！下圖是老的製作方法，完全手寫，後期就與原型一併產出了。詳細到界面上每個元素的具體定義及行為描述，Diagram圖的編號需要與上面的Workflow內的編號一致，方便開發人員查找！有些同行說沒用、沒人看，但我的體會是寫個一年半載，整體設計能力將提升一個level，workflow文檔和spec文檔也可以考驗一個人的細膩程度，現在的基本功也是那時候練下來的。
圖4
Spec文檔細分（圖5），上面這個是大spec文檔，還包含一些其它部分的文檔。像之前我們的產品進行設計時是一個通用性的產品，當需要針對不同的客戶進行訂製化時，又將產生相應的Site Modification文檔 。
圖5
產品原型（圖6），早些年做原型時基本以PPT進行產出，review時方便進行展示，後來也用Axure（算是國內較早一批使用Axure的用戶吧），由於前期流程比較紮實，review環節也比較多，我們製作原型時往往會產出高保真原型。另外，我們使用Axure製作原型除了看重它的交互性之外更重要的是它能方便導出spec文檔。ps.現在已經較少用到了。
圖6
圖6
工作資料目錄（圖7 科技樹要完整 ^_^ ），做完一堆工作，產出N份文檔，需要有一個邏輯清晰的目錄管理，方便以後工作。下圖僅列出產品目錄，三個層級：產品名稱 》 文檔分類 》 具體目錄。 簡單、明了、命名清楚（相關人員只要看到文檔名就知道是哪個產品的哪份文檔以及版本情況，下面介紹）
圖7
圖7
文檔命名規範（圖8），這個是有大用處的東西！交付物從不同的設計人員手中產出，以文檔的形式進行存放，並且需要給不同部門、不同人員進行閱覽， 命名統一後管理方便、溝通一致。
圖8
-_- 這... 沒想又成長文了！
羅列到這吧，除了上述這些，還有許多雜七雜八的文檔。
目前，市面上用戶體驗人員越來越多，設計師也越來越多，但... 對於流程、規範、交付物、都沒有太多介紹，不知道上面羅列的對各位有木有幫助，各個公司都有各個公司的玩法，算是一個補充吧。
UX / UE / UCD / UED / PED ... 我都浮雲了！ 設計而已嘛，繼續加班 ......
ps. 轉載請註明作者，不然黑你家產品 (-"-)按團隊研發流程有所區別。
類敏捷的流程、SCRUM式的輕型團隊，產出物的概念比較弱，只有關鍵+必要的東西才產出，就是那種「沒有就會亂套」的東西，形式靈活多樣，一般AXURE的原型比較多，思維導圖也比較常見，寫word文檔什麼的太累贅了不方便在輕型團隊用。
傳統行業、瀑布+螺旋迭代的大型團隊，人數200+的，必須文檔。沒有文檔作為基礎和底子的話，後期絕對有隱患，人多口雜，扯皮事小不一致事大。轉自：王為
討論總結：
我們這個小組，都是來自不同公司的人，QQ、yahoo、百度等。我們認為大家的交互第一媒質不同，我們是不同的媒質來承載交互。
再一點是交互的使用者決定了交付物的形式。有的人交付物給設計師，有的交付物給老闆，有的交付物給客戶。看交互的人，對交互理解不一樣。比如給能對 方案拍板的人看，可能需要一個保真的交互設計交付物，來確定項目是否要執行。再比如，我們的方案要給客戶看，那麼我們就要清楚表現出交互設計本身涵蓋的深 層次的東西，同時還要讓他們看到我們花費的時間是多少，這時交付物要涵蓋更多的內容。
最後一點，交互設計輸出的樣式有很多，如交互流程圖、說明圖等，它們都是就交互設計的表現層面，是整個交互設計過程中的一個環節而已。交互設計更是表現思想的東西，希望能把想的過程做得越多一些，而交付物的過程做得少一些，以發揮交互師的最大價值。
補充：交互設計交付物有哪些？（Banlon）
簡單的手繪稿
用筆在草稿紙上快速畫的一些簡單線框圖，來表達自己的設計思路和界面布局，主要是為了快速的表達意思；在一些簡單的設計中，手繪稿可以直接與PM溝通，待確定後可以直接拿給視覺設計師進行視覺設計。當然，手繪稿要好好保存，方便以後查閱。
線框圖
線框圖是用繪圖軟體繪製的來表達界面布局的交互設計稿。它用來描述界面布局、尺寸、狀態等等內容。線框圖是使用較多的一種交付物。
流程圖
用來表示系統的操作流程。也是交互設計很重要的一種交付物形式。
原型Demo
原型demo可以動態表示系統的交互樣式，更接近於實際的產品樣式。
設計說明書
是將調研、設計方法、設計方案、設計說明等等都整合到一起的一份文檔。它可以有效的傳遞設計成果設計方法等對設計最終方案有影響的因素。
彙報文檔
這是一類很特殊的交互設計交付物，它更多的是為了對項目進行總結彙報而專門準備的。
交付物的樣式很多樣，要靈活的使用各種樣式，在不同的項目中可以根據實際情況選擇合適的樣式。
我正好在做總結，這一頁應該能夠作為解答。
戳大圖應該能看清吧～
戳大圖應該能看清吧～
這個內容來自用戶體驗的交付物
axure的交互模擬是很強大，但在實際工作中幾乎很少用到，因為做交互效果的原型會降低工作效率，更改迭代也非常麻煩。所以，模擬交互可以在一個畫布上做頁面流來展示，方便做的人，也方便看的人。
問這個問題的人，通常是交互設計新人，那麼我的建議是先了解交互設計的基本方法，以及你的協作團隊。而不是討論輸出物應該包含什麼，用什麼工具。
不同產品在不同的階段，以及面對不同的協作團隊，輸出物都可能不同。方法與過程更重要。
分享一下我們目前的做法，供參考。
我們面對創新型產品、模仿型產品，以及常規的迭代優化，它們的方法流程都不同，自然輸出物也不同。
1、針對創新型產品，從分析用戶和需求開始，輸出物包括人物角色、場景腳本等等。它們的輸出物可能是Word、PPT或是其它。然後是任務分解的過程，輸出物包括任務列表等等。接下來可能會做紙上原型，那麼輸出物是紙片或其它物理介質。這一步完了後會輸出用戶體驗目標以及創建流程圖、線框圖…… 最後經一輪又一輪的測試、評審之後會完善線框圖以及設計細節。
2、針對模仿型產品，我們非常強調對競爭產品的分析。包括分析競爭產品在交互體驗上的優勢，以及用戶痛點。這裡邊會產生一份詳細的分析報告，有時會用Word、PPT，甚至Excel。接下來的步驟同樣是任務分解的過程以及流程圖、線框圖…… （線框圖也不一定非得Axure）
3、針對常規的迭代優化，會花較多的時間在用戶操作行為的分析，以及收集用戶意見或建議上面。並且定期輸出體驗報告，Word、PPT……形式不拘。然後會有與產品團隊溝通達成的改進方案以及實施結果跟蹤表……
我的回答可能不具備專業性，但是因為個人原因，想記錄在這裡，順便也當做拋磚引玉的作用。
工作3個月，我一共寫過2份文檔而已，因為我們公司沒有交互設計師，而且項目立意之類的都由老闆和高級PM定好了，所以我暫時的工作，可以說就是寫一份能讓開發團隊看懂的「交互說明」。
第一份文檔，我按照我以前上司做的方式，先講邏輯（純文字），再講頁面，頁面中涉及2個內容，一個是頁面注釋，一個是頁面跳轉。但是這樣做不好的地方在於，非常不方便查閱，很多頁面狀態全都混雜在頁面注釋里說，裡面還夾雜著頁面跳轉。這樣在改動的時候我自己也覺得實在太臃腫，查找不方便。
第二份文檔是我自己起草的框架，肯定也有很多不足的地方，但我改動的目的在於提高理解效率。因為產品邏輯比較簡單，所以要講的東西，無非是交互與頁面了。吸取了第一次寫文檔的經驗之後，我決定把流程和頁面跳轉結合起來講，大概會出一些這樣的圖：
我把這個定義為一個Flow。講的是1個完整的流程，裡面包括了頁面跳轉邏輯。
我在每個頁面上都標識了Pn的序號，雖然頁面不多，但是比較方便開發索引。並且，相對於跳轉邏輯來說，頁面細節變動的地方可能更多，我希望開發同學們以Pn的頁面圖為準。
然後，我會把一個模塊內涉及的所有頁面，比如說這裡的P1 P2 P3 P4，分別作頁面注釋。看上去大概是這樣的：
這樣做的目的是方便UI很快地知道自己要出多少張圖。要改的話，在Pages裡面去改，也好過在整篇文檔里大海撈針尋找所有相關的頁面。
當然，文檔是以模塊來分塊的。然後我做了一張這樣的表格，放在文檔開頭：
然後就是對文檔內部的所有pages and flows作了內部超鏈接，這樣要查找起來的話，效率就會快很多。
然後就是對文檔內部的所有pages and flows作了內部超鏈接，這樣要查找起來的話，效率就會快很多。
用word文檔來寫的話，免不了要用文檔結構圖，在這裡能對整個文檔作出總體理解，並且也能快速跳轉。
總體的寫作邏輯是
1.模塊 1.1 流程與頁面交互 F1 F2 F3... 1.2 頁面與注釋 P1 P2 P3...
2.模塊...
我知道我的文檔里有很多東西還沒有寫，其實總的來說，根據團隊的要求和工作的需求去探索適合自己的詮釋方式，同時讓開發GG們賞心悅目，就最喜聞樂見了。
_________________________________________賣蠢了。工作3個月，在深圳。女產品puppy。
現在一般產出物其實很簡單的，大部分都是用思維導圖表現功能結構，其次是詳細的交互原型，功能結構原型是和PM討論，原型和視覺設計師做溝通討論。
下圖為比較全的交互設計流程以及每個流程的產出物，根據自身項目及場景需要，需要經過的節點也是不一樣的。
產出物其實用什麼形式什麼工具做並不重要，重要的是你的開發人員，你的設計人員是否理解了你所要表達的意思。最重要的是人和人面對面的溝通，這比什麼產出物都重要。只指望靠自己寫份文檔然後發封郵件，就讓流程按照自己期望的方向去發展，是不切實際的。
只有在大家溝通無縫，彼此認同的情況下，這時的產出物更多的是梳理邏輯，細化流程，還有最重要的是知會一些人，他們什麼都不懂，也幫不上什麼忙，但是事後算賬的時候就很精明，例如領導，哈哈。axure+mindmap+面對面的解釋討論。axure要儘可能高度還原交互效果。mindmap側重邏輯和結構，方便開發者理解，這一點很重要，交互界面設計也要有面向對象的思想，設計不能隨行所欲，也要注重歸納，封裝，復用。文字說明全部寫在原型注視里。word寫的人寫死，有幾個做開發的，做ui的會仔細看pm和ux寫的文檔。
看到某樓的觀點，我有點憋不住了，想抒發下情懷。
交互設計這個概念最早是國外提出的，他們對於交互設計的定義不僅僅是拿著需求憑空想故事，然後畫流程做線框，交互設計師的責任在整個產品周期來說涉及的要更加廣泛。比如產品策略層面，設計層面，開發層面，投放後跟進層面，交互設計師都要負責，都要投入心思去做。
因此我根據某樓的觀點，順應這種發言的感覺，得到一個結論，在中國根本不需要產品經理，不知道哪個公司最先發明的產品經理這個職位，肯定是感覺可以降低成本結果的目的變成了壯大自己的隊伍。
不過我希望我的發言是錯誤的，也更希望某樓的發言也是錯誤的，這種爭論毫無意義。
最後，如果有必要，摺疊了吧。是思路和解決方案
不要糾結於形式，如果你想著如何表達好自己的思路和解決方案的話，你自然會不斷的迭代自己的產出物，並且會根據不同的背景靈活變化，所以沒有什麼固定的形式。
正好在前段時間裡，為部門裡交互設計師的交互文檔進行了規範化的設計。在此來談談自己對於交互設計師產出物的看法。
背景：公司是一家主營業務為 to B 產品的公司，公司的設計部門也是新起步的，所以，目前設計部門並沒有什麼調研資源，設計基本都是靠和產品之間配合，講解業務，理解之後進行設計。
交互產出物的作用
1.協同
交互產物最主要的作用就是達到協同的目的，一個產品的設計從上游的產品到下游的開發，測試等各個環節，涉及到了很多不同的人。不同的人看待產品的角度和方式都是不同的。所以這個時候就需要交互設計師來協同這些不同的人，讓大家都能夠通過你的產出物來理解好你的設計，讓大家對於這個產品是什麼樣，有一個共同的認識
2.減少後期犯錯成本
在產品設計中，產品和設計所花的時間並不是最久的，最耗費時間的是開發。所以，設計作為上游的工種，一定一定要保證考慮的足夠清楚，這樣才不會發生設計進入了開發階段之後發現重大BUG，導致設計返工，甚至最嚴重的影響到了開發進度。
所以，這個時候我們就需要一份完善的產出物，來幫助我們理清設計思路，減少後期出錯概率。
交互產出物包含內容
好的，剛剛啰嗦了那麼久，終於進入正題了~ ，接下來具體談一談產出物的具體內容有哪些 
一份設計文檔很有可能經歷不同的版本的變遷和修改。所以，我們需要對於文檔進行更新的記錄，做好版本記錄。以防止將來我們回首看之前的設計的時候，出現不明白為什麼這麼改的情況。
（這種情況在部門裡是很常見的，很多時候設計師沒有做好記錄，會導致很多改版原因的丟失，這會造成很不好的影響）
2.設計分析
前面提到過，因為公司做的是to B 的產品，我們的工作模式主要是和產品來確認業務，然後出設計方案，比較缺少調研部分的內容。所以，在設計分析這一部分的內容，我們主要還是集中於業務上。
包括的內容有：業務背景，主要用戶，業務流程圖（泳道圖），功能流程圖，信息架構圖
2.1 業務背景
業務背景存在的目的還是我之前提到的，為了協同。我們的產出物需要面對不同環節中的人，所以，為了讓大家用最短的時間理解業務，明白這個產品是幹嘛的。我們需要簡單的描述下產品所針對的業務背景是怎麼樣的。來達到各個人員之間的協同。
做任何設計都需要首先明確我們的用戶，同時明確不同用戶所具有的功能許可權和數據許可權
2.3 業務流程圖
對於to B 產品來說，分析其業務的流程是進行設計的第一步，只有分析清楚業務的流程是如何進行的，你才能針對性的進行設計
2.4 功能流程圖
當我們理清了業務流程之後，就需要通過對於業務的理解來產出對於產品的理解。我們產品需要哪些功能，功能如何實現。這個時候，我們需要進行關於功能流程的分析。
2.5 信息架構圖
最後，當我們考慮清楚產品的功能設計之後，就需要往內設計我們的信息內容和信息之間的關係劃分，在這個分析過程中，我們可以採用很多的方法，比如:卡片分類... ，最終，我們會產出一份信息架構圖。
信息架構圖的劃分是按照某一頁面，頁面內不同的區域，以及
信息架構圖的劃分是按照某一頁面，頁面內不同的區域，以及區域內所擁有的信息內容和之間的層級關係進行繪製的，這張圖就是我們將來產出實際方案時的重要參考。
基本上，經過了前期的這些步驟的分析，我們對於這個業務，產品，該如何設計有了我們自己心中的概念和初步的方案（事實上在分析功能流程和信息架構的時候，我們心中應該已經有了界面的初步概念了）
接下來，我們需要做的，就是根據我們的分析結果來進行實際頁面的設計
3.實際設計方案在分析過後，我們就介入真正的實際頁面方案的產出。其實在交互產出物中，除了設計好頁面之外，最重要的事情就是各種交互說明的撰寫。一份好的交互文檔肯定是具備很好的交互說明
以上兩張圖，分別就是目前在實際工作中所產出的頁面設計，以及交互說明。
以上兩張圖，分別就是目前在實際工作中所產出的頁面設計，以及交互說明。
這裡其實主要想講下交互說明我目前是如何撰寫的。
目前的撰寫方式，是採用窮舉的方式，寫這份文檔的時候，會將頁面內容劃分成為多個模塊，比如搜索模塊，內容模塊等等，然後一個個模塊的來撰寫詳細的信息規則和操作流程。
再具體點講，一個元素的信息規則包含有，極限值，排序，布局方式，數據來源，分頁方式.....
而操作流程則是劃分成為了： 觸發，規則，反饋，循環 這四個步驟來進行思考的。
其實當初在思考如何撰寫文檔的時候，其實是有借鑒到 微交互 (豆瓣)這本書中的內容。上面我所說的信息規則和操作流程在該書中都有涉及，推薦大家去仔細閱讀，很有幫助！
最後...
最後，我目前的交互輸出物就是上述的這些內容，但是其實就目前而言，這份輸出物還是存在有許多問題。
1.很多模塊的交互說明其實是可以共用的，如何減少這方面的工作量？
2.目前交互說明的位置和實際頁面是區分開的，如何讓開發人員看的時候可以更有效率，更快的找到交互說明，這是個很大的問題
推薦閱讀
該問題下，很多專業的人士都已經回答了很詳細了，最後，還是想給大家推薦一些跟交互產出物相關的內容：
1.U一點·料 (豆瓣) 這本書很多人應該都知道，在這本書中的第5章有詳細講述，阿里巴巴的交互設計師是如何產出的。
2.交互設計Tink-flow「五導家」筆記 這個也是阿里巴巴所分享的一種設計思維——五導家，其實這個跟產出物沒有太大關係。之所以想推薦給大家，是因為其中總結出來的一套設計師的思維體系，可以很好的提升前期設計分析的質量，這個其實也是應該體現在產出物中的。
產出物，和產出物的載體，是兩回事。
這些都是設計思想的載體。
交互的產物應該是以結果為導向，能出一份全局的軟體交互圖，方便視覺，產品和程序溝通，不在乎是用什麼工具做，什麼熟悉什麼效率高用什麼.
交互設計的實質是用戶行為探究和行為塑造。
交互設計的目標是通過用戶行為分析達到更優的轉化率。
推薦閱讀：