用戶界面設計的未來：下一代 UI 工具

自第一代 Adob​​e Photoshop 以來，UI 設計工具已經取得了長足的進步，這是一個旨在編輯照片而不是創建動態用戶界面的程序。 當前一代的工具，例如 Adob​​e XD、Figma 和 Sketch，讓我們的工作變得更輕鬆、更快捷。

然而，我們日常工作流程中的低效率比比皆是，當我們可以設計人們想要使用的產品時，我們正在浪費寶貴的時間和資源。 今天可用的設計程序優於我們開始使用的程序，但它們未能利用當前的技術並阻止我們充分發揮作為 UI 設計師的潛力。

是時候使用新一代的 UI 工具了。

集成設計和代碼

未來的用戶界面工具將設計和代碼結合在一起，為設計人員和開發人員提供更加無縫的體驗。 我們當前的工具並不能幫助我們設計 Web UI； 他們正在幫助我們設計 Web UI 的抽象表示。 Figma 和 Sketch 製作的模型與源代碼斷開連接。

今天，許多設計師都知道 HTML 和 CSS 的基礎知識。 一些強硬派在代碼中進行設計，但這對複雜的項目無效； 設計師需要能夠在承諾之前快速探索概念驗證。

軟件開發人員擁有 Visual Studio Code，這是一種將代碼編輯和開發結合起來的工具，允許工程師在同一環境中構建、測試和調試代碼。 同樣，設計人員需要一個可視化開發環境，該環境既能提供完整的設計功能，又能生成可用於生產的代碼。

這就是未來的發展方向。

並行創建將取代設計/開發人員交接

設計師和開發人員之間有太多的來回，尤其是在交接階段。 在某些情況下，交接非常耗時且令人筋疲力盡，以至於工作質量受到影響。 隨著下一代設計工具與源代碼交互，開發人員將不再單獨負責構建 UI。 相反，他們將能夠專注於開發將產品的 UI 連接到其後端並使其正常運行的邏輯架構。

設計師將使用嵌入的代碼奠定 UI 的基礎，開發人員將在此代碼的基礎上為產品注入活力。 設計師不再需要用諸如“請添加 16 像素而不是 8 像素的填充，如模型中所示”之類的請求來嘮叨開發人員。 開發人員不必停下來提出設計問題，例如“該組件應如何在平板電腦和台式機斷點之間擴展？”

相反，設計師和開發人員將在更重要的問題上合作，例如設計方法在給定時間和預算的情況下是否可行，或者是否所有 UI 組件的狀態都已得到解決。

設計 UI 工具和開發人員軟件將保持一致

當前的工具依賴於定制的編程模型來生成設計組件。 這些模型通常不如 CSS 強大，並且不允許設計人員查看其設計文件下的自動生成代碼——這些代碼最終必須導出為 HTML、CSS 或 JavaScript。 如果我們的工具原生使用 HTML 和 CSS 會簡單得多。

例如，CSS 使用盒子模型，它要求將每個頁面上的 HTML 元素放置在一個盒子內，該盒子被編碼以定義其高度、寬度、邊框和填充。 Figma 通過其自動佈局功能接近提供此功能。 但如果 Figma 使用已經為大多數 Web UI 提供支持的盒子模型，開發人員將需要更少的翻譯和導出。

樣式繼承也是如此，它控制在沒有為特定元素指定樣式時發生的情況——類似於默認值。 CSS 使用它，但大多數不是為特定於 Web 而創建的設計工具都沒有。

我們需要我們的工具來輸出 Web 視圖，而不是靜態畫板或模型。 我們不需要 HTML 和 CSS 模擬器。 我們需要 HTML 和 CSS。

模型將過時

與其扔掉模型，不如把模型扔到門外。

模型留下了太多沒有答案的問題。 為每個數字環境設計一個是不可行的。 今天，設計師為 320 像素、834 像素和 1440 像素的屏幕寬度構建佈局； 但是如果部分佈局在 1220 px 視口上中斷會發生什麼？ 為什麼不針對 375 像素進行優化，這是當今較大手機的常見尺寸？

為每個場景創建一個畫板是不切實際的，尤其是在考慮所有斷點和視圖時——更不用說黑暗主題了。 為所有這些變量進行設計會使畫板的數量超出合理範圍。

模型也是一種資源浪費。 它們的構建非常耗時，並且在數字產品設計中變得不那麼突出。 Webflow 已經取消了模型，而是提倡響應式、交互式原型。 （不幸的是，Webflow 僅限於基於 Web 的解決方案並迎合簡單的網站）。 雖然一次性交付物在構思過程中可能有意義，但在解決方案階段它們是一種浪費。

將考慮所有系統狀態

所有數字產品的狀態都與它們在特定時刻所做的事情相對應——例如，在加載過程中停止或顯示錯誤消息。

必須考慮每種狀態，但當前的 UI 工具將這項任務留給了設計人員，迫使他們創建單個組件的多個變體。 開發工具 React 和 Vue.js 允許開發人員輕鬆調整組件的所有可能狀態。 設計工具必須效仿並鼓勵設計師——甚至是嘮叨他們——以確保所有組件狀態都是針對其設計的。

真實數據將取代佔位符內容

正如設計師為多種狀態創建組件一樣，他們也為各種各樣的數據進行設計。 UI 設計師需要能夠使用實際輸入（副本、圖像、日期、名稱、標題等）來測試他們的組件，這些輸入最終會填充到他們的設計中的組件中。 目前，設計師只能通過手動將數據複製粘貼到畫板上來模擬數據，這是一項極其繁瑣的任務。 有一些插件可以幫助自動化這個過程，但它們很麻煩。

要求開發人員評估組件如何處理數據也不是答案。 當組件開始測試時，重新設計它們太費時間了。 如果設計人員無法使用真實數據測試和迭代組件，他們如何知道卡片是否可以使用長標題或根本沒有標題？ 他們將如何發現字體不支持阿拉伯字符或網站不支持從右到左閱讀的語言？

邊緣案例測試將變得更容易

當 UI 工具最終滿足所有狀態並啟用真實數據測試時，設計師將能夠更好地預測邊緣情況。 創建組件後，設計人員將對它的各種狀態進行壓力測試，用不同的數據對其進行爆破，以查看它在不同場景中的表現。 這樣，UI 將成為設計人員的領域——讓開發人員能夠專注於修復 JavaScript 或測試 API 等任務。

開發者工具和第三方瀏覽器擴展的世界將打開

一旦我們的工作採用 HTML 和 CSS，整個擴展生態系統將在設計階段變得可用，例如用於性能、SEO 和可訪問性審計的不可或缺的 Lighthouse，或者模擬設備斷點和低網絡速度的各種瀏覽器開發工具。 瀏覽器工具集在創建和測試生產就緒 UI 方面比 Figma、Sketch 或 Adob​​e XD 中的任何插件更有價值。

設計師和開發人員將並行工作

我將產品開發的當前狀態比作廚房，一名廚師試圖通過指示另一名廚師做什麼來烹飪一道菜：它可能會起作用，但它需要更長的時間並且效率要低得多。 有些公司正在開發基於代碼的設計工具——Hadron、Modulz 和 Relate 的產品處於測試階段。 這些工具的廣泛採用將標誌著數字產品創造革命的開始。

這也將標誌著設計師與開發商關係的根本轉變。 隨著雙方並行工作，產品團隊的效率將成倍提高。 開發人員將可以自由地處理 UI 架構的複雜邏輯，而不是浪費時間解釋模型或被設計師要求他們將像素微調到完美而陷入困境。 隨著設計師成為成功的數字產品的共同構建者，他們對他們的團隊和公司將更有價值。