網站企劃流程

這篇是為了要順一次自己的企劃流程而誕生的產物。

裡面也有從書或文章上學習,或是研究其他案例得到的內容,預計會隨著我自己的學習與經驗補充更多細節,有空也會做實際文件sample分享。 因為個人經驗還很不足的關係,有任何質疑或缺點都歡迎提出。

前言

首先要說的是,網站企劃流程非常 case by case 。整個流程與產出文件的類型、數量和精細度(詳盡度),都會因為很多原因而有所不同。 通常影響企劃流程最大的因素,是專案的規模。 大的專案會需要比較多的文件去整理狀況、描述細節,每份產出文件的精細度也會偏高,因為要給比較多的夥伴看(這裡的夥伴甚至包括未來的自己,不要太奢望n個月後還回憶的起當年自己在想什麼)。小的專案可能就會跳過很多步驟,省去很多文件,因為你可能只需要和旁邊的夥伴溝通,兩、三個人取得共識就好。

除此之外,也會和公司或團隊文化、面對的客戶(是上頭還是客戶,客戶是有概念還是沒概念的)等息息相關。因此,每個專案的流程都不一樣是很正常的現象。

不過階段性任務並不會因此而有所改變。 整個網站企劃流程階段應該會包括下列幾個階段,()中代表該階段可能會產出的文件:

  1. 需求分析(服務建議書、Function Map)
  2. 調查研究(使用者資料、市場調查資料)
  3. 具體化功能與架構(Function List、網站(資訊)架構圖、Metadata規格)
  4. 規劃動線與流程(工作流程圖、UI Flow、導覽規劃圖)
  5. 決定頁面元素與配置(Wireframe)
  6. 製作雛型,測試驗證(Prototype)

就算實際執行時有階段被省略,但那通常是代表該階段只存在腦中後被略過。

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

但這邊想要先強調一個觀點:網站不是一個開發出來就結束的東西,網站企劃的工作也不止於上線那刻為止。 正確的產品規劃(不限於網站)應該會是一個循環:

規劃→開發上線→測量→從中學習

上述階段完成後,最後會再次回到規劃階段,但這次不是從頭規劃,而是局部性進行改善與修正,或者是累積到一定待修改的量之後,整個大改版。 絕大部分網站通常都被當成免洗網站(但其實很多都沒有免洗屬性),包括測量在內的後續階段會被忽視,但那真的不是一個良好的產品生態。

開發階段前的網站企劃流程

需求分析

做任何一件事情都要先確立「目標」。就算是製作兩個同樣類型的網站,目標不同也會導致網站架構不一樣。所以網站企劃第一步就是要先去問清楚網站的目標,釐清提出目標者(上頭or老闆or整個團隊)的目標和需求。弄清下面幾件事:

網站目標

  • 為什麼要做這個網站?
  • 網站的核心目標? 也可以看成所謂「一句話敘述該網站的特色」
  • 這個網站做好後希望達到怎樣的成效?

了解網站使用者、市場族群

  • 該網站的使用族群為?(哪些人會使用該網站?)
  • 使用者在網站上會進行哪些任務?(用這個網站做些什麼事)
  • 透過該網站,使用者有哪些需求被滿足?

網站功能需求

  • (提目標者眼中)需要哪些網站功能?
  • 承上,功能的重要度、優先順序為何?

時程與限制

  • 死線是何時?為什麼? 了解死線界定的原因對於安排優先順序上還滿有幫助的。
  • 有哪些可用資源?要用哪些資源? 舉凡預算、人力、硬體設備、開發技術、可用素材等都要問一問。 不過小的團隊幾乎不用問這個問題,因為很多都是一目了然or沒得商量的事。

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

依照不同型態的專案,會產出不同的東西:

接案型→服務建議書

接案型的公司通常走在時代前端,在這個階段就必須先做簡單的調查研究,先準備資資訊架構圖(Sitemap)等給客戶確認網站大致架構。 個人沒待過接案公司,只有之前做外包時做了簡易版的服務建議書,裡面包括:

  • 網站建置規劃
  • 網站地圖(Sitemap)
  • 網站功能簡介
  • 網站版面參考
  • 主視覺設計參考
  • 報價表

改版型→舊版網站的Function List

若是要進行改版,首先就是要先把原本網站的功能先統統列出來,如果有當年的網站規劃文件可以直接參考使用當然很好。 如果沒有,那就是從頭自己來,列出現有網站的功能並做分類,寫出現有網站的Function List。

內部開發型→Function Map

小公司或小團隊通常都是這一型,專案出發點可能是上頭的一句話或是某人的某個idea。這種型態在需求分析會議完畢之後,主要開發團隊就要來場內部頭腦風暴,討論出網站初步核心的功能,繪製成Function Map。 通常我製作Function Map都會先將功能進行區塊分類,比方說分成「商品」、「會員」、「購物」等大類別,再往下延伸補完各分類下面的各項功能。

調查研究

進行收集資料、調查與訪談。這邊因為我做的不夠多,無法提出太多具體建議和方向,以我自己有做過的來說有下面幾項:

使用者訪談

跟使用者進行面談,了解他們的需求,從中發現可以改進或考量進網站設計的觀點。 以網站改版專案為例,最簡單就是訪問當前且最近的使用者=同事,了解他們對目前網站的看法,如:

  • 你的工作上會用到網站哪些區塊?
  • 你在操作網站時曾碰上哪些問題?是怎麼解決的?
  • 你希望可以新增哪些功能來增進你的工作效率?
  • 工作上碰到的客人(公司外部的使用者)曾經反映過哪些網站的問題?

使用者訪談是相當常見的研究方法,這塊做的最不錯的就屬UX Designer,建議可以找UX的書作為設計訪談問題的參考。

市場調查研究

在此個人進行過的是「標竿研究法」,就是去研究業界或國內外相同類型網站的架構與設計。 具體方法是利用試算表畫表格後,列出想要探討的項目作為縱軸,想探討的多個標竿網站則放在橫軸,然後填滿表格。 進行這個研究是為了找出其他網站有哪些好的部份、有哪些問題可以彌補加強,並且藉由整理資料和研究標竿網站的行動,激出企劃者更多的想法。

具體化功能與架構

接下來是以前面階段的資料作為基底,討論出可以開發的功能,產出網站的資訊架構圖(Sitemap)與詳細的Function List。而如果是重度的內容型網站,也需要在此先規劃出Metadata規格。

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

資訊架構圖也稱Sitemap,是呈現網站架構用的資料,呈現出網站的區塊相關關係。因為 Sitemap 也可能被誤認為是指給搜尋引擎用的 sitemap.xml ,因此建議以資訊架構圖(IA圖)來稱呼。

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

Function List則是前面Function Map的進階版本(有些人會把這些稱之為系統規格書,有些人則會稱之為Module List。),列出所有功能與詳細說明,後續開發階端都會以此列表為準。所以如果後續到了繪製流程圖或Wireframe階段,才發現功能有所闕漏的話,都要先退回這步進行修改。

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

還有,以一個包括前後台的大型網站(ex:商城、電子商務網站)來說,除了列舉出功能的Function List以外,其實還會需要一份詳盡說明的「系統規格書」,包括資料庫table定義、資料欄位長度、內容屬性、區塊文字多寡、資料排序方式等,都會在系統規格書中一一寫明。 系統分析在軟體開發專案中其實是一個專門的職位,因為個人在這方面還非常的弱,最多都只有負責到前台的部份,等日後磨練磨練再補完這塊。

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

Metadata規格這邊直接看例子會比較好懂:

  • 圖書館網站→館藏資料(書、影音資料等等)Metadata 如:書名、作者、版次、出版社……等
  • 電子商務網站→商品Metadata 如:商品名稱、定價、特價……等

其實 Metadata 規格與制定是一門學問,但通常大部分的網站都有現存的規格或是需求方給的規格,因此大部分企劃也就直接沿用。但比較好的方式是利用「卡片分類法」的方式與需求方和使用者討論,藉由需求方與使用者的需求來設計欄位。

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

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

規劃動線與流程

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

流程圖比較好理解,簡單來說就是畫出所有任務的流程。 使用者在使用網站時,大都身懷需求和任務,他可能是想要買一本書,也可能是想查看他前天的訂單寄送進度。每一項任務都是透過一連串動作才得以完成,所以流程圖就是在幫使用者規劃使用網站的動線,以使用者的任務為出發點,他在進行一個任務時會經過哪些頁面,碰到哪些狀況分歧,統統都要畫進流程圖裡面,因此流程圖可能會非常多張,而且前後台都會需要規劃設計。

如果規劃的網站後台流程有牽連到其他非線上活動ex:倉庫出貨流程等,那麼也需要針對這些相關活動進行了解,並繪製交互影響的流程圖。當網站流程牽連到其他部門的作業流程時,通常是跟其他負責的部門面談,一起討論線上和實體的活動流程詳情。有時候也可能是由網站企劃這邊決定,在主管或上頭確認過流程沒問題後,所有相關部門就照網站企劃訂立的流程走。

至於導覽規劃圖,則有點像是在Sitemap上進行分類與導覽設計,用一張圖交代出整個網站的導覽設計。導覽其實有很多種類型,像是《Information Architecture 100》中就提出8種導覽:

  1. 主導覽列
    網站中最主要的訴求功能或內容。 其實書中沒有特別提出,但主導覽列的重要性基本上應該大家都知道。
  2. 功能導覽
    感覺上好像不重要,但是一定必有且全站共通的功能,如:隱私權政策、聯絡我們等等都屬於此類。也有人稱此為「友善導覽」,我自己則是稱之為系統列。
  3. 階層式導覽
    最常見到的分類選單(ex:階層式的商品目錄)就是階層式導覽。
  4. 相關導覽
    跨分類的導覽,像是推薦商品、其他人也買了同樣商品等都算是此類。
  5. 直接導覽
    類似捷徑(short-cut)的功能。最常見的是首頁第一屏的大廣告banner,以及sidebar上常見的廣告或是特展主題的button。
  6. 步驟導覽
    在單一線性步驟區塊(ex:購物車流程)中常見的導覽型態,另外像是搜尋結果超過一頁的時候,讓使用者可以選擇頁數的Pagination也是步驟導覽的一種。
  7. 動態導覽
    動態生成的導覽功能,主要是指搜尋功能。不過通常在談資訊架構時,會把搜尋列於導覽外,視為一個獨立主題功能。
  8. 麵包屑導覽
    麵包屑導覽和網站的組織分類有關,除了作為實際的一個功能以外,同時也是讓使用者了解自己所在處的一個很重要的提示。

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

另外,如果是APP專案或是小型的輕架構網站,可以考慮不繪製流程圖,而是直接產出UI flow,交代好所有功能頁面的如何連結即可。由於UI Flow比較難去呈現複雜的任務動線,所以若是規劃功能較多的中大型網站,還是得乖乖畫任務流程圖。

個人覺得影響使用者體驗最大的一個要素,就是網站的動線流程,絕大多數網站的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聖經,很薄很好讀,推薦使用者訪談的章節,可以直接照著做。
  • 為什麼他接的案子比我多? 書名翻譯很爛,但內容超棒,雖然是給設計師的書,但也有很多企劃相關知識與實戰技巧。
  • Information Architecture 100:100個網站規劃必備的知識
  • 網頁介面設計模式
  • 行動介面設計模式
  • 操作介面設計模式 設計後台必備書籍!

--

--

在網路業界打滾的設計師 Itsuki Lin 的個人網站。 RSS > http://feeds.feedburner.com/otoitsuki / Plurk > https://www.plurk.com/otoitsuki

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store