今天我們談到了那些年來設計師的“微小變化”，以及上下游協作（設計師，產品經理，開發，運營和維護等）之間的微妙關系。

所謂的“小變化”通常出現在設計師或產品經理的口中，其描述如下：

僅更改文本顏色;僅更改圖標;只是一些微小的變化;非常簡單?

但是對于程序員來說，它通常會有不同的味道：

還需要在這里改變？想在這里經營嗎？這個布局完全改變了！人與人之間的信任在哪里？

那么，人與人之間的信任究竟是如此無動于衷呢？還穿什么安全褲！

首先，來自這里的產品人員，如果你一開始不信任開發人員，你總是想把事情簡單，或者把時間和插入要求，那么開發人員也會有相應的不信任：無論如何，你打算插入你需要什么來估計時間？

從設計師的角度來看，設計師的思維往往更自由自由，同樣的設計稿，在設計師的眼中是一對畫布讓我揮灑。

當然，網頁設計師仍然熟悉基本的頁面布局實現，但程序員眼中的結構和邏輯仍然是兩個世界。

因此，設計師常常覺得我的結構不動，只是在這里添加一個小東西，或者每個元素都調整到某種位置顏色，因為它符合當前的設計風格。結果是程序員的悲劇：這相當于重做！

在完美的開發過程中，上游和下游的方向非常強大。

產品和交互可以探索（bi）來確定（bi）來確定解決方案，與設計師的交互，沒有太大的發展空間。

設計師的設計草案，到前端開發，除了一些特效和實現細節外，基本上就是這么做的。如果前端開發區分重構和JS，那么JS只能繼續使用重構結構進行開發。

前端和后臺之間的關系實際上不是上游和下游。應該說是平行的。即使在大多數情況下，前端也應遵循背景規則。

在此過程的后端，測試學生必須參與產品文檔，設計測試用例的整個過程。從產品邏輯，設計恢復，兼容性問題，接口自動化測試，安全問題，性能問題等方面考慮。

更不用說還有運營商遵循時序變化，優化數據庫等等。

可以想象，上游的一些看似微小的變化將對下游人員造成蝴蝶效應。

因此，除了“理解萬歲”之外我們稱之為口號，實際上，上游角色應該更加了解下游工作，以便更好地推進。

例如，產品操作的學生可以更多地了解交互，為什么它如此執著，為什么這個彈出窗口不能如此轟擊？

互動學生可以看到我的互動形式是否過于嚴格的設計，是否可以有更好的演示形式？

設計師更多地考慮這種變化對頁面結構的影響程度。設計如何成為一個頁面？

前端同學想一想，我可以使用模板JS /后臺嗎？我是否有能力考慮各種狀態和各種擴展的變化？

后臺學生更多地考慮我的界面真的很容易使用？有沒有可以省略的參數？有沒有不應該暴露的信息？界面太臃腫了嗎？該領域的意義是不清楚或不一致？

測試同學考慮一下，我怎么能這么難？

操作和維護同學多考慮一下，我還沒談過，你玩得開心嗎？

嘿，古人云，我住在長江，王住長江，長江是水，懂萬歲。