專案進行的過程中，階段性的文件產出（Deliverables）一直是被視為十分重要的一環。而許多專案也常常將文件列為重要的驗收項目之一，筆者曾經 手接受兩大箱的系統文件要求驗收，可能這樣客戶端才會覺得付了錢，獲得拿到東西的滿足感吧。還真懷疑這些人到底會不會看這些文件。

先不論客戶是否會看，文件內容必須符合實務需求，才能夠在真正需要的時候發揮參考價值，如果只為了驗收交差了事，而硬擠出一堆不具任何參考價值的陳腔濫調，還不如響應環保，少砍點樹比較好。

文件應重「質」，而非「量」

針對專案文件的規範，在許多系統分析設計的參考文獻中都能找到不少範例，如果你採用物件導向分析及設計方法，UML系列的文件必然也不陌生。

就實務面來看，許多專案因時程及人力不足的雙重壓力下，一人球隊從頭到尾「校長兼撞鐘」的悲慘案例，已不再是什麼稀奇的事，文件撰寫常常變成事後補件的作業程序。所以，目前專案的當務之急，是提高文件品質而非數量。

《Communication Design》希望從事網站設計開發專案的相關人員，能花對的時間在對的文件上。在規畫網站設計專案過程中，本書針對專案進行過程中的3種不同角色設計， 包括文件製作者、文件審核者，到最後文件使用者。在文件的架構及撰寫用意上，本書則提出三層式資訊表達方法，依文件內容的詳細程度，分別適用3種不同的閱 讀需求。

提供多種文件撰寫綱要及範本

本書針對3類用途列出10種文件，分別著重在使用者需求文件（User Need Documentation）、策略性文件（Strategy Documentation）以及設計文件（Design Documentation）。

● 使用者定義文件（Personas）：定義主要使用者（Stakeholder），並清楚描述他們會如何使用這套系統。將所有可能會使用網站的使用者都列進來，在設計流程及測試過程時會更完整。

● 可用性測試計畫（Usability Test Plan）：系統上線前必然經歷測試的項目及方式過程，定義這些內容之前，針對網站對於不同對象的使用方式均需要充分了解，才能掌握正確方向。

● 可用度報告（Usability Report）：針對上述的計畫執行後所產生的報告文件。

● 競爭力分析（Competitive Analysis）：就網站而言，競爭力分析等於是與其他競爭對手的優劣比較分析，從網站內容、提供的產品服務以及使用者經驗比較。

● 概念模型（Concept Model）：在系統分析中，在概念上定義出與系統有關的物件及彼此之間的關係，後續系統分析設計的主要基礎得以紮穩。

● 資訊內容（Content Inventory）：呈現網站的資訊架構及分類方式。

● 網站地圖（Site Map）：這應該是最常見、也最基本的網站階層架構示意文件，讓網站規畫人員與設計人員可以明確得知，每個網頁的內容及功能之間的關連性。

● 網站流程圖（Flow Charts）：架構是靜態的呈現，透過流程圖能分析使用者使用網站的行為動線，以及例外狀況處理。

● 視覺版面設計（Wireframes）：使網站主要內容的樣式及視覺化呈現具有一致性，包括版面格局、圖片色系的制定、文字內容。

● 畫面設計（Screen Design）：在許多系統設計方法論中，畫面的呈現設計一直被視為與使用者溝通的重要文件內容。唯有使用者看到實際的畫面，才有辦法確認設計的成品是不是他所想要的，並且降低認知上的差異。

審視、最佳化手邊的系統文件

上述文件，在本書都有專章說明如何撰寫，包括文件所應具備的文件大綱，而讀者在撰寫的過程中，必須與其他文件之間相互參照，例如在進行畫面設計時，也需要同時參照概念模型內容，以維持文件資訊的一致性。

也許你手邊已經有不少系統文件規範格式，但本書可以當作檢視既有文件完整度的工具，讓文件更臻完美。

New.Riders_Communicating.Design.2nd.Edition