在迷霧中抽絲剝繭的新創產品開發之路(下)

Aug 10, 2021

我是Miki，一個互動設計師，擅長處理軟體和硬體整合的人機介面，物聯網產品是主要涉獵範圍，目前邁入第九年的設計生涯，正在B2B汪洋大海裡仰泳．．．

前言

這篇文章描述了我在互動設計產品開發的階段性經驗談，分為上/下集，上集主要談談我過去經歷過的開發故事，從中回想是有一些線索可見微知著的，下集則是集中討論我如何用設計做出應對，若你想看看有哪些線索可見微知著的，可以前往上集 👉在迷霧中抽絲剝繭的新創產品開發之路(上)

身為設計師，當發現有些出事前的線索不斷出現時(想看看出了什麼事可以前往👉上集)，雖然混亂但也必須趕緊採取行動。

開發前中期我把重點放在跨領域整合，將各方的資訊蒐集，讓整個團隊的知識在同個水平上，對於後續進行設計也會有很好的data base，可以適時地提出意見。

我作了以下嘗試

1. 利用UX Tool嘗試聚焦

在當初參與案子時，因為一直卡在踢皮球狀態，我曾經召集了PM／Sales／RD leader進行快速的Journey map將大家心中的情境具體化，並將我理解的Personas以「確認」而非「建立」的方式，讓工程背景的各位能輕鬆提出意見。

執行工作坊時，也請他們實際擔任腳色，例如有一次我請同仁擔任小偷的腳色，他提出會在作案前三天就不斷觀察建築的進出人口，如何入侵等等的作戰計畫，讓我們將討論的情境往前發展，而且會讓參與者更加投入！

如同「Google創投認證！SPRINT衝刺計畫」一書提到的衝刺方法「請教專家」，你可以把自己當作情蒐的腳色，建立在大家的知識基礎上。

但要注意，將同事當作第一線的UX情蒐雖然是常用的方法，但日後仍需與客戶實際需求做比較，才能把專案從預期落地成實踐。

2. 了解市場商業邏輯和公司定位劃分

我比較了競品(包含硬件及軟體APP)的基礎功能還有硬件整體上下游的商業邏輯，確認我們公司可提供的服務和可能的定位，再來比對業務提供的線索。重點在於抓出共通語言來建立基礎，用行業趨勢來做創新。

例如我目前正在開發給中國地區的智能鎖功能，每家廠商都提出自己具備「指紋、卡片、密碼、遠程開鎖、臨時密碼」的功能，而原因在於應用分為三類：家用、商辦或套房出租等等，因應不同情境而產生的需求，是行業在制定基本功能的共同語言。

而目前趨勢仍著重於反貓眼（門上看出去的孔洞），以及遠端開鎖的安全疑慮仍沒有一定規範標準，所以這是行業著手進行開發的趨勢。

與業務或行銷夥伴不同的是，除了看數據，設計師應該有更多的質性的探討，時時思考為何有這樣的趨勢，其背後的原因是文化？居住環境？人口組成？將蒐集到的資訊用來佐證並打造情境，才能很明確的去描述用戶是如何使用產品的。

3. 自行調研，把握機會與客人直接對談

在沒有被指派的狀況下，我擬定了訪談的問卷，與主管商量我需要一些時間了解基本情境，我設定了可能符合目標的TA，透過業務的管道找到符合的受訪者進行訪談，並把結果公告在內部白板，進一步在會議上以此背書來舉證。關於過程中使用的模板我推薦 https://servicedesigntools.org/ 網站有許多好用又美觀的工具。

其次是把握每次與客戶對談的機會，把自己當作合夥人，進行建議和提案，關鍵在於掌握以下三點。

為何找我們合作?
期待我們解決的問題(可以思考其中是否有設計能處理的部分)
當他所面對自己的客戶時實際接收的反饋

這樣來往的過程不僅建立一個對談的窗口，也能從客戶實際分享的案例獲得寶貴的經驗，許多過往模糊的問題立即有了解答。

4. 理解團隊內上下游溝通的關鍵字

若與工程師溝通順暢是基本題，那用設計工具進行跨功能整合就是進階題。身為處於軟硬整合的設計師，需和EE(電子硬件)/Embedded(嵌入式整合)/SW(軟體)工程師溝通，也常常面臨彼此不清楚對方實作需求而掉棒的狀況。

以實例來說，一個智能音箱在配網綁定的過程中，APP和硬體何時做溝通？綁定成功何時上報？而綁定失敗雙方如何判定？若一方無聯網如何回應用戶操作？這中間常常會發生各自實作，後續才發現無法銜接的狀況，設計師夾在中間常常要拍拍臉告訴自己以用戶操作為主，卻同時兼顧實作的限制。

因此，設計過程我事先確認了各自會產生的文件，以及彼此溝通必備的文件，就好像打遊戲一樣拿到各個關鍵寶物，才能夠贏得勝利。

在嘗試了幾次後，我會列出這樣一張圖表包含了硬體+APP+用戶操作行為的時間軸，讓不同團隊能在同個基礎上，知道開始與結束的接觸點，並以此為基礎開始往下發展。

心得

當一開案時，所有人集合在同一個起跑線，朝著共同目標衝刺，是最理想的狀態。但現實情況總是慘的讓人措手不及．．．

偷偷告訴你們，我遇過最恐怖的一次經驗是，案子撐了兩年，由於PM不了解軟體實作內容，最後是Software Leader自己寫了份功能需求規格(FRS)，而這份FRS變成PM拿來丟給客人或其他單位的規格書，在功能不明確的狀況下，PM一直不斷問軟體某一個功能作好了沒？但實質情境到底是什麼他也不清楚，整個團隊猶如一盤散沙，彷彿誰負責誰倒楣．．．嗚嗚嗚

人非萬能，理想的人員配置不求PM一肩扛下所有規格，但能好好傳達需求並合理劃分每個產品線及對應SKU(stock keeping unit)，而業務人員能清楚傳達客戶主要需求／我方主打服務／產品主要亮點，才能讓研發團隊如期交貨，我列了以設計師角度理想的人員配置如下。