產品心得：讓產品規格文件更完整的思考法
設計所時三不五時會修到 App Redesign、Brand Redesign 的課，這些課程期末常常會邀請到業界人士來當評審。我們會把這些提案做成精巧美好的 user story，提案後也都從評審那邊得到「很創新」的讚賞。
然後，就沒有後續了。好一點的，可能提了 10 個提案最後會被實作 1–2 個。
這個懸念就被我一路帶到了工作上。直到有一天，老闆終於在看了我的 PRD 後，數度斟酌用詞，但只能想到這句，「這個企劃⋯⋯很 intern。」
設計所的訓練是使用體驗（或關係人）至上，以 scenario、user story 去展開一個服務該有的功能與流程；我甚至記得自己的論文有引用 Design thinking for innovation 的文氏圖來表達好的設計出自於使用者體驗（desirability）、商業價值（viability）、技術可行性（feasibility）。
學生專案只看到了系統的冰山一角
這個概念現在看起來基本上沒錯，但是缺乏了很多細節，不如說學生提案能看到的多半就是作為消費者所見到的冰山一角。
就舉個虛擬的學生提案案例——「在美妝 App 裡加個社群功能，讓使用者們可以找到相同美妝風格的朋友吧！」，我們沿用上面三個環的架構，討論學生設計專案裡會被規劃到的部分。
使用者體驗
- 使用者體驗是否優良
- 功能是否滿足所有業務情境
欸對，就沒了。為什麼不講更多呢？是因為這方面的改變（學生 aka. 消費者）最看得見。
在業界評審深不見底的眼神裡，他們看到的是⋯⋯
商業價值
能否以不動到產品設計、程式的前提先確認商業成效？
「為什麼第一點就這麼銅臭味！」學生們心裡可能捂起了鼻子。
但是如果我們還無法證實「找到好友、找到同溫層」的效益是利大於弊，現有的功能架構就可能需要設計師去擴充 design system，才能做出聊天室的介面；也可能要請工程師規劃出好友之間的 API、DB 欄位、開發後再兼顧開發後續的 CI/CD。
如果這個功能上線後，發現效益不夠要拔掉呢？
大家應該有用繩子打結的經驗，繩子一直打結一直爽，要解開結的時候摳到天荒地老還摳不開。這就是技術債。
確認成效良好後，才能開始後續的評估
設計面
設計元件能否重複使用
在產品線漸增、產品功能龐大的企業尤其如此，維繫功能間一致的元件、操作邏輯十分困難。新功能能否沿用 Design System，或是不得已需要延伸出特規，就必須思考「未來還會不會用到它？」
否則，Design system 就只是一份擺著好看、但過時的文件了。
開發面
使用的第三方 API 是否支持我們想要的結果
學生專案裡也許會期望 App 的好友圈看得到 Dcard 美妝版熱門文章，「這樣就能促進社團有話題聊啊！」他們說。
熱門文章怎麼獲取？總不可能憑空出現，得去查 Dcard 有沒有提供這類的 API，否則 App 營運團隊要雇一個小編每天都在複製貼上。
DB 欄位能否重複使用
就跟設計元件能否重複使用一樣，DB 欄位也是很珍貴的。
假設你維護了一個很多 table 的 excel 去記載會員的個人資料、消費紀錄、贈點紀錄，但這些 table 裡面有很多只被使用一季的欄位，像是「2023_夏季_心理測驗結果」，整個 database有一堆 null 的欄位想必非常阿雜。
哪些資料值得存，如何存，都跟後續我們如何重複使用、使用頻率相關。
Client 效能能否負荷
各位手機如果不是買最新的，想必都曾經玩手遊玩到手機發燙（我拿的是 iPhone SE2，玩 RPG 戰鬥遊戲甚至會卡頓閃退）。這些功能要求會否牽涉大量的資料或畫面即時運算？如果會的話，有沒有不太影響使用體驗的 backup plan？
Client 端是否通用
這舉個實際例子。最近處理 EDM 的專案，注意到大家使用的收信軟體基本上是年久失修的 browser，Outlook, Yahoo mail, Apple … 等 mail client 開同一封信，都有可能因為 render 不出漸層、點擊效果、動畫，而造成整封信閱讀困難。
沒想到吧，通用性竟然不只是要考量因人而異的體驗，還有可能是 client 在雷。
商業面
企劃中的工具、資訊傳輸的成本是否最低廉？
假設美妝 app 會指引使用者去有合作的屈臣氏好了，印象中 Google Map 的 API 是依 request 數量收錢（他出動那麼多 Google 地景車維護最新的地圖並不是跑慈善的！），要怎麼樣才能讓使用者不會狂搜尋增加一堆資訊傳輸成本呢？或這個方法真是有夠貴，乾脆在美妝 app 官網列出有合作的屈臣氏的名單，也許也能解決？
這個企劃會在自動運作後多久降低其品質？
假設美妝 app 的社群功能大紅大紫，大家上傳到 AWS S3 的美妝圖片容量越來越大，我們就得要預見超過所購買 AWS 容量上限的未來發生（否則有一天使用者就發現圖片一直上傳不了）。以 LINE 來說超過期限的圖片無法存取就可能是個好作法，或是要付費才能永久存取，這就可以跟使用者體驗放在一起討論。
回想起來，過去經驗中的企劃很快落地，可能是因為需求規格常見，或是設計師、工程師補足了企劃缺漏，又或是解法本身是個只會被使用一次的 workaround 或技術債。
現職公司的企劃要討論很久，可能是因為我們深知開發 feature 很簡單、但是拆債很難，我好像離解答更近一步。而有主管、夥伴比我更在乎這些事，是最值得感到幸運的事。
「看到自己的進步不覺得很開心嗎？」
一天，老闆在推開會議室的門之前，轉身問準備收拾下班的我。
「可是我常常還是覺得自己好無能。」
「每一天都是痛苦的，時間拉長一點看就會看到了，我每一天也都是這樣的。」
老闆笑著把門關上，去開另一個會了。
