開發人員“擁有”代碼，那麼設計師不應該“擁有”體驗嗎？

我們都去過那裡。 您花了幾個月的時間收集業務需求，制定複雜的用戶旅程，製作精確的界面元素並在具有代表性的用戶樣本上進行測試，結果卻發現最終產品與所需體驗幾乎沒有相似之處。

儘管您認為組織還沒有準備好，但也許您應該更加有力並堅持採用敏捷方法？ 也許您應該在模式組合方面做得更好，確保開發人員使用您的模塊化代碼庫，而不是創建五種不同的輪播變體。 或者，也許您甚至應該每天都坐在開發團隊旁邊，確保您的設計真正實現。

關於 SmashingMag 的進一步閱讀：

• 為什麼你應該在設計過程中包括你的開發人員
• 團隊協作和縮小響應式設計中的效率差距
• 設計師和開發人員玩得很好
• 如何與開發者有效溝通

取而代之的是，您只剩下一堆混亂的 UI 元素，所有的微妙之處都被去掉了。 難道他們沒有看到你工作了好幾天才使過渡效果恰到好處，只是為了讓他們放入默認動畫庫中嗎？ 這個額外的結帳步驟到底是從哪裡來的。 我敢打賭，市場營銷是在最後一刻把它扔進去的。 你知道整合會很困難，需要做出妥協，但我們應該讓用戶在這裡生活更輕鬆，而不是技術團隊。

當然，網站採用這種方式有很多充分的理由。 具有不同技能水平的不同團隊在項目的不同部分工作，最後一分鐘的更改縮短了開發週期，以及一大堆技術挑戰。 不過，為什麼開發團隊不能來就他們的 UI 更改徵求您的意見？ 你不會弄亂他們的代碼，那麼他們為什麼要改變你的設計呢？ 尤其是當業務影響可能很大時！ 您只是在拐角處，如果他們剛剛提出要求，您會很樂意提供幫助。

雖然上面的故事可能是虛構的，但這是我從設計界的各個角落聽到的一種情緒，無論是內部還是代理方面。 一個精心製作的經驗被一個嚴厲的開發團隊毀了。

這段經歷讓我想起了幾年前在美國當地新聞頻道看到的一個新聞故事。 一個縣集市正在舉辦一場耐力比賽，最後一個把手放在皮卡車上的人獲得了獎品。 我經常認為設計就像一場“碰車”的大型遊戲，開發團隊總是在比賽結束時拿著鑰匙離開。 就像爭論中的最後一句話一樣，最終與該網站接觸的人擁有所有權力，可以決定它的工作方式或外觀。 特別是如果他們聲稱特定的目標體驗不是“技術上可行的”，這通常是“非常困難”、“我不介意那樣做”或“我認為有更好的方法”的簡寫所以我要拉開發卡”。

現在我知道我在這裡對開發人員不公平地苛刻，我不是故意的。 那裡有一些非常有才華的技術人員，他們真正關心可用性並希望為用戶做到最好。 然而，由於認為設計很容易，因此每個人都可以發表意見，而開發是困難的，並且只針對特別發起的人，因此人們常常感覺學科之間存在不對稱的尊重程度。 因此，雖然鼓勵（有時期望）設計師讓每個人都參與到設計過程中，但他們往往得不到同樣的奢侈。

老實說，我不怪他們。 畢竟，我知道足夠的開發是危險的，所以如果你想要我對數據庫結構和代碼性能的看法（除了我在很大程度上認為性能是一件好事），你就是個白痴。 再說一次，我確實知道足夠的知識來判斷開發人員何時在捏造東西，並且帶著他們認為不可能或需要幾個月才能實現的工作原型回到他們身邊總是很有趣 - 但我離題了。

問題是，我認為很多開發人員在設計方面都處於相同的位置——他們只是沒有意識到這一點。 因此，當他們根據幾年前在一次會議上聽到的內容對界面元素進行更改時，他們可能缺乏重要的上下文。 也許這是您已經測試過並打折的東西，因為它表現不佳。 也許您出於特定原因選擇了這個元素而不是另一個元素，比如可訪問性？ 或者，也許開發人員的意見是錯誤的，基於他們作為超級用戶而不是普通用戶體驗網絡的方式。

現在讓我們直接在這裡。 我並不是說開發人員不應該表現出對設計的興趣或對設計過程的投入。 我堅信跨職能配對，並認為一些最好的可用性解決方案來自技術團隊。 那裡也有很多才華橫溢的人，他們跨越多個學科。 然而，在某些時候，體驗需要被擁有，我認為它不應該被最後一個打開 HTML 文件並“觸碰卡車”的人擁有。

那麼，如果優秀的設計師尊重優秀的開發人員帶來的技能和經驗，那麼稍微平價又如何呢？ 如果設計師樂於讓開發人員“擁有代碼”，為什麼不表現出類似的尊重，讓設計師“擁有體驗”呢？

這樣做相當簡單。 如果您發現自己不確定為什麼以特定方式設計某些東西，並且認為可以做得更好，請不要一頭扎進並開始進行更改。 同樣，如果你遇到了技術障礙，並認為用不同的方式設計東西會讓你的生活更輕鬆，那就去和你的設計師談談。 他們可能對您建議的更改完全滿意，或者他們可能想離開並考慮解決同一問題的其他方法。

畢竟，合作是雙向的。 因此，如果您不希望設計人員在您的版本控製過程之外開始“優化”實時服務器上的代碼，請停止對他們的設計做同樣的事情。