国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

在數(shù)字產品設計與開發(fā)領域，開發(fā)與設計之間的不匹配問題一直是行業(yè)內的痛點。設計師使用自由度極高的畫布工具進行創(chuàng)作，而開發(fā)人員則需要在規(guī)則嚴格的開發(fā)環(huán)境中實現(xiàn)這些設計。這種差異不僅導致了交接過程中的摩擦和錯誤，還浪費了大量時間和精力。本文將深入探討開發(fā)與設計不匹配的根本原因，并分析現(xiàn)有的解決方案及其局限性。同時，作者將分享對未來設計工具的展望，探討如何通過工具的改進來更好地支持協(xié)作，提升設計與開發(fā)的效率和質量。

用戶界面設計師使用沒有約束的畫布工具，設計那些基于規(guī)則的交互系統(tǒng)，然而，期望開發(fā)人員在研發(fā)環(huán)節(jié)中完善所有內容。這往往導致設計師和開發(fā)人員之間產生隔閡。

數(shù)字產品設計和開發(fā)領域一直存在 2 個問題。第 1 個問題還比較顯而易見，因此，不出意外，受到了大量的關注，并且，也衍生出很多還算合理的階段性解決方案。然而，第 2 個問題就顯得更為深層、微妙，因此，也更容易被忽視。

我們先從第 1 個問題說起：交接問題

實際上，交接過程之所以是一個主要問題，有好幾個原因：

在交接過程中的摩擦以及可能會出現(xiàn)的錯誤。這一點導致實際編碼的產品與設計師在設計工具中所表達的意圖產生偏差。唯一重要的是真實用戶對實際產品的體驗。如果在最終的產品中無法將設計完美呈現(xiàn)，那么，這將會使整個過程變得低效且令人沮喪。

交接過程浪費了設計師和開發(fā)人員大量的時間。為了正確構建界面，編碼和解碼所有相關信息，這需要耗費大量的精力。設計師必須通過規(guī)格說明、示例、注釋和文檔過度溝通（這些看似必要，但確實很冗余），同時，開發(fā)人員則必須以一種偏執(zhí)的、近乎偵探級別的警覺來查看設計文檔，有時候，甚至還需要瞇起眼睛，以免遺漏任何一個設計細節(jié)。

將設計文檔交給開發(fā)人員從頭開始構建，會創(chuàng)造一個萎縮的產物。一旦代碼上線，它就會與設計文件產生偏差，從而引發(fā)一場永無止境的對齊競賽，以確保設計文件與“現(xiàn)實”保持一致。這種對齊過程不可避免會被打破，不信任就此產生。開發(fā)人員看到舊版本的設計文檔的時候，下意識就會認為忽略這些似乎與“現(xiàn)實”脫節(jié)的部分是理所當然的。結果，設計師變得高度警惕，不斷尋找設計與“現(xiàn)實”之間不一致的地方。當開發(fā)人員選定某個組件庫作為基礎的時候，雖然加速了研發(fā)的效率，與此同時，與設計文檔不一致的情況也就會經常發(fā)生。

交接設計迫使設計師在他們通常不太喜歡或不太重視的事情上浪費他們的時間。詳細說明并記錄文本字段，明確標注在產品中應該如何呈現(xiàn)的所有方式，這些事情往往讓設計師覺得很細碎、很繁瑣。尤其，當他們知道這事項并非是實際要構建的產品，而僅僅是一個一次性的產物。同樣，這也迫使前端開發(fā)人員專注于那些沒什么樂趣或意義的任務。在代碼中重現(xiàn)已設計好的界面，通常還要追著設計師確認當窗口變大或變小時各項內容元素應如何重新排版，這些事同樣對他們而言毫無樂趣。

由于交接過程所產生的問題基本都是比較顯而易見的，同時，產品設計和研發(fā)人員都希望能夠解決這些問題，無論在過去還是現(xiàn)在，這一呼聲都是很高的。

于是，市面上逐漸構建出 2 種不同方向的解決路徑：

其中 1 條路徑：是針對最流行的畫布式設計工具開發(fā)輔助應用程序。起初出現(xiàn)一些以視檢為核心功能的工具（例如： Avocode、Zeplin、Simpli 和 Abstract、藍湖、摹客）。隨后，主流的設計工具開始陸續(xù)增加了視檢功能（例如 Figma、Sketch、XD 和 InVision 中的開發(fā)模式）。之后，也出現(xiàn)了專門的工具，主要是以文檔編寫（例如： Zeroheight 和 InVision 的 DSM ）。在 Sketch 和 Figma 的上線插件市場后，也涌現(xiàn)出了很多對應的插件（例如： Anima、Locofy 以及其他“Figma 轉 HTML”插件工具）。

另 1 條路徑在本質上則截然不同。它試圖通過打造新一代的設計工具來實現(xiàn)徹底消除交接過程，這些工具主張能夠自行“端到端交付”，幾乎不需要或完全不需要開發(fā)人員的協(xié)助。如今，最突出的代表工具當屬 Webflow 和 Framer，然而，在市面上，此類工具種類很多，我們可以追溯到 25 年前的 Dreamweaver 。

然而，這些無代碼/低代碼工具存在 1 個巨大的問題，過去如此，現(xiàn)在依然如此，它們所構建的方式不僅消除了開發(fā)與設計師之間的交接過程，還消除了對開發(fā)人員本身的需求（簡而言之，就是不要開發(fā)人員了）。但是，這就自然會導致這些工具所能讓設計師端到端構建的產品的復雜性設置了限制（上限相當?shù)停瑥碗s的產品根本搞不定）。眾所周知，商業(yè)上取得成功的更多集中在網站構建工具和平臺，然而，原生 iOS/Android 或 Web 應用構建工具則始終無法突破（目前我只知道 Play for iOS 和 Draftbit）。我個人認為，主要原因在于應用程序的復雜邏輯超出了無代碼工具所能提供的交付能力。在過去的幾年里，一些垂直類工具，例如 Framer、Webflow、Builder.io 開始通過構建新的“橋梁”，通過使用插件，從 Figma 等畫布工具導入設計資產。

因此，解決交接問題的路徑上在其核心處還存在一個權衡：

要么，擁有一個通用的畫布工具，能允許設計師們設計出世界上最復雜的應用程序，但是，設計交付只是一個半成品，還需要交接開發(fā)；要么，擁有一個專屬的構建工具，能讓設計師能夠自行設計和開發(fā)，但是，設計師想要創(chuàng)建的復雜程度較高的產品就會受到限制。

據我所知，市面上只有 2 款設計/開發(fā)工具成功采用了不同的、統(tǒng)一策略。

Flash（由 Macromedia 開發(fā)，后被 Adobe 接手，最終被史蒂夫·喬布斯終結）

Visual Studio 的 Blend 工具，使用微軟的 XAML 和 WPF 平臺。

Flash 擁有 ActionScript，允許同一個對象既可以由設計師自由設計，同時開發(fā)者也可以使用 ActionScript 命令對其進行邏輯操作。這種設置讓所有相關專業(yè)人士都能發(fā)揮所長。設計師專注于重要的體驗和視覺的重要元素。也就是說，設計師不需要向開發(fā)人員交接任何內容，因為開發(fā)人員可以直接針對設計師創(chuàng)建的現(xiàn)有資產進行開發(fā)。沒有一次性的中間產物，沒有交接過程，也沒有復雜度的限制。雖然 Flash 并不會輔助編寫代碼，但是，它允許開發(fā)者在設計師的舒適區(qū)就能開始接手工作。

Visual Studio 的 Blend 工具也是類似的故事，但使用的文件、結構和邏輯有所不相同。它是一個雙環(huán)境設置。設計師可以進行設計，而 Visual Studio 開發(fā)人員可以針對完全相同的資產進行開發(fā)。同樣，沒有交接過程，沒有一次性的中間產物，也沒有復雜度限制。

眾所周知，F(xiàn)lash 的消亡是因為與其安全性和性能上與 iPhone 不兼容。Blend 和 Visual Studio 現(xiàn)在也已經淪為小眾且不流行的工具。在過去 7 年的工具使用情況調查中，我從未見過有人提及它們。與此同時，F(xiàn)igma 幾乎占據了整個產品設計市場份額。

?? 設計師們，我們正面臨一個關于“Figma主義”的陷阱

這不得不讓我們得出一個結論：即使是采用最佳方法的工具，也不能免于因各種其他原因而失敗。商業(yè)確實是一場變幻莫測的游戲。

現(xiàn)在，正如我在一開始所說，產品設計和開發(fā)領域一直存在 2 個問題。接下來，我們一起探討一下那個更隱蔽但更為重要的難題。

第 2 個問題：局限問題

簡單的基于畫布的工具對設計師隱藏了廣泛的設計屬性。

當前設計工具存在的問題影響深遠，但這并非刻意為之。這其實是一種權衡的結果，設計師們過去只看到了“自由創(chuàng)作”這一優(yōu)點，而忽視了其帶來的局限性。設計師們普遍熱愛創(chuàng)作自由，我也不例外。

重要的是，作為一名設計師，我們有必要了解我們是如何發(fā)展到今天這種在行業(yè)中已變得如此普遍的使用畫布工具的現(xiàn)狀。

我們從一張實體頁面開始。平面設計師將紙張、墨水和顏色完美的調配。頁面是靜態(tài)的、具體的、清晰的。隨后，圖形處理軟件出現(xiàn)了，幫助加快了設計速度，Photoshop、Freehand、CorelDraw、Illustrator（以及后來的更多軟件）。所有的軟件都幫助我們設計印刷品和大多靜態(tài)的網頁資產。之后，發(fā)生了一件重要的事情。電腦屏幕尺寸開始多樣化?；ヂ?lián)網和原生應用不得不適應這一變化。它們引入了響應式單位和規(guī)則。在 iPhone 和平板電腦發(fā)布之后，這一切變得更加復雜。但設計師，尤其平面設計師和早期的交互設計師們，卻已經習慣了頁面概念。自然而然，那些已盈利為生的設計工具繼續(xù)為設計師們提供這種設計方式和體驗。直接操作的便捷性（最初是用鼠標和鍵盤，后來是用手指手勢和觸控筆）讓設計師們感到無比舒適，以至于他們不愿為了其他好處而放棄這種設計方式。但是，這也導致了一種不匹配，工具鼓勵設計師擁有自由，而現(xiàn)在的需求卻是響應式、系統(tǒng)化、智能化、參數(shù)化的設計規(guī)則，提供給開發(fā)人員來實現(xiàn)。

而這就是產生巨大分歧的地方，因為：

設計工具面臨一個兩難選擇：要么提供完全的創(chuàng)作自由度，要么提供系統(tǒng)化的規(guī)則和約束。這兩種特性很難在同一個工具中完美共存。

想一下“引力”的基本概念：在 Figma 推出自動布局（auto-layout）功能之前，所有主流的畫布工具相比之下都提供了極大的自由度，這意味著無論是向上還是向下都沒有“引力效應”。這與網頁端以及原生的 iOS 和 Android 環(huán)境截然不同。

在傳統(tǒng)設計工具中，所有元素默認是完全自由放置的，它們只是按層級堆疊，互不影響。元素之間沒有推擠關系，也沒有互動。內邊距和外邊距這些概念形同虛設。添加更多文字時，容器大小也不會自動調整。由于沒有類似瀏覽器窗口的概念，所以無法使用相對于窗口的尺寸計算；甚至百分比尺寸也幾乎不會被使用。因此，幾乎所有元素都是獨立存在的，沒有相對關系。

隨著時間推移，更適合 UI 設計的工具逐漸出現(xiàn)。Sketch 開創(chuàng)了先河，為后來的 XD 和 Figma 鋪平了道路。Sketch 引入了組件系統(tǒng)、樣式覆蓋機制、將設計框架對應到網頁 div 的概念映射，以及更多可調整參數(shù)的視覺屬性（比如 Figma 中的顏色系統(tǒng)、文字排版、視覺效果和布局網格）。這些創(chuàng)新為設計領域帶來了一股新的風暴，但同時也隨著工具的發(fā)展帶來了新的挑戰(zhàn)。

具有技術思維的設計師們開始感到壓力，紛紛自學編程。這讓他們獲得了巨大優(yōu)勢，因為通過編程實踐，他們對UI實際開發(fā)的理解不再停留在表面。設計行業(yè)迫切需要更強大的工具，因此主流設計軟件（Sketch、Figma和XD）都引入了“自動布局”功能，這實際上是網頁開發(fā)中 Flexbox 布局的簡化友好版本。這種變化就像在一個完全自由的設計畫布中，創(chuàng)建了特殊的區(qū)域，在這些區(qū)域內元素會像網頁 DOM 那樣相互影響和排列，而這個特殊區(qū)域又被包含在更大的自由畫布環(huán)境中。

這是革命性的。設計師們開始理解內容會如何影響其所在容器的大小。頁面元素重新排列的方式變得更加合理，內邊距這個概念終于有了實際作用。

有經驗的設計師開始幾乎完全依賴自動布局來創(chuàng)建他們的用戶界面。

請花點時間思考這個現(xiàn)象的意義…

在沒有元素間相互影響的設計工具環(huán)境中，我們卻要創(chuàng)建大量使用自動布局的區(qū)域，讓元素能夠相互影響！如果設計工具的默認狀態(tài)就像代碼環(huán)境那樣，元素天生就能相互影響，默認就支持自動布局，不是會更簡單嗎？實際上，網頁開發(fā)、iOS 和 Android 開發(fā)環(huán)境本來就是這樣工作的。

回顧過去十年的設計工具發(fā)展歷程，我們可以看到一個明顯的趨勢：工具正在幫助設計師建立更系統(tǒng)化、更靈活的設計規(guī)則。

但是…

我們還未迎來最關鍵的變革。

對于 UI 設計（組件和頁面構建），產品設計師不得不放棄傳統(tǒng)的自由畫布方式。

我認為，設計和構建數(shù)字產品必須與開發(fā)平臺的實際約束保持一致。作為設計師，我需要能夠像開發(fā)者一樣使用彈性布局、網格系統(tǒng)、內外邊距、百分比尺寸、窗口單位等全套工具。我需要能輕松調整窗口大小，并實時查看所有元素如何響應變化。組件應該區(qū)分“狀態(tài)”和“屬性”這兩個不同概念。組件變體應該基于規(guī)則自動生成，而不是手動創(chuàng)建每一個變體。我們應該用設計令牌系統(tǒng)代替簡單的樣式，建立多層次、可復用的設計參數(shù)（如排版系統(tǒng)）。

設計工具的默認設置應該引導我們做出更好的決策，而非僅僅更美觀或更簡單的決策。它應該防止我們輕易創(chuàng)建出表面看似整潔但實際混亂、不一致且難以維護的系統(tǒng)。在《網絡的紋理》中描述了數(shù)字界面設計的本質挑戰(zhàn)：

“一個沒有明確邊界的界面，由許多小的、獨立的、可變化的元素組成。這些元素來自不同角度，共同構建成一個可理解的整體，呈現(xiàn)出特定時刻的狀態(tài)。”

數(shù)字產品設計有其獨特的特性和挑戰(zhàn)。我們需要的設計工具應該直面這些復雜性，而不是簡化或隱藏它們。作為設計師，我們需要成長和進步，因為高質量的工作流程、良好的設計師和開發(fā)者關系、優(yōu)質的產品以及用戶滿意度都值得我們投入更多努力。

未來的設計工具必須真正支持協(xié)作，而不僅僅是設計交付。大多數(shù)復雜產品的開發(fā)是離不開開發(fā)人員的參與。盡管 AI 工具和無代碼平臺看起來很有前景，但它們無法完全替代專業(yè)開發(fā)團隊在復雜產品開發(fā)中的作用。

我相信設計工具領域的變革即將到來。我和朋友們正在開發(fā)一款名為Jux的工具，它體現(xiàn)了這些新理念。雖然目前還處于早期階段，還有很長的路要走，但我們相信這將是一次真正的革新。