其實我一直認為一篇文章的啟發性因人而異，就像是這篇關於網站企劃的紀錄可能只對我自己有用一樣。網站規劃是一個創造的過程，我所認知的流程也是，說不定在一個月後這些這些流程我來說也都不管用了，但這就是一個動態的過程，每項產品最佳化的規劃流程絕對不會一致，只能想方設法地將自己認為必要的過程記錄下來，看能不能為下一個產品所用。
情境探索
While I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all. Their approach completely kicked our approach’s ass.
我認爲勝負就是取決在這一階段，一個100分的無用產品，跟一個30分的關鍵解法，孰輕孰重高下立判。
不過當然，我們追求的是100分的關鍵解法。
我們都知道要了解使用者，但是在第一步都會手足無措，尤其是當有機會和User訪談時，確保要做好訪談規劃，分秒其實都是非常寶貴的。
首先需求探索要先關注探索的目標是誰，Client(客戶)和User(使用者)的需求探索並不盡然相同，但若是接受客戶的網站建置的案子，往往不會有足夠的時間去做User reasearch，只能在Client身上萃取出切合他們實際需求的產品規劃。（但Client是否了解他們的User就是另外一件事了）
若目標是User, User research interview因不同階段訪問目的概括可以分為：
產品未上線：
- Exploratory Interview
尚未有產品構想，但有概略方向，從User的情境中去確認我們想要解決的問題是什麼？ - Validation Interview
對於產品已經有明確的構想，可以利用prototype驗證此產品是否確實能夠解決User的問題，或是讓User自己走一次使用流程，針對產品做修正
產品已上線：
- Satisfaction oriented Interview
有用性測試，了解User認為產品的解決問題的程度和意見回饋 - Efficiency Interview
易用性測試，或給予受訪者任務，觀察User完成任務的流程是否如我們預期，可從中歸結出真實的Customer Journey Mapping
雖然不同階段的訪問重點不同，但是大致的流程是相似的：
- 確立Target User(目標使用者)
- 規劃訪談內容
- 受訪者必要條件或類型
- 受訪人數
- 訪問目的
- 內容與流程
- 回饋或報酬 - 尋找符合Target User的候選人
- 接觸並邀請候選人受訪
關於訪談內容的方法設計可以參考 User Research Basics
訪談的過程有一些要點，聽取User的回應之外，並多嘗試詢問User內心的感受，挖掘每個行動與想法背後的動機。但要注意，User的回答並不一定都是真實的，其實不只是感受，可能甚至連使用者的判斷都是假的，舉范冰《Growth Hacker》中的舉例來說：
案例一、尋問使用者線上服務如果漲價(18 -> 20元)，是否還願意購買，使用者普遍回答不願意，但是事實上調漲後的總收入是沒有改變的。
案例二、聊天軟體中常會有陌生人的騷擾訊息，團隊因此欲開發一鍵已讀的功能，並且被女性使用者備受期待，但在實際功能釋出之後，該功能使用率卻極低，再經過多次群體訪談後發現，女性使用者炫耀自己魅力的需求（向朋友展示未讀騷擾訊息），遠比一鍵已讀的需求來的更加迫切。
需求分析
無論哪種類型的Interview在搜集並消化訪談後的資料都可以依序以下的產出，唯一的不同在於，越後面的階段的產品目標和使用者流程應該會更加精確：
- Persona （人物誌）— 情境中目標使用者的人物代表
tools. Xtensio
- Customer Journey Map （使用者旅程地圖）— 描述User在體驗過程中接觸的事件與感受
tools. Balsamiq
- User Story Mapping（使用者故事地圖對照）- 可能涵蓋穿插多種Persona活動，列出各環節需要支援的產品功能，加以排序，若功能繁多，要視情況切分產品功能的釋出階段
tools. Cardboardit, Realtimeboard, Trello
Customer Journey Map 和 User Story Mapping概念容易被混用，詳細區別可以參閱：
不是每個階段都要如實按照上述，目標是產出完善的User Story Mapping即可。User Story Mapping的架構與詳細規劃請參照《使用者故事對照》，優秀的User Story讓接續的產品開發更具完整性與全觀性。
從各式Interview中持續產出上述的結構化資料，構思和修正產品真正的樣貌，再持續藉由Interview或是線上data來做驗證，這就是一個不斷迭代(iterate)的過程。
規格制定
一開始的規格制定往往是在原型設計出來之前，利用條列式的方式勾勒出Client/User需求，並由以下的規格制定產生共識：
- Feature list — 包含需要與不需要的主要功能、類別、支項，若是面向客戶的，可與報價單合併呈現，且記錄要盡可能詳盡，這對雙方來說都是一種保障
- User Story/Flow— 用文字或圖畫敘述使用者在網站中各項活動的流程與情境，方便檢視是否有遺漏的功能或頁面，最終網站完成時也可以藉由這些User Story/Flow來驗收成果
- Sitemap — 網站組織架構，可以清楚了解到會有哪些頁面，各自的關聯性為何，利於往後原型設計時的邏輯
tools. xmind, draw.io, slickplan - Overall style — 整體的風格定調，包含色彩盤、字型、風格關鍵字
tools. creativemarket, coolors - Schedule Planning — 以功能或是頁面切分，定好預計的時程規劃，可以甘特圖表達
tools. elegantt - Communication Channel — 面向客戶時，千萬不要小看溝通管道的協調，當客戶找你的時候只會打手機，你就會開始崩潰了
tools. Slack, Skype, Discord - Shared Data —
包含多項文件的共享，利於雙方的持續溝通紀錄與追蹤
e.g. server spec and info, feature checklist, weekly report, google analytics tracking code, etc.
tools. Dropbox Paper, Google doc and sheet
詳細的規格案例可以參考：
原型設計
所謂的原型通常說的不外乎就是以下三種
三者的主要差別可從下圖解釋
Prototype 產生後可以持續回第一階段情境探索，帶入進行使用者研究中，反覆淬煉出更好的產品設計。
上述的論述若有誤，歡迎糾正與討論，一起持續成長🙌🏻
