設計與工程解決不同的問題；AI正在忘記這一點

當組織透過工程工作流採用AI時，設計工作往往被拉進管道，變成程式碼的提示生成器，或者只是加快產出速度的另一種方式。設計師不得不適應這些流程，因為通常只有這些流程可用，但這種適應將焦點從設計本應進行的決策上轉移開。

設計與工程的交叉確實重要，它可以改善雙方的決策。當設計師理解工程師如何構建、編碼和測試時，他們能做出更好的設計決策。當工程師理解設計思維時，他們能更周到地構建產品。但交叉不等於做同樣的工作，或使用同樣的流程。

AI最初在工程領域顯現的收益，主要體現在更快的程式碼生成、自動化管道和系統效率提升上。這並不奇怪。工程工作已經以速度和產出為導向，AI則同時加速了這兩者。當工程引領組織的AI探索時，其工作流和最佳化目標將塑造整個過程：組織會選擇適合工程管道的工具，團隊以速度和產出衡量成功，開發者圍繞交付程式碼設計工作流。當設計師採用這些工具時，焦點就轉向了速度和可交付性，偏離了設計本應做的決策：我們是否應該構建這個功能？這會將誰排除在外？當順利路徑失敗時，什麼會出問題？這些正是這些工作流所沒有留出空間的工作。

設計工作並非從工程工作流的起點開始。它開始得更早，在模糊性、相互衝突的約束和尚未有明確答案的問題中。它在承諾解決方案之前理清問題空間。這需要一個不同的過程，而不是工程過程的加速版本。當設計師被賦予工程工作流時，工作開始發生變化：更多時間花在學習工具上，而不是從事實際工作；團隊開始最佳化產出而非決策質量；設計創造的價值（風險降低、問題框架、共享理解）變得更難看見，也更容易被削減。這並不是因為組織明確決定設計應該像工程一樣工作，而是當只有一個學科塑造工具和工作流時，系統會自動產生這種結果。

設計工作的實際作用是，在構建任何東西之前做出更好的決策。它識別什麼不該構建，在風險變得昂貴之前將其暴露，並創造共享理解，使團隊能夠自信地朝正確方向構建。無論設計師是在為不熟悉的使用者選擇導航模式、為螢幕閱讀器構建內容層次，還是確定在開始設計新功能之前需要研究哪些問題，這一點都成立。放慢這些早期決策通常能透過防止返工和後期失敗來加速整體交付。這在無障礙工作中最為明顯。團隊可以快速生成UI，生成能透過自動化檢查的東西。但透過測試並不等於對使用螢幕閱讀器、開關裝置或語音控制的人來說是可行的。這些失敗不會以程式碼錯誤的形式出現，而是後來以真實人的糟糕體驗出現。發現這些失敗需要判斷力、模式識別和領域知識，需要理解互動和使用者。更快的產出並不能解決這個問題。加速錯誤的部分沒有幫助，只會讓你更快地到達錯誤的地方。

這並不是反對在設計中使用AI的論點。而是主張以符合設計實際工作的方式來使用AI。使用AI更快地生成程式碼並不能使結果更易訪問。使用AI來壓力測試互動則確實有幫助。這種質疑——鍵盤使用者會遇上什麼？焦點順序在哪裡崩潰？螢幕閱讀器會宣告什麼？——擴充套件了已有的思考。這就是AI作為思考夥伴，而非生產工具。當使用得當時，AI可以透過更早地發現風險、挑戰假設、探索邊緣情況和綜合研究來支援設計所需的思考。在無障礙工作中，早期關於互動模式、元件結構和內容層次的決策可以防止下游任何工具都無法捕獲的失敗。這樣使用AI，它支援判斷而非取代判斷。

任何AI倡議更重要的問題不僅僅是“我們如何更快？”而是“工作的哪些部分可以藉助AI改進——哪些部分需要保持緩慢？”設計和無障礙從業者最有資格回答這個問題，但前提是他們在問題被提出時在場。許多組織缺少的是認識到設計師帶來了不同的方法，這種方法暴露了可用性、理解性和無障礙方面的風險，並以決策質量而非產出速度來衡量成功。這不是軟技能。這是基礎設施。它是防止代價高昂的失敗並確保構建的東西真正適用於人的基礎性思考。

目標不是將AI從工程主導轉向設計主導。那將造成另一種不平衡。純工程方法過度最佳化速度；純設計方法可能過度強調開放探索。產品開發是一個共享的決策系統，而不僅僅是執行。AI的採納需要工程、設計和產品共同領導。在實踐中，這意味著：將AI工具置於工程、設計和產品工作流中評估；以包含決策質量的方式定義成功；明確哪些思考需要保護；讓兩個學科參與工具和工作流的定義。AI不應該只是讓團隊更快，它應該幫助他們做出更好的決策。只有設計、工程和產品共同塑造AI的使用方式，而不是讓一方適應另一方的工作方式時，這一點才能實現。