我是Miki，一個互動設計師，擅長處理軟體和硬體整合的人機介面，物聯網產品是主要涉獵範圍，目前邁入第九年的設計生涯，正在B2B汪洋大海裡仰泳．．．前言
這篇文章描述了我在互動設計產品開發的階段性經驗談，分為上/下集，上集主要談談我過去經歷過的開發故事，從中回想當時出狀況時，團隊應該思考的關鍵問題，下集則是集中討論我如何用設計做出應對，若你剛好也在同樣迷霧中，可以直接跳轉下集️👉在迷霧中抽絲剝繭的新創產品開發之路(下)
我們先來談談一個普通的產品開發，無論身在IN-HOUSE／AGENCY／START-UP都能適用的基礎步驟會像是這樣子的。
- 確認需求(趨勢/擁有的技術/業務端的回饋)
- 由PM定義規格/SKU及規劃時程
- 各團隊建立原型Prototype
- 交付設計給客人獲取反饋
- 來回反覆測試及釋出設計
- 量產評估(QA測試/產線評估/安規通過)
設計初期需求來源 / Source from MikiFan
然而，現實總是不按牌理出牌
從前期的產品概念及規格制訂，到後期的實作細節，專案實際進行時會遇到許許多多的狀況，在這些令人沮喪的狀況，如何用設計產生影響力，在上集我提供了該問的關鍵問題，下集則提供了一些我嘗試方法，在實際的案例中發現確實可以幫助團隊進行決策。
狀況一：團隊裡沒有人是專家，人人把UX當靈媒
⏰發生時機：前期｜🔥危險程度：★★★☆☆
當面對一個新開發的領域，業務極可能還在推敲潛在客戶，所以開出的規格相對模糊，通常又快又急的要求試做一個樣本。
這時若有人提出「要不要這個功能？」，這時PM卻一問三不知的轉頭問UX，再換UX一臉無辜，請問你的產品定義是什麼？用戶是誰？情境是什麼？會議室沉默．．．
⚡️關鍵問題：開案初期專案是否有建立一份具有脈絡、架構和目標的規格文件，用來限縮問題範圍？
⚡️設計輔助：若短期內無法建立文件，是否有對標的競品，設計師可以就競品反推假想的產品定義及基本用戶腳色，但仍然要請PM建立一份規格文件。
狀況二：有一份規格書，但是一直沒有往下展開定義細節
⏰發生時機：前期｜🔥危險程度：★★★★☆
輪到開案初期，業務與客人談妥合作後，列了一份規格，乍看之下沒問題，但仔細看發現其中穿插了具體功能、硬體規格、操作行為，像不同款的拼圖被丟在同個盒子裡。
輪到開案初期，業務與客人談妥合作後，列了一份規格，乍看之下沒問題，但仔細看發現其中穿插了具體功能、硬體規格、操作行為，像不同款的拼圖被丟在同個盒子裡。
內容重複的資訊雖能隱約想像最終產品雛形，卻沒有主要脈絡，也看不出客人買單的賣點**。**
這時業務與PM不斷互踢皮球，PM追問業務具體而言要用哪個零件？而業務反問RD你們手上的樣品拆開有什麼心得？有沒有建議的型號？
在時程壓力下規格書直接下放到RD，RD滿頭問號的問定位是什麼？要跟什麼比較？那其他產品有的功能我們要不要有？形成一個羅生門 …。
⚡️關鍵問題：為了避免團隊實作時回頭大海撈針，PM是否有明確劃分每個版本及預期內容規劃?
⚡️設計輔助：從源頭找尋答案，詢問業務或客戶實際描述主要需求是什麼，將情境具體化，並檢視現有功能是否能被滿足這些情境，協助團隊判斷細節的精細度。
狀況三：時程表週週有，但進度一直滑掉
⏰發生時機：中後期｜🔥危險程度：★★★★☆
在時程表中最關鍵的是整合的時間點，當各部門針對功能各自評估開發時間後，PM還必須協調列出整合及驗收的關鍵時程。
以軟硬整合設計來說就是根據硬體的EVT/DVT時程而進行整合及驗收，若遇上沒有經驗的PM，軟體的交付時程很容易就變成是依附在硬體交付的時程順便制定。
我遇過很慘的狀況是PM沒有定義軟件規格，也沒有列出實作須達成的目標，當軟件實際開發時如同解壓縮般，在不合理的時程中面對一堆未知，追問時又直接銜接到業務窗口，等待客人回覆的時間又擠壓到開發時程。
客戶發現時程延後，他在你背後，他很火大．．
⚡️關鍵問題：實作時程是否有包含評估、整合及驗收時程？若時程很趕有哪些功能的優先順序較高？當出現問題時是否有指定負責人協助釐清？
⚡️設計輔助：在評估設計時程時，要將與客戶溝通往返＋後續修正的工作量也算在內，通常交付給客戶後，要求客戶反饋的時間會比較寬鬆，常常收到反饋時，手上也同時有正在進行的工作，因此一定要將這些狀況考慮在內。
狀況四：包山包海的規格，企圖滿足所有需求的模組化產品，卻遲遲無法量產
⏰發生時機：中後期｜🔥危險程度：★★★★★
剛開始的產品規格很簡單，具備ABC三種功能就好，但不知何時，開始出現模組化這個看似夢幻的解法，如同Google曾經推出的模組化手機，號稱喜歡什麼功能就組什麼，而實際運用下來則是慘不忍睹。
業務企圖滿足所有客戶而要求在同塊PCBA(電路板)上保留所有功能，以聯網模組而言就好像必須同時具備Wifi模組、藍芽模組、Zigbee…，客戶要哪個就換哪個模組，實際上對應軟體卻無法這麼靈活運用。
而APP也保留了各家競品的功能，只要有些微不同就留下來，在PM沒有阻擋的狀況下，導致第一次交付的原型已經龐大到幾乎與最終產品無誤，第一次小批量量產的里程碑感覺遙遙無期。
⚡️關鍵問題：PM與業務的溝通是否出現問題？在不影響原有進度的狀況下，需要額外增加多少時間？新增的需求是否具備強烈原因需要調整目標（例如：客戶改變策略）或者另外開案?
⚡️設計輔助：適時提出停損點是必要的，釐清需求是否確實存在，現有功能是否能滿足，說不定就能減少一次全盤推翻的災難。
誰能來救救我
長期忽略開發問題所帶來的影響是全面的
實際上的影響可分成三個部分
開發人力成本龐大
沒有限縮範圍的專案開發會導致專案又臭又長，就像是硬件只喊一個攝像頭，看起來輕鬆合理，但對應到嵌入式軟體和應用開發就是一整套必須完善的邏輯
僅僅只是希望「在夜間有人走過時拍照」，就得重新定義情境，例如：夜間需要加上補光，需支援紅外線攝影，走過時是動態拍攝還是有偵測到人形就拍照？需錄影多久時間？何時上傳？
設計端需從頭追問業務，有時甚至沒有答案，每個人看起來都很忙，但卻都不是在忙自己擅長的事情。
物料成本龐大
產品尚未闖出名堂時，第一個比拚的就是價錢，當客戶已經有長期合作的夥伴，建立信任及優惠的價格，若你價格比他的夥伴還要高，就難以拿到合作的第一張門票。
但如果企圖用同個商品滿足所有潛在客戶，會發現沒有一個主要的架構(或一塊專門的板子)支援所有功能，所以要不斷預留版面或外接子版。
暫時保留的功能不一定有時間實作，卻是扎實的錢被卡在上面，導致成本壓不下來，然後老闆跟客戶都很生氣(逃~。
產品外觀複雜
產品外觀與人因息息關，在外觀可能同屬一個區域，但料件的體積固定，因此外觀多少都會造成干涉。
例如：製作一個帶屏幕的貓眼攝像鏡頭時，鏡頭與顯示屏幕就必須在眼高所及的位置，但不能同時卡一起，導致產品不斷加長外觀，或者因為共版而把多種複合功能放在同一顆按鍵上，圖標就越來越複雜，操作也不再直觀。
是時候展現真正的技術了！
看到這裡是不是覺得世界要毀滅了? 😆 那麼就繼續看下集，我整理出的心法，如何在兵荒馬亂中理出一條脈絡。
如果覺得喜歡內容請給我 1–5 個 claps；覺得實用的話請給我 6–10 個 claps，謝謝~~
