其實我一直認為一篇文章的啟發性因人而異，就像是這篇關於網站企劃的紀錄可能只對我自己有用一樣。網站規劃是一個創造的過程，我所認知的流程也是，說不定在一個月後這些這些流程我來說也都不管用了，但這就是一個動態的過程，每項產品最佳化的規劃流程絕對不會一致，只能想方設法地將自己認為必要的過程記錄下來，看能不能為下一個產品所用。
情境探索
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 產生後可以持續回第一階段情境探索，帶入進行使用者研究中，反覆淬煉出更好的產品設計。
初學者的 Prototype
Akane Lee with UI Designblog.akanelee.me
上述的論述若有誤，歡迎糾正與討論，一起持續成長🙌🏻
