AQUILA PRO AI

這是一個從零開始的產品，沒有前一版可以參考，也沒有既有的使用者行為可以觀察。要在還沒有任何人用過的前提下，決定「一般家庭到底要怎麼管理自己家的 Wi-Fi」。

而且限制是綁著一起來的。上線時程很趕；介面要相容舊機型，不能假設使用者手上是最新的硬體；色系必須跟行銷設計那邊統一，主色不能走深色 —— 這是老闆定的方向。

目標定得夠窄才有用：讓一個沒有網路知識的人也能把家裡的 Wi-Fi 裝起來、管起來，而這份簡單不能擋住工程師需要的除錯資訊。

背後有兩個商業目標，而且都不在介面裡。降低退貨率： 路由器裝不起來的結果不是「使用者將就用」，是退回去 —— 安裝失敗會直接變成營收損失。降低客服成本： 每一通「我裝不起來」的電話都有成本，而且會集中在同樣那幾個步驟，那就代表它是設計問題，不是使用者問題。

這兩件事決定了資源怎麼放。我們沒有把改版預算平均分配到所有功能，而是集中在測試中失敗率最高的安裝流程，Scene 這類進階功能排到第二階段。商業目標不是背景資訊，它是優先序的依據。

看的是兩類。Apple HomeKit 跟 LG ThinQ 在意的是「家裡所有裝置怎麼被統一管理」；TP-Link、Google Nest Wifi、小米在意的是「網路本身好不好」。我們的產品卡在中間 —— 它是路由器，但要管的東西越來越像智慧家庭。

顏色分析看的不是競品的 App，是我們自己的硬體。主色是一組溫柔的藍：乾淨、不侵略，調性現代、有信任感，帶一點距離感的優雅。這組分析決定了整個介面的方向 —— 乾淨的科技藍配柔和的生活色，而不是這類產品慣用的深色科技感。

決定不做的功能：Dashboard 的自訂背景。RD 評估工時偏長，而那是一個「好看但不解決問題」的功能 —— 時程很趕的時候，它是第一個該讓位的。

從 LG ThinQ 學到兩件事：針對產品做硬體層級的檢測，以及在 App 裡放商店。前者對路由器特別合理，因為東西壞掉時，使用者第一個想知道的是「是不是我這台機器有問題」。

受測者是刻意挑的。我們不找「一般使用者」，找的是對網路術語最不熟悉的初次安裝者 —— 10 位女性同事。

理由是這台機器真正的失敗情境，不是懂網路的人裝不起來，而是家裡沒有人懂網路的時候，那個被推去裝的人卡在 SSID、頻段、Factory Reset 這些名詞前面。如果連他們都能順利裝完，其他人就不是問題。設計安裝流程應該對著最容易失敗的那一端做，而不是對著平均值。

這個 App 沒有前一版可以測，所以研究對象是上一代機種 —— D-Link Eagle Pro AI M32 的實機與它隨附的 App。測的是完整的開箱流程：從拿到機器、接線、安裝，一直到真的能上網為止。不是測那個舊介面好不好看，是測一個沒裝過路由器的人到底會卡在哪。

測試範圍是刻意往前拉的。原本只打算測 App，後來決定從拆箱開始 —— 因為使用者不會分辨「這是 App 的問題還是產品的問題」，他只會覺得這台機器很難裝。這個決定後來證明是對的：測出來的五個卡點裡，有兩個根本不在 App 裡。

先講 App 裡的三個，每一個都改了設計。

沒有人找得到 Setup Code。 那串碼就印在機身上，但用文字描述位置完全沒用。改成直接畫一張插圖，標出它在機身的哪個位置。掃描失敗時也不再丟通用的錯誤訊息，而是說出到底哪裡出錯。

沒有人讀文字。 畫面一出來就按下一步，說明看都不看。所以關鍵資訊全部改成圖像優先、一頁只講一件事、主要字級放大，非必要的說明降級或直接刪掉。既然使用者不讀字，就別把成敗押在字上。

手動切 Wi-Fi 會把人弄丟。 安裝過程需要手動切換到裝置自己的網路，很多人切出去就回不來了。改成把這一步包進 App 的引導裡，並在等待期間顯示明確的進度與預期時間 —— 讓「等待」不會被誤判成「壞掉了」。

還有一個誰都沒預料到的：有人想把新網路設成跟舊的同一個 SSID，這樣手機會自己重連。但他們完全不知道那個設定藏在哪裡。

另外兩個完全落在 App 之外。包裝並排的時候，第一眼選哪一個幾乎由色彩決定，白底乾淨的明顯勝出；外型上「立方體、沒有天線」被形容成更現代、更適合擺在客廳，有天線的則被聯想成機房設備。這兩件事都不是我能改的 —— 重點是知道該交給誰。

這些發現最後收斂成一條規則，後面每一章的設計都是從它長出來的：每一頁只讓使用者做一件事，並且立刻讓他知道有沒有做對。

我們提了兩個方向。差別不在畫面好不好看，在要不要動流程結構 —— 一個保守、一個激進，刻意把可能性的兩端都攤開來。

結果兩個都沒選上，決策端指了第三個方向，也就是最後上線的這一版。

當下當然有點洩氣。但事後回看，這個結果本身就說明了 A 和 B 的作用：它們不是兩個候選答案，是兩根標竿。把保守與激進的極端都擺出來之後，決策者才有辦法指著說「我要的在這中間、偏某一邊」—— 而那句話，在看到 A 和 B 之前是講不出來的。

如果三個方案裡有兩個是為了讓第三個長出來，那兩個就沒有白做。 前提是你得先把極端提出來，讓人有東西可以反對。

不管最後走哪個方向，判斷標準是同一組：能不能解掉失敗率最高的那兩個關卡、在技術限制下做不做得出來、能不能在期限內完成並驗證。

這一章的每個決定都接在上一章的測試後面：使用者不讀字，也找不到機身上的東西。

這個產品有好幾種安裝路徑 —— 有線、無線各有各的走法 —— 原本很容易讓人卡在中間。收斂流程的做法是把分岔移到最前面：使用者一開始就選好路徑，而不是走到一半才發現走錯。後面每一步都配一張對應的插圖，直接標出實體按鈕在機器上的哪個位置、以及眼前這台是哪一款機型。不用再猜「他講的那個鍵到底是哪一個」。

我原本提了 Dark Mode 的設計。除了老闆定的色系方向之外，還有一個更實際的理由讓我自己也放棄了：路由器本體就是深色的，產品圖放在深色介面上會整個融進背景 —— 使用者在安裝流程裡根本認不出自己手上那台是哪一款。這個產品的介面必須一直出現裝置圖，所以亮色系反而是對的，不管是誰要求的。

情境模式可以直接套用預設的 Arrive、Leave、Sleep，也可以自己建一個。選取之後用一段輕微的動態過場導向圖示選擇頁，場景化的 icon 讓設定幾秒就完成。微互動 —— 選取時的細微縮放與亮度變化 —— 遵循「最少操作、清楚回饋」這一條原則。而這個決定直接來自測試現場的觀察：使用者的挫折感通常不是因為步驟多，而是因為不確定剛才那一下到底有沒有生效。

另一個要解的是讓 AI 被看見。自動優化有個奇怪的問題：它做得越好使用者越無感 —— 沒有畫面、沒有動作，對使用者來說就等於什麼都沒發生。處理方式是讓它自己留下紀錄：系統會自動存下每週報告並主動通知使用者，優化不再是看不見的背景行為，而是每週會來敲你一次、告訴你這禮拜幫你做了什麼。

無障礙不是設計做完再回頭稽核的事。做法是先訂出一組通過檢驗的色票，之後所有介面都只能從這組裡取色；對比度、字級、觸控範圍在元件階段就寫進規範，而不是等驗收才提。把合規變成預設值，設計師就不需要每次重新判斷。

再加一條硬規則：顏色不單獨承載訊息。 所有狀態一律同時具備顏色、圖示與文字。這條規則一次解決兩個問題 —— 色覺障礙的使用者能正確判讀，而多語言版本在文字長度變動時也不會失去語意。

交付的不是一份色票表，是一套別人接得下去的系統：色彩 token 與狀態定義、字級階層、卡片與導覽列、按鈕與輸入元件、背景層級，以及實際畫面的組裝範例。

規格標到可以直接實作的程度 —— 主要按鈕寬 276pt、高 46pt、左右內距各 15pt，三種尺寸（276 / 130 / 94pt）、四種狀態（主要、次要、警示、停用）。寫到 pt 是刻意的。 規格靠口頭傳、實作各做各的，這個虧吃過一次就夠了。

交付的最後一件事也是同一個道理：除了 Figma 檔跟上傳到 Zeplin 的標註，微動畫的程式碼是我自己寫的。給工程師一段動態影片是「請求」，給他程式碼是「已經決定好的事」。

可以驗證的部分：產品上線了；色彩系統全數通過 WCAG AA、主要文本達 AAA；設計規範標到 pt 交付出去；五個發現裡有兩個越過 App 的邊界，進到硬體團隊手上。這些前面幾章都有憑據，這裡不重複。

值得多寫幾句的是，重做一次我會改什麼。

取樣少了對照組。 鎖定對網路術語最不熟悉的人是刻意的，但所有樣本都落在同一端，我就分不出這些卡點是「這個族群特有」還是「所有新手共通」。下一次我會保留主要族群，另外找幾位有網路背景的人當基準線 —— 不是為了平衡，是為了知道每個問題到底有多普遍。

沒有先量基準數據。這是我在這個專案上最大的失誤。 當時覺得看行為就夠了，事後才發現：少了改版前的數字，就沒辦法證明改版後真的變好 —— 這也正是這篇案例只寫得出質性成果的原因。

決策者進場太晚。 A 和 B 提出去之後，才知道方向要往別的地方走。如果在提案前先用低成本的草圖對齊一次判斷標準，探索的方向會更準 —— 極端提案還是要提，但可以少繞一圈。

如果重做，我會在測試開始前先定好這五個指標，並在改版前後各量一次：