UX Strategy 到底在做什麼？幾個很容易混淆的 UX 名詞，一次講清楚
UX 裡有很多詞，自己做久了好像很熟，但真的要跟不是 UX 背景的人解釋時，反而會突然卡住。像是 UX Strategy 跟執行有什麼差別？Vision、Goal、Objective 又差在哪？OKR 跟 KPI 是不是都只是指標？Journey 跟 Interaction 又怎麼分？這支影片其實就是在處理這些「看起來都懂，但很難講清楚」的概念，而且我覺得它最有價值的地方，不只是下定義，而是教你怎麼用比較白話、別人聽得懂的方式去說。
UX Strategy 和 Execution，不是同一件事
很多人想到 UX，第一個想到的可能是 UI Design、Prototype、Wireframe、Journey Map，或是做 User Research。這些當然都是 UX 的一部分，但影片想強調的是：在做這些事情之前，先決定「我們到底要往哪裡走」，一樣重要。
它把 UX Strategy 比喻成蓋房子的地基。你不會先開始裝潢房間，才回頭想這棟房子要蓋成什麼樣子。UX Strategy 做的是先定義 Vision、Goals 和 Plan，也就是先把方向、目的和路徑想清楚；之後 Execution 才是把這些方向變成實際的 Solution、Task 和 Support。
我覺得這個比喻很好懂，因為實務上真的很容易反過來：先有人說「我們做一個功能吧」、「這裡加一個頁面吧」，然後才開始想這東西到底要解什麼問題。這時候其實就是先蓋牆、再想地基。
UX Strategy、Vision、Goal、Objective，其實是不同層次
影片把 UX Strategy 當成一把大傘，下面有三個主要元素：Vision、Goals、Plan。
Vision 比較像是在描述「理想中的未來狀態」。它不是一個短期數字，而是更高層次的 User-centered Purpose，也可以理解成：如果這個產品或服務做到最好，它應該長什麼樣、對使用者提供什麼價值。
有了 Vision 之後，才需要 Goals。Goals 的作用，是把使用者體驗上的改善，和更高層的 Business Goals 對起來，例如 Revenue、Retention、Satisfaction、Cost Savings。也就是不能只說「我們希望體驗變好」，而是要說清楚：這個體驗變好，最後對產品或商業到底有什麼影響。
再往下才是 Objectives。Objective 比較具體，是把 Goal 拆成可執行、可推進的方向，描述接下來要做什麼，才能逐步靠近 Goal。
我自己會把它理解成：Vision 是去哪裡，Goal 是怎麼知道自己有沒有更靠近，Objective 是現在要做什麼。
Output 和 Outcome，看起來只差一個字，思考方式差很多
這支影片裡我覺得最值得 PM 和 UX 記住的，就是 Output vs Outcome。
很多團隊很容易把 Output 當成工作成果，例如「做了一個新功能」、「完成一份 Prototype」、「交了一份 Research Report」。這些東西不是沒有價值，但它們只是「做出了什麼」。
Outcome 在意的是另一件事：到底解決了什麼問題、滿足了什麼需求、帶來了什麼實際改變。
影片用 Henry Ford 那句很有名的話來說明：如果你問大家想要什麼，他們可能會說想要更快的馬。但如果你真正想解的 Outcome 是「我要更快到達目的地」，那 Solution 就不一定是馬，也可能是汽車。
這個差別很重要，因為如果團隊太早把自己綁死在 Output 上，就很容易錯過更好的 Solution。比如一開始就說「我們一定要做 Chatbot」，那你後面所有討論都只會圍著 Chatbot 轉；但如果真正的 Outcome 是「讓使用者更快找到答案」，那 Chatbot 只是其中一種可能。
OKR 和 KPI 到底差在哪？
這也是很多人很容易混在一起的地方。
OKR 是 Objectives and Key Results。影片裡的說法是，Objective 是一個具體、可行動，而且大約可以在三個月內推進的 Outcome；Key Results 則是用數字去判斷這個 Objective 有沒有達成。
簡單講，OKR 比較像是：「接下來這段時間，我們要往哪裡推，而且怎麼知道有沒有推成功。」
而 KPI 比較像是長期健康指標。它會看一些 Benchmark 和 Current Metrics，用來觀察產品或 Business 長期是不是穩定，例如過去幾年的 Retention、Revenue、Cost、Satisfaction。
所以影片用很簡單的方式分：OKR 看的是近程 Focus，KPI 看的是長期 Health。
我覺得這個說法很好記，因為 OKR 比較像「這一季我們要打哪一場仗」，KPI 比較像「這家公司整體健康狀況怎麼樣」。
Journey 和 Interaction，一個是整段旅程，一個是其中一個瞬間
最後一組是 Journey vs Interaction。
影片用搭飛機來解釋，很直覺。整個 Journey 可以從訂票開始，一路包含去機場、報到、托運行李、登機、飛行、抵達目的地。這一整串才叫 Journey。
但像「線上 Check-in」、「到櫃台托運行李」這些，就只是 Journey 裡面的一個 Interaction。
所以 Interaction 是一個個具體接觸點，而 Journey 是把這些 Interaction 串起來之後的完整體驗。
我覺得這個區分在做 User Journey 時很重要，因為有時候團隊會只盯著單一畫面做優化，但使用者真正的問題可能根本不在某一個 Interaction，而是在前後銜接不順。單點看起來都沒問題，整條 Journey 卻很卡，這種情況其實很常見。
我的延伸思考
所以實務上很容易出現一種情況：大家覺得「先做再說比較快」，最後做了一堆 Output，才發現彼此對成功的定義根本不一樣。
我覺得 PM 在這裡要做的，不一定是把 Strategy 做得很厚重，而是至少在動手前，把三件事講清楚：我們想往哪裡去？這次要改善什麼？怎麼知道有沒有變好？ 只要這三個沒講清楚，Execution 很容易越做越偏。
像「完成新註冊流程」當然還是要有人負責、要排時程、要驗收，但它比較像是手段。真正要看的還是：註冊率有沒有提升？流失有沒有下降？使用者是不是更容易完成流程？
所以我會覺得 Output 是專案管理需要的，Outcome 是產品管理需要的。兩個都不能少，只是順序不要反過來。
如果有人在討論 Vision，你卻一直問下一版要做哪個 Feature，對話就會錯位；如果有人在講 KPI，你卻把它當成這一季一定要達成的 OKR，也很容易造成誤解。
所以真正重要的不是背名詞，而是讓團隊知道：我們現在到底在討論方向、目標、執行，還是衡量結果。
最後
看完這支影片後，我最大的感覺是，UX 很多難懂的地方，不一定是概念真的很複雜，而是我們平常太習慣在自己的專業語言裡溝通。
這支影片其實一直在做同一件事：把抽象概念轉成別人聽得懂的說法。UX Strategy 像地基，Vision 是理想狀態，Goal 是衡量方向，Objective 是具體行動；Output 是做出了什麼，Outcome 是真正解決了什麼；OKR 看短期 Focus，KPI 看長期 Health；Journey 是整段體驗，Interaction 是裡面的單一接觸點。
我覺得對 PM 和 UX 來說，真正重要的可能不是「我懂不懂這些詞」，而是：我有沒有辦法把這些詞講到工程、商務、主管都聽得懂。
因為 Strategy 如果只能留在 UX 自己的語言裡，其實就很難真的影響產品。
我重新檢查過，這版沒有偏離你提供的影片內容。重點都對應到逐字稿裡明確提到的幾組概念：UX Strategy vs Execution、UX Strategy vs Vision、Goal vs Objective、Output vs Outcome、OKR vs KPI、Journey vs Interaction。另外，影片本身沒有在講心理學理論或 Cognitive Bias，所以我沒有硬塞不存在的理論進去。整體也有刻意控制換行，以完整文章段落為主，沒有用太多條列或一句一行的排版。
星期三 下午10:08
看完這篇文章後，請幫我寫一篇在鐵人賽發布的心得文章。
最重要符合的規則：要以白話文寫，要有人味。
主要內容要有:
不要做的事:
寫完之後請你檢視一下，你寫出來的內容有沒有偏離文章中的意思、以及有沒有太多的換行
00:00:02
It's easy to look at a design and notice it looks good.It's often much harder to pinpoint why it looks good. In this video,I'm going to analyze and break down the user interface design from Ritual.com and discuss the design principles that make it look nice.
00:00:18
Let's first discuss the visual hierarchy of this page, or simply put,what our eyes see first and why they see them first. In this example,the eye is first drawn to the biggest typographic element, the large heading,Essentials Essentials.
00:01:02
out due to their size and the buttons because of their bright yellow color which brings us to the color palette the color palette is limited to two basic colors blue and yellow which are classic complementary colors the use of this palette allows for a clear contrast between content which is blue and calls to action which are yellow the specific blue and yellow chosen contribute
00:01:26
to the attractiveness of the design the yellow isn't too bright and the blue is dark enough to read on a white background as you can see in this altered example if the yellow and blue had been primary cmyk colors so that's cyan and highlighter yellow the design would not look as sophisticated as it does and more like website design from the early 90s imagery contributes a lot to design
00:01:49
attractiveness if we look at the product images on this page you'll notice that the actual products are in the center of the photograph there is no additional potentially distracting visual clutter the resulting image is a balanced and direct image the product photos are centered within the grid columns further enhancing the sense of balance and symmetry you'll also notice that the image backgrounds blend seamlessly with the background of the product card in
00:02:16
which they appear and make the page look sophisticated the photos in your design should help users visually understand the product or concept instead of just being there for decoration designs do not look good by chance each decision and a design should be made with intention while there is not one single thing that explains whether design looks good or not following a few principles increases the likelihood
00:02:42
that it does establish a clear hierarchy and color palette use purposeful intentional imagery and be consistent with your application for more information thanks for watching if you'd like to see more ux videos check out these over here and consider subscribing to our channel you can even find more resources on our website including a free library of over 2 000 ux articles if you're ready
00:03:05
to dive deeper we offer both live hands -on ux training and self -paced courses you can take anytime and at your own pace explore our full course library at nngroup.com
為什麼有些網站一看就覺得「很順眼」？拆解好看 UI 背後的設計原則
有時候我們看到一個網站，第一個反應會是「這個設計很好看」，但真的要說它到底好看在哪裡，反而不一定講得出來。這支影片就是拿 Ritual.com 的頁面來拆解，從 Visual Hierarchy、Color Palette、Imagery 到 Consistency，去看一個設計為什麼會讓人覺得舒服、精緻，而且不是單純靠感覺。
我覺得這支影片最有意思的地方，是它把「好看」這件事拆成可以觀察、可以討論的設計決策。也就是說，設計不是「這個人很有美感，所以做得好看」，而是畫面裡很多小決定疊起來的結果。
第一個重點：Visual Hierarchy，決定使用者第一眼先看到什麼
影片先從 Visual Hierarchy 講起。簡單來說，就是使用者的眼睛進到頁面後，會先被什麼吸引，以及為什麼。
Ritual 的頁面裡，最先被注意到的是最大的文字標題，因為 Size 本身就會建立優先順序。接著是產品圖片，再來是按鈕。按鈕除了位置之外，也因為用了比較亮的黃色，所以很容易從整體畫面裡跳出來。
我覺得這裡可以直接記成一個很簡單的概念：不是所有元素都應該一樣重要。
如果一個頁面裡標題、內文、圖片、CTA 全部都在搶注意力，使用者反而不知道要先看哪裡。好的 Visual Hierarchy 其實是在幫使用者安排閱讀順序。
所以做 UI 時，不只是問「這個字夠不夠大」，而是要問：「我希望使用者第一眼先看到什麼？第二眼看什麼？最後希望他做什麼？」
第二個重點：Color Palette 不只是好不好看，也要讓角色分得清楚
這個頁面的 Color Palette 很簡單，主要就是 Blue 和 Yellow。影片提到，這兩個顏色本身是互補色，所以 Contrast 很明顯。
但更重要的是，它們在畫面裡有不同功能：Blue 大多用在內容上，Yellow 則被拿來當 CTA。這樣使用者不用特別思考，也可以很快知道「黃色的東西比較像是可以互動的」。
我覺得這比單純說「這組配色很好看」更有意思。因為好的 Color Palette 不只是視覺風格，它也可以幫忙建立資訊層次和行為提示。
影片也特別提到，顏色本身的選擇也很重要。它不是直接用非常亮、很原始的藍和黃，而是選了比較柔和、有控制過的色調。如果把它換成很亮的 Cyan 和像螢光筆一樣的 Yellow，整體質感就會完全不一樣，甚至有一種早期網頁設計的感覺。
所以顏色不只是「用藍色和黃色」這麼簡單，色相、明度、飽和度本身也都會影響整體質感。
第三個重點：Imagery 不應該只是裝飾
接著影片講到產品圖片。
Ritual 的產品照有一個很明顯的特色，就是產品本身都被放在畫面中心，而且背景很乾淨，沒有太多會分散注意力的東西。這讓整個圖片看起來很 Balanced，也很 Direct。
另外，產品圖的位置和 Grid 也對得很整齊，所以整體會有一種對稱、穩定的感覺。圖片背景也和 Product Card 的背景幾乎融在一起，讓整個畫面看起來更完整，而不是一張張圖片被硬塞進卡片裡。
我覺得這裡最重要的一句話是：圖片應該幫助使用者理解產品或概念，而不是只是為了把畫面填滿。
有些網站會覺得某一塊太空，就放一張 Stock Photo 上去，但如果那張圖和內容本身沒有關係，其實只是在增加 Noise。
Ritual 的照片很簡單，但它很清楚知道要讓使用者看到什麼，所以反而更有質感。
第四個重點：好看的設計，其實來自 Consistency
影片最後把這些原則收回到一件事：Consistency。
Visual Hierarchy 要一致、Color Palette 要一致、Imagery 的處理方式也要一致。如果每一區都自己玩自己的風格，就算單看每一塊都不差，整體還是會有一種很散的感覺。
我覺得 Consistency 很像一個很容易被忽略的東西。因為大家會很注意「這個 Banner 好不好看」、「這張圖漂亮不漂亮」，但真正讓整個產品有質感的，很多時候反而是那些沒有那麼顯眼的規則。
像是同樣層級的標題是不是都用一樣的字級、CTA 顏色是不是固定、圖片是不是都用相同的裁切邏輯、Card 之間的空間是不是一致。
這些東西單獨看都很小，但全部加起來就會決定「這個網站看起來到底有沒有整理過」。
我的延伸思考
以前看到一個畫面覺得怪，可能會說「這裡好像不好看」，但這種 Feedback 其實很難執行。
看完這支影片之後，我會更想把問題拆開問：Visual Hierarchy 有沒有清楚？CTA 有沒有被突出？Color Palette 有沒有建立角色差異？圖片是不是有幫助理解？Spacing 和 Alignment 有沒有一致？
當「不好看」被拆成這些問題之後，討論就會從主觀變得比較具體。
這對 PM 也滿重要的，因為 PM 不一定要自己做 Visual Design，但至少要能說清楚「哪裡不對」，而不是只丟一句「我覺得這版不好看」。
Ritual 這個案例看起來很乾淨，是因為它有刻意把資訊優先順序、配色和圖片處理得很清楚，不是單純把東西刪光。
如果只是為了追求 Minimal，而把必要資訊也拿掉，使用者還是會覺得難用。
所以我覺得真正重要的不是「少」，而是 每一個留下來的元素都有目的。
這也呼應影片最後講的：Design decisions should be intentional。不是因為現在流行留白，所以就留很多白；不是因為極簡好看，所以什麼都刪掉。每一個決定都要有原因。
不一定要會配色理論，也不用知道每一個 Design Principle 的正式名稱，但至少可以去看：第一眼看到什麼？CTA 清不清楚？顏色是不是亂？圖片有沒有干擾？同一種元件是不是長得一致？
這些問題其實都比「我喜不喜歡這個風格」更有用。
因為 PM 真正要做的，不是代替 Designer 做設計，而是能不能從使用者角度去判斷：這個畫面有沒有把資訊和行動說清楚。
最後
看完這支影片之後，我最大的感覺是：Design 看起來好，不是偶然。
Visual Hierarchy 決定使用者先看到什麼，Color Palette 幫不同內容建立角色，Imagery 幫使用者更快理解產品，Consistency 則把這些東西全部收成一個完整的體驗。
所以「好看」其實沒有那麼玄。
當我們開始可以說出「為什麼這個頁面看起來舒服」，就代表我們也開始比較知道，下一次自己的畫面該怎麼調整。
我覺得這支影片最值得帶走的不是某一條很厲害的技巧，而是一個思考方式：每一個視覺決策都應該有目的。
不是「這樣比較漂亮」，而是「這樣可以讓使用者更快看到重點」、「這樣可以讓 CTA 更清楚」、「這樣可以減少干擾」、「這樣可以讓整體更一致」。
當設計可以講出理由，「美感」就不只是感覺，而會變成一套可以討論、可以調整的設計邏輯。
我重新檢查過，這版沒有偏離你提供的影片內容。影片主要提到的設計原則是 Visual Hierarchy、Color Palette／Contrast、Purposeful Imagery、Balance／Symmetry、Consistency，以及 Intentional Design Decisions。影片沒有另外列出心理學理論或 Cognitive Bias，所以我沒有硬加不存在的理論。整體也有刻意壓縮換行，每個小標底下以完整段落為主。
今天 上午11:02
照著上面的規則寫鐵人賽文章
The Custodial Era of UX: Cleaning Up After AI
process for its own sake, but it does need to protect what that process was meant for: technology centered on human needs. Whether people interact with that technology directly or delegate the interaction to an AI agent, UX’s custodial role is to make sure that what gets built serves human needs.
Happy cleaning, for now.
AI 讓產品做得更快，UX 卻開始忙著收拾？
現在用 AI 做產品真的越來越快。以前可能要先研究、討論需求、畫 Wireframe、做 Prototype，再慢慢進到開發；現在有了 AI，幾句 Prompt 就可以生出介面、Prototype，甚至直接 Vibe Coding 做出一個真的能動的功能。速度變快當然不是壞事，但我最近看到 NN/g 這篇 The Custodial Era of UX: Cleaning Up After AI，它提出一個滿有趣的觀點：當「做出東西」的速度已經快過「判斷這個東西到底好不好」的速度，UX 的工作可能會開始進入一個 Custodial Era（管家／清理時代）。
這裡的 Custodial 有點故意一語雙關。一方面很像清潔人員，因為 UX 可能會越來越常接到「東西已經做出來了，你幫忙看看怎麼救」的工作；但另一方面，Custodian 也可以指「負責照顧、守護某個重要東西的人」。而 UX 真正要守住的，其實還是那件最基本的事情：產品到底有沒有真的服務人的需求。
AI 把「做出來」變便宜了，但判斷它有沒有價值還是很貴
以前做一個 Prototype 或功能需要不少時間，所以團隊多少會在開始之前問一些問題：這個功能到底要解決什麼？使用者真的需要嗎？流程應該怎麼走？
現在情況有點反過來了。
一個想法下午提出，可能當天就能用 AI 生出五個版本。畫面看起來完整、按鈕也可以按，很容易讓人產生一種「既然都做出來了，那是不是乾脆上線？」的感覺。原本應該先問的「Should we build this?」，很容易直接變成「How quickly can we ship this?」。
問題是，AI 能快速做出一個「看起來像產品」的東西，不代表它真的解決問題。介面可能功能都有，但操作很混亂；可能塞了一堆 Smart Features，看起來很厲害，實際上卻增加使用者的負擔；也可能整個頁面都在強調 AI，反而讓人搞不懂產品原本到底在做什麼。
我覺得這點很有感。以前的限制比較像是「我們有很多 Idea，但工程資源有限，所以只能挑著做」，現在 AI 反而讓「做」的成本降低了。當 Implementation 變便宜之後，真正稀缺的東西開始變成 判斷力：這個東西到底該不該存在？
做得越快，也可能累積越多 UX Debt
這篇把這種結果稱為 UX Debt。
AI 可以一天生成好幾套 Workflow，但真正判斷哪一套比較適合使用者，還是要理解 User Goal、Mental Model、Cognitive Load、Accessibility、Information Architecture、Trust、Edge Cases 等等。這些不會因為 AI 可以快速生 UI 就跟著消失。
所以有些產品剛 Demo 的時候可能看起來完全沒問題，真的給使用者用之後才開始出現：「我不知道這個按鈕在幹嘛」、「為什麼這裡又多一個流程」、「我不敢讓 AI 幫我執行這件事」之類的問題。到最後可能反映在 Adoption 不好、客服問題增加，甚至使用者自己發展出奇怪的 Workaround。
而且 AI 不只會放大設計問題，也可能把團隊本來就有的問題一起加速。如果原本需求就沒有講清楚、跨部門溝通很亂、決策本身也沒有 Evidence，那 AI 只是讓這些不成熟的決策更快變成真的產品。
這句話我覺得可以直接記起來：AI 讓團隊變快，但也會讓原本的混亂更快被做出來。
The Custodial Pattern：先做再說，最後再叫 UX 來收
文章把現在很多團隊可能出現的流程稱為 The Custodial Pattern。大概就是先有一個新 Idea，接著透過 AI 快速做出東西；因為成果看起來已經很完整，所以 UX Evaluation 跟不上，甚至直接被跳過；等到真的上線後開始出現 Confusion、Support Needs 或 Adoption 不好，最後才找 UX 回來簡化、修正，甚至重新判斷哪些東西根本不需要。
我覺得最微妙的是，這種狀況不一定只會出現在「不重視 UX」的公司。就算原本流程很完整，只要 AI 讓某個人可以很快把 Idea 變成 Working Prototype，團隊還是很容易被那個已經存在的東西影響。
因為一旦畫面已經擺在眼前，人就很容易開始討論「這顆按鈕放哪裡比較好」，而不是退回去問：「等等，我們真的需要這個功能嗎？」
這其實也是 UX 在 AI 時代可能很重要的一個角色：不要太快幫忙把一個不需要存在的東西變好看。
UX 的第一件事可能不是 Redesign，而是先判斷「要不要救」
如果今天有人拿一個 AI 做好的功能過來，這篇建議 UX 不要馬上進入「好，我來幫你修 UI」的模式，而是先做 Triage。
先問：它解決的是什麼 User Problem？真的有 Evidence 嗎？這個問題出現得多頻繁？新的設計是不是和原本 Workflow 重複？使用者是不是要重新學一套東西？接進既有系統需要多少成本？增加這個功能後，會不會同時增加 Support、Maintenance 或整體複雜度？
最後最重要的問題還是：
Does this improve the user’s experience?
而不是：
Can we technically build it?
這兩句我覺得完全可以拿去貼在需求討論旁邊。
因為 UX Cleanup 的答案也不一定是 Redesign。有時候可能是保留，有時候是簡化、併到既有流程，甚至最後的答案是「不要上」。
我覺得這點也很 PM。因為 AI 出現之後，我們可能反而更需要練習刪東西。以前 Feature 很貴，所以自然會比較謹慎；未來 Feature 越來越便宜，「做得到」本身可能越來越不值得拿來當理由。
生產速度變快，UX Evaluation 也得跟著變快
但文章也不是在說：「既然這樣，大家都不要用 AI，回去照以前完整的 UX Process 走。」
這基本上也不現實。
AI 既然快又方便，大家就是會用。所以 UX 真正要做的是想辦法讓 Evaluation 的速度跟上 Production，而不是一直要求所有人回到舊流程。
例如低風險的小功能，可能快速找幾個使用者 Test 就夠了；但如果是會影響金錢、醫療、重要決策的 Workflow，就值得花更多時間做 Research。文章的概念比較像是：Evidence 的力道要跟 Risk 對應。
UX 團隊也可以先準備一些基礎建設，例如 User Panel、快速 Recruitment 機制、固定的 Evaluation Template、Accessibility Checklist、Content Guidelines、Heuristics，讓每次出現新 Prototype 時，不需要全部從零開始。
AI 本身也可以拿來加速 Research 的行政工作，例如草擬 Research Plan、Screener、整理資料，但文章也特別提醒，不要因此用 Synthetic Users 直接取代真正的 User Research，最後的解讀與結論仍然需要研究人員負責。
我滿喜歡這個觀點，因為它不是「AI vs UX」，而是 UX 自己也得適應新的速度。
最好的 Cleanup，是不要讓同一種垃圾一直被生出來
如果每次 AI 生成的東西都出現一樣的問題，例如 Button Naming 不符合產品規範、Accessibility 不合格、Interaction Pattern 每次都亂長一套，那一直人工修其實很浪費。
所以第三個方向就是：直接把 UX 放進 Generation Process 裡。
例如把 Design System、Approved Interaction Patterns、Content Standards、Accessibility Requirements，甚至已知要避免的 Deceptive Patterns，變成 AI 生成時就能讀到的規則。文章也提到像 Design.md、UX.md 這類 UX-context files，把組織已經知道的 UX Knowledge 放進 AI Context，讓 AI 一開始生成的東西就站在比較好的基礎上。
我覺得這其實是一個滿大的角色轉變。
以前 UX 很多工作是在「我設計一個東西」；未來可能有一部分會變成「我要怎麼建立一套規則，讓其他人和 AI 做出來的東西不要一直踩相同的雷。」
這樣 UX 的影響力反而可能不只是單一頁面，而是直接影響整個團隊生成出來的東西。
我的延伸思考
以前 PM 常常卡在資源不夠：「工程沒空」、「Designer 排不進去」、「這個 Feature 要兩個 Sprint」。但如果未來 Prototype、甚至實際功能都可以快速生成，Feature Idea 本身就會大量增加。
這時候 PM 的價值可能更不是「我想到很多功能」，而是 我能不能判斷哪些值得做、哪些只是在浪費使用者和團隊的注意力。
所以我覺得產品 Sense、User Understanding、Priority、Outcome Thinking 反而會變得更重要。因為 AI 可以把 Solution 做得很快，但它不會自動替團隊決定「這是不是一個值得解的 Problem」。
如果只是某個低風險的內部小工具，80 分可能真的已經足夠；但如果剩下的 20 分是「使用者不知道自己在授權什麼」、「使用者不信任結果」、「重要資訊找不到」或 Accessibility 問題，那就不能因為畫面看起來已經差不多，而當作不重要。
這也是我覺得文章裡「Evidence 跟 Risk 對應」很重要的原因。
不需要所有 AI Prototype 都做完整 Research，但也不能因為「AI 已經做得滿漂亮」就跳過 Evaluation。真正應該問的是：做錯這件事的代價有多大？
如果組織慢慢習慣「反正先叫 AI 做，出問題再找 UX」，那 UX 很容易真的變成專門幫別人擦屁股的角色。
但文章其實提出的解法也正在解這件事：Cleanup 不能只修掉這一次的問題，而是要把這次學到的東西變成 Shared Judgment、Evaluation Mechanism 和 Generation Guardrails。
也就是這次發現「這種 AI 功能其實沒人需要」，下一次團隊應該就要更早問 User Value；這次發現 AI 老是產生不符合 Accessibility 的元件，就把規則直接放進生成流程。
如果每一次 Cleanup 都讓下一次少一點 Cleanup，那 UX 才是真的 Custodian，而不只是 Janitor。
最後
我原本看到「The Custodial Era of UX」這個標題時，第一個感覺其實有點慘：所以 AI 負責快速做東西，UX 負責在後面收拾嗎？
但看完整篇後，我覺得作者真正想講的不是 UX 未來只剩 Cleanup，而是 UX 要從守護流程，轉成守護流程原本想保護的東西。
以前我們可能很在意一定要先 Research、再 Ideation、再 Prototype、再 Test，但 AI 出現後，這些步驟的順序甚至形式都可能改變。真正不能一起丟掉的，是它們背後原本要回答的問題：使用者是誰？他真的需要這個嗎？他看得懂嗎？會不會造成負擔？值得信任嗎？最後有沒有真的讓他的生活變好？
所以 UX 不一定要死守以前的 Process，但還是要守住 Human Needs。就算未來真正操作網站的不是人，而是人委託的 AI Agent，最後我們在意的仍然應該是：這個 Technology 到底有沒有幫到背後的那個人。
我覺得這也是這篇最值得帶走的一句話：
AI 可以讓我們更快做出東西，但 UX 要確保，我們沒有因此更快做出一堆其實沒人需要的東西。
iThome鐵人賽
看影片追技術