網站企劃流程| by Itsuki Lin | 文學少年& 神話少女

需求分析（服務建議書、Function Map） · 調查研究（使用者資料、市場調查資料） · 具體化功能與架構（Function List、網站（資訊）架構圖、Metadata規格） · 規劃動線與流程 ... 文學少年&神話少女Signin文學少年&神話少女網站企劃流程ItsukiLinFollowMay2,2015·13minread這篇是為了要順一次自己的企劃流程而誕生的產物。

裡面也有從書或文章上學習，或是研究其他案例得到的內容，預計會隨著我自己的學習與經驗補充更多細節，有空也會做實際文件sample分享。

因為個人經驗還很不足的關係，有任何質疑或缺點都歡迎提出。

前言首先要說的是，網站企劃流程非常casebycase。

整個流程與產出文件的類型、數量和精細度（詳盡度），都會因為很多原因而有所不同。

通常影響企劃流程最大的因素，是專案的規模。

大的專案會需要比較多的文件去整理狀況、描述細節，每份產出文件的精細度也會偏高，因為要給比較多的夥伴看（這裡的夥伴甚至包括未來的自己，不要太奢望n個月後還回憶的起當年自己在想什麼）。

小的專案可能就會跳過很多步驟，省去很多文件，因為你可能只需要和旁邊的夥伴溝通，兩、三個人取得共識就好。

除此之外，也會和公司或團隊文化、面對的客戶（是上頭還是客戶，客戶是有概念還是沒概念的）等息息相關。

因此，每個專案的流程都不一樣是很正常的現象。

不過階段性任務並不會因此而有所改變。

整個網站企劃流程階段應該會包括下列幾個階段，（）中代表該階段可能會產出的文件：需求分析（服務建議書、FunctionMap）調查研究（使用者資料、市場調查資料）具體化功能與架構（FunctionList、網站（資訊）架構圖、Metadata規格）規劃動線與流程（工作流程圖、UIFlow、導覽規劃圖）決定頁面元素與配置（Wireframe）製作雛型，測試驗證（Prototype）就算實際執行時有階段被省略，但那通常是代表該階段只存在腦中後被略過。

還有這邊只有列出「開發階段（程式與美術正式動工）以前」的網站企劃流程，開發階段期間和上線營運後，網站企劃還是要做事的，這邊又是更casebycase，也不在本篇討論範圍。

但這邊想要先強調一個觀點：網站不是一個開發出來就結束的東西，網站企劃的工作也不止於上線那刻為止。

正確的產品規劃（不限於網站）應該會是一個循環：規劃→開發上線→測量→從中學習上述階段完成後，最後會再次回到規劃階段，但這次不是從頭規劃，而是局部性進行改善與修正，或者是累積到一定待修改的量之後，整個大改版。

絕大部分網站通常都被當成免洗網站（但其實很多都沒有免洗屬性），包括測量在內的後續階段會被忽視，但那真的不是一個良好的產品生態。

開發階段前的網站企劃流程需求分析做任何一件事情都要先確立「目標」。

就算是製作兩個同樣類型的網站，目標不同也會導致網站架構不一樣。

所以網站企劃第一步就是要先去問清楚網站的目標，釐清提出目標者（上頭or老闆or整個團隊）的目標和需求。

弄清下面幾件事：網站目標為什麼要做這個網站？網站的核心目標？也可以看成所謂「一句話敘述該網站的特色」這個網站做好後希望達到怎樣的成效？了解網站使用者、市場族群該網站的使用族群為？（哪些人會使用該網站？）使用者在網站上會進行哪些任務？（用這個網站做些什麼事）透過該網站，使用者有哪些需求被滿足？網站功能需求（提目標者眼中）需要哪些網站功能？承上，功能的重要度、優先順序為何？時程與限制死線是何時？為什麼？了解死線界定的原因對於安排優先順序上還滿有幫助的。

有哪些可用資源？要用哪些資源？舉凡預算、人力、硬體設備、開發技術、可用素材等都要問一問。

不過小的團隊幾乎不用問這個問題，因為很多都是一目了然or沒得商量的事。

釐清上述問題之後，再來就是基於這些討論，著手產出相關文件並且進行內部討論。

依照不同型態的專案，會產出不同的東西：接案型→服務建議書接案型的公司通常走在時代前端，在這個階段就必須先做簡單的調查研究，先準備資資訊架構圖（Sitemap）等給客戶確認網站大致架構。

個人沒待過接案公司，只有之前做外包時做了簡易版的服務建議書，裡面包括：網站建置規劃網站地圖（Sitemap）網站功能簡介網站版面參考主視覺設計參考報價表改版型→舊版網站的FunctionList若是要進行改版，首先就是要先把原本網站的功能先統統列出來，如果有當年的網站規劃文件可以直接參考使用當然很好。

如果沒有，那就是從頭自己來，列出現有網站的功能並做分類，寫出現有網站的FunctionList。

內部開發型→FunctionMap小公司或小團隊通常都是這一型，專案出發點可能是上頭的一句話或是某人的某個idea。

這種型態在需求分析會議完畢之後，主要開發團隊就要來場內部頭腦風暴，討論出網站初步核心的功能，繪製成FunctionMap。

通常我製作FunctionMap都會先將功能進行區塊分類，比方說分成「商品」、「會員」、「購物」等大類別，再往下延伸補完各分類下面的各項功能。

調查研究進行收集資料、調查與訪談。

這邊因為我做的不夠多，無法提出太多具體建議和方向，以我自己有做過的來說有下面幾項：使用者訪談跟使用者進行面談，了解他們的需求，從中發現可以改進或考量進網站設計的觀點。

以網站改版專案為例，最簡單就是訪問當前且最近的使用者=同事，了解他們對目前網站的看法，如：你的工作上會用到網站哪些區塊？你在操作網站時曾碰上哪些問題？是怎麼解決的？你希望可以新增哪些功能來增進你的工作效率？工作上碰到的客人（公司外部的使用者）曾經反映過哪些網站的問題？使用者訪談是相當常見的研究方法，這塊做的最不錯的就屬UXDesigner，建議可以找UX的書作為設計訪談問題的參考。

市場調查研究在此個人進行過的是「標竿研究法」，就是去研究業界或國內外相同類型網站的架構與設計。

具體方法是利用試算表畫表格後，列出想要探討的項目作為縱軸，想探討的多個標竿網站則放在橫軸，然後填滿表格。

進行這個研究是為了找出其他網站有哪些好的部份、有哪些問題可以彌補加強，並且藉由整理資料和研究標竿網站的行動，激出企劃者更多的想法。

具體化功能與架構接下來是以前面階段的資料作為基底，討論出可以開發的功能，產出網站的資訊架構圖（Sitemap）與詳細的FunctionList。

而如果是重度的內容型網站，也需要在此先規劃出Metadata規格。

如果是改版型的專案，這裡產出的就是新版網站的FunctionList，並且還會另外再做一張和舊版List比較之後，新增功能的List。

資訊架構圖也稱Sitemap，是呈現網站架構用的資料，呈現出網站的區塊相關關係。

因為Sitemap也可能被誤認為是指給搜尋引擎用的sitemap.xml，因此建議以資訊架構圖（IA圖）來稱呼。

至於網站各個頁面有哪些功能與詳細介紹，則是寫在FunctionList之上。

FunctionList則是前面FunctionMap的進階版本（有些人會把這些稱之為系統規格書，有些人則會稱之為ModuleList。

），列出所有功能與詳細說明，後續開發階端都會以此列表為準。

所以如果後續到了繪製流程圖或Wireframe階段，才發現功能有所闕漏的話，都要先退回這步進行修改。

另外，我個人是會在這個階段，連同網站導覽設計與頁面預計使用的設計模式（Pattern），一併寫在FunctionList的旁邊，方便後續步驟進行發想設計。

還有，以一個包括前後台的大型網站（ex：商城、電子商務網站）來說，除了列舉出功能的FunctionList以外，其實還會需要一份詳盡說明的「系統規格書」，包括資料庫table定義、資料欄位長度、內容屬性、區塊文字多寡、資料排序方式等，都會在系統規格書中一一寫明。

系統分析在軟體開發專案中其實是一個專門的職位，因為個人在這方面還非常的弱，最多都只有負責到前台的部份，等日後磨練磨練再補完這塊。

如果是重度內容型網站，也就是擁有複雜且龐大內容的網站的話，那麼除了功能以外，還需要針對網站的品項規劃Metadata規格。

Metadata規格這邊直接看例子會比較好懂：圖書館網站→館藏資料（書、影音資料等等）Metadata如：書名、作者、版次、出版社……等電子商務網站→商品Metadata如：商品名稱、定價、特價……等其實Metadata規格與制定是一門學問，但通常大部分的網站都有現存的規格或是需求方給的規格，因此大部分企劃也就直接沿用。

但比較好的方式是利用「卡片分類法」的方式與需求方和使用者討論，藉由需求方與使用者的需求來設計欄位。

上述提到的這些文件可以是整個製作團隊一起進行討論後再產出，也可以由企劃先起頭，做完後再給團隊其他人做技術評估與確認。

無論如何，撰寫文件不是為了產出而產出，不管是Sitemap或FunctionList或之後的資料，都要拿去給其他團隊成員看過，確認或討論有沒有問題後再往下進行。

規劃動線與流程知道規劃中的網站有哪些功能和內容後，就可以開始繪製流程圖以及導覽規劃圖。

流程圖比較好理解，簡單來說就是畫出所有任務的流程。

使用者在使用網站時，大都身懷需求和任務，他可能是想要買一本書，也可能是想查看他前天的訂單寄送進度。

每一項任務都是透過一連串動作才得以完成，所以流程圖就是在幫使用者規劃使用網站的動線，以使用者的任務為出發點，他在進行一個任務時會經過哪些頁面，碰到哪些狀況分歧，統統都要畫進流程圖裡面，因此流程圖可能會非常多張，而且前後台都會需要規劃設計。

如果規劃的網站後台流程有牽連到其他非線上活動ex：倉庫出貨流程等，那麼也需要針對這些相關活動進行了解，並繪製交互影響的流程圖。

當網站流程牽連到其他部門的作業流程時，通常是跟其他負責的部門面談，一起討論線上和實體的活動流程詳情。

有時候也可能是由網站企劃這邊決定，在主管或上頭確認過流程沒問題後，所有相關部門就照網站企劃訂立的流程走。

至於導覽規劃圖，則有點像是在Sitemap上進行分類與導覽設計，用一張圖交代出整個網站的導覽設計。

導覽其實有很多種類型，像是《InformationArchitecture100》中就提出8種導覽：主導覽列網站中最主要的訴求功能或內容。

其實書中沒有特別提出，但主導覽列的重要性基本上應該大家都知道。

功能導覽感覺上好像不重要，但是一定必有且全站共通的功能，如：隱私權政策、聯絡我們等等都屬於此類。

也有人稱此為「友善導覽」，我自己則是稱之為系統列。

階層式導覽最常見到的分類選單（ex：階層式的商品目錄）就是階層式導覽。

相關導覽跨分類的導覽，像是推薦商品、其他人也買了同樣商品等都算是此類。

直接導覽類似捷徑（short-cut）的功能。

最常見的是首頁第一屏的大廣告banner，以及sidebar上常見的廣告或是特展主題的button。

步驟導覽在單一線性步驟區塊（ex：購物車流程）中常見的導覽型態，另外像是搜尋結果超過一頁的時候，讓使用者可以選擇頁數的Pagination也是步驟導覽的一種。

動態導覽動態生成的導覽功能，主要是指搜尋功能。

不過通常在談資訊架構時，會把搜尋列於導覽外，視為一個獨立主題功能。

麵包屑導覽麵包屑導覽和網站的組織分類有關，除了作為實際的一個功能以外，同時也是讓使用者了解自己所在處的一個很重要的提示。

很明顯的不是所有網站都會用到上述所有類型的導覽，但身為企劃必需要了解各種導覽系統的使用時機，在規劃網站時做全方面考量並進行規劃。

另外，如果是APP專案或是小型的輕架構網站，可以考慮不繪製流程圖，而是直接產出UIflow，交代好所有功能頁面的如何連結即可。

由於UIFlow比較難去呈現複雜的任務動線，所以若是規劃功能較多的中大型網站，還是得乖乖畫任務流程圖。

個人覺得影響使用者體驗最大的一個要素，就是網站的動線流程，絕大多數網站的UX關鍵都在這裡。

決定頁面元素與配置任務流程都決定完畢後，再來就可以進入到視覺化的階段，決定每個頁面的元素與版面配置，繪製出Wireframe。

Wireframe中文翻譯是線框圖，相當於是網站頁面的草圖，在後續的開發階段中不管是美術設計還是程式開發，都要看著這堆Wireframe進行設計或coding。

Wireframe的目的在於提供內容元素和架構，並展示出元素的排序與層級。

也就是這個頁面應該要有哪些東西、這些東西的重要性順序如何、這些東西的做成大腸包小腸（層級）是怎樣呈現出來。

因此以設計師觀點來看，他們會把Wireframe當成是設計Layout的準則，該有的元素和區塊順序與等級要跟Wireframe一樣，但並不需要照Wireframe進行版面設計。

繪製Wireframe的工具很多種，可以選擇自己順手…………或是公司有的來使用，個人在Windows上是用Pencil（Free，跨平台），在Mac上則是用Sketch3（99鎂，Mac限定，但易用到掉淚）。

個人覺得如果把前面的規劃流程都做好後，Wireframe反而是最簡單的一個階段。

如果在這裡卡關，通常問題是前面的流程沒有規劃周全，或是腦內的設計模式不夠多，後者請多多看網站累積腦內設計模式，或是買歐萊禮出的「oo介面設計模式」（oo可以帶入行動或是網頁）聖經書擺在桌上翻閱參考。

其實，不只是網站企劃會用到Wireframe，平時如果有和設計師一起合作執行平面設計等專案的話，都可以先產出Wireframe作為草圖，之後再交由設計師進行設計。

這種繪製Wireframe草圖的練習可以平日常常進行，對於腦內累積頁面設計模式很有幫助。

製作雛型，測試驗證有了Wireframe，下一個步驟就是以Wireframe為基底製作網站雛型（Prototype），也就是集所有前期規劃為大成的最後一個步驟。

之所以要製作Prototype，最主要是用來確認互動設計，並且將做好的Prototype拿去做簡單的使用者測試。

因為其他前面所有的步驟，都不是能夠拿給使用者實際操作的東西，只有Prototype在稍微包裝一下後，可以拿給使用者做測試。

用Prototype做測試的方法，通常是讓使用者觀看Prototype，並詢問使用者注意到什麼，請使用者試著猜想各區塊的用處，以及指定任務請使用者完成，並觀察使用者是如何操作該Prototype。

前期能夠做測試是一件非常幸福也非常重要的事，就算只拿給一個人做測試，得到的回饋也會出乎意料的多且非常有用，可以突破很多開發階段的盲點。

做Prototype的工具和方法很多種，可以選擇自己順手或是公司有的來用，附帶一提似乎很多人都是用Axure，但因為我公司沒買，所以我也從來沒用過。

通常我是直接用Html自己刻（Bootstrap萬歲），或是用一些線上工具如InVison來製作。

推薦參考書籍資訊架構學網站應用偉哉北極熊書，內容很硬，看完一次會立刻忘記，但請邊規劃邊翻。

別讓我動腦想UX聖經，很薄很好讀，推薦使用者訪談的章節，可以直接照著做。

為什麼他接的案子比我多？書名翻譯很爛，但內容超棒，雖然是給設計師的書，但也有很多企劃相關知識與實戰技巧。

InformationArchitecture100：100個網站規劃必備的知識網頁介面設計模式行動介面設計模式操作介面設計模式設計後台必備書籍！文學少年&神話少女ItsukiLin的個人網站UXDesign/Lifehack/Frontend?Follow351UXWebPlanning351 claps351WrittenbyItsukiLinFollow好的創意跟設計是「結合多種領域並要求細節與規劃」的產物。

Follow文學少年&神話少女Follow在網路業界打滾的設計師ItsukiLin的個人網站。

RSS>http://feeds.feedburner.com/otoitsuki/Plurk>https://www.plurk.com/otoitsukiFollowWrittenbyItsukiLinFollow好的創意跟設計是「結合多種領域並要求細節與規劃」的產物。

文學少年&神話少女Follow在網路業界打滾的設計師ItsukiLin的個人網站。

RSS>http://feeds.feedburner.com/otoitsuki/Plurk>https://www.plurk.com/otoitsuki