以情境為基礎的功能規劃
M 社在早期的功能規畫方式，也是遵循傳統的 “由上至下” cascade 式的做法: 先做好大區塊的功能大綱，再進行近一階的細部設計。這種規畫的主軸是以功能 (例如 menu 的階層項目) 作為劃分的界線。這種作法在早期功能不多的情形下還能運作，但是到了後期，功能的數目多得嚇人，有兩個問題被凸顯出來: 一、無法掌握使用者完成一項完整工作 (例如在郵件中打開檔案，列印完畢之後再關掉程式) 的流程，其中所可能產生的 bug 會超乎預期。二、操作的體驗有可能因整合度不夠好，使用起來會很不流暢，產生很多客訴。
到了 Office 2007 到 2010 的時代，一種稱為 scenario based planning 的方法被提了出來，就是希望能解決前面所談的兩個問題。這個做法也不是完全推翻傳統的方式，而是在進行細部規劃之前，每個大產品組的 GPM 總舵手要先同意幾組重要的使用情境。那甚麼是 user scenario? 他有三個重要的元素。為了讓大家能很快了解，這裡舉一個假想的範例:
- 主人翁 persona: 25-30 歲的上班白領，女性。開車上班。
- 操作需求與使用環境 context: 在手機中尋找郵件中特定的 Word 檔，開啟並瀏覽內容。
- 吸引主人翁使用功能的關鍵點 attraction point: 使用語音就能找到檔案並自動開啟，無需使用手機虛擬鍵盤。
有了共同的情境，每個 feature crew 就會想辦法讓自己的功能在這個框架下能最佳化。這三個要素中最難設計的就是 attraction point，它不能過度幻想 (手一揮就能變出小鳥之類的)，還是要 SDE 技術能做出來的範圍內；也不能描述的過份仔細，限制了 feature crew 的解題創作能力。通常 GPM 在開工之前都要反覆討論這些 scenarios，使用之前所提到的 sticky note 的手法；更重要的是，最後大家要對 scenario 的優先順序要共識決，發產才會有穩定的基礎。
下一篇我會進一步介紹 scenario 的進一步延伸: 點對點的使用體驗 end-to-end user experience。