中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導讀：產品設計的穿透力怎么表現？穿透意味著打破界限，從表面到內核，從表象到本質。需要把一個點打穿打透，需要的不僅僅是一個烏托邦的幻象，更多需要深入到 real world 當中，感知更多的限制、連接。本文以智能柵格工具的設計開發為例，來看看怎么表達設計的穿透力。

今天想和大家分享一下智能柵格工具的整個設計開發的過程，并從中感受到設計的「穿透力」。

什么是穿透力？穿透意味著打破界限，從表面到內核，從表象到本質。需要把一個點打穿打透，需要的不僅僅是一個烏托邦的幻象，更多需要深入到 real world 當中，感知更多的限制、連接。

一、初版方案與實現思路

經過初步討論后的第一版設計基本可以作為 demo 開發，但是存在一個不明確的地方就是居中按鈕。

這個方案的設計完全借鑒了 Sketch 的布局界面，但是 sketch 的這個居中按鈕其實挺令人匪夷所思的，往往不知如何使用。

經過一番討論后，我們一致認為這個按鈕應該放在柵格總寬邊上，表示需要對柵格進行調整。同時為了便于預覽，最好給柵格預覽區加上相應的寬度值，大致如下：

以上是我們作為設計師的視角，經過兩輪討論，得出來的設計結果。到這一步，我們都可以認為這個版本算是一個合格的柵格工具。

然后我作為工具的實現方，我準備先大致明確開發順序。在這個窗口的實現上從易到難，應該為：靜態柵格實現->柵格響應實現。

所以我決定開發順序是這樣：

靜態柵格預覽渲染 -> 柵格參數面板 -> 柵格動態響應 -> 生成柵格 。

二、靜態柵格：柵格生成公式解析

繪制靜態柵格包含兩部分工作，第一部分是左右布局的柵格，第二部分是居中布局的柵格。

我的思路是先確定一下左右布局和居中布局的計算公式，然后在實現的時候就可以有清晰的實現手段了。

在紙上一通演算，我突然發現左右布局和居中布局的計算公式其實是不一樣的：

左右布局： 畫板寬度 A = 左側偏移寬度L + 兩側間距M 2 + 柵格總寬G居中布局： 畫板寬度 A = 兩側間距M 2 + 柵格總寬G

乍一看似乎兩者沒什么區別呀？不就是左側偏移距離L 在居中布局的時候變為 0 了嗎？為啥不統一成一個呢？

從公式里去看，背后的原因是這樣：

針對左右布局的柵格，我們需要去調整A、L、M、G 四個值，然后調整一個改變其他值；

而在居中模式下，我們只需要去調整 A、M 和 G 三個值（因為 L 變成了 0 ）。所以由于公式上少了一個 L，所以我們不必要也不應該在居中模式下，讓 L 這個參數出現。

或許從程序員視角來說，統一成一個更加便于開發。但是從設計師的角度來看，這其實對設計的帶來了新的啟示：

我們不應該用一個居中按鈕去實現柵格居中的效果，而應該采用不同的模式區分不同的布局類型。

所以在實現這個參數面板的時候，我們選擇了使用選擇器的方式呈現不同的布局模式，同時在居中布局下去掉了【側邊欄寬】這個參數。

到這個時候，我們再去對比 Sketch 的柵格布局面板，已經能夠感知到明顯不同了。而這一步，只是由于深入了一下布局柵格的計算規則帶來的。

這是第一層，設計穿透了柵格布局計算公式。

三、智能柵格：動態響應規則設計

當初步完成上述的柵格顯示，下一步就是要允許用戶自定義柵格參數。這就立即帶來了一個問題：修改柵格公式中的某個參數，其余參數應該如何相應？

事實上，在上一部分講到的柵格計算公式只是一個簡化版本。因為我們沒有展開柵格寬度的計算公式。完整的計算公式應該是這樣（以左右布局為例）：

畫板寬度 A = 左側偏移寬度L + 兩側間距M 2 + 柵格列數L 柵格寬度W + （柵格列數L – 1）* 柵格槽寬T

如果照著這個公式去思考，我想是個人頭都要大了，一個參數變化，需要考慮其他 5 個參數的相應。其實我在第一步分析公式的時候，就是這么列的，結果就是很難往下推進開發，公式太過復雜，不知道如何算。

所以我又回過頭來思考了下柵格修改的場景，發現修改畫板、偏移寬度等總寬值時，用戶對柵格內部的狀態不會太關注。所以針對總寬的參數，我們就應該使用這樣兩個公式：

左右布局： 畫板寬度 A = 左側偏移寬度L + 兩側間距M 2 + 柵格總寬G居中布局： 畫板寬度 A = 兩側間距M 2 + 柵格總寬G

再結合柵格修改時設計師的設計意圖判斷，我從中總結了 7 條規則：

在左右邊距模式下：

• 修改畫板寬度 A 時，往往希望柵格總寬 G 變化，即 A?? ~ G??；
• 修改左側偏移寬度 L 時,往往希望柵格總寬 G 變化，即 L?? ~ G??；
• …. (更多的就不列了)

到這一步，我只是理清楚了總寬類參數響應規則，但是還沒有對柵格內部的參數進行分析。接下來就需要對柵格總寬的計算公式進行下鉆分析。

柵格總寬 G = 柵格列數L 柵格寬度W + （柵格列數L – 1） 柵格槽寬T

按照同樣的思路，我得出了4條規則：

• 修改柵格總寬 G 時，往往希望柵格寬度 W 變化，即 G?? ~ W??；
• 修改柵格列數 L 時，往往希望柵格寬度 W 變化，即 L?? ~ W??；
• 修改柵格槽寬 T 時，往往希望柵格寬度 W 變化，即 T?? ~ W??；
• 設計師幾乎不會去主動修改柵格寬度；

當總結完以上11 條規則時，在設計端上我有兩個新的認知：

1. 修改布局和修改柵格應該分兩個部分分別呈現；
2. 不必給出修改柵格寬度W的配置項。

所以在設計端最后的配置參數呈現如下（基本驗證了第二版設計方案的正確性）

而將上述這 11 條規則結合起來，并通過代碼實現后，柵格就具有了智能動態響應的效果。由于這11條規則直接來源于設計師的認知經驗，可以基本保證用戶的使用體驗如絲般順滑，仿佛背后不存在設計一樣。

這是第二層，設計穿透了柵格變更的響應規則。

一個小插曲：在最初的時候（大約是Microwave 0.3.1），我走進了一個誤區，在柵格總寬變化時，讓柵格寬度和柵格槽寬等比縮放。結果帶來的問題就是：每次修改完柵格總寬后，都需要人為手動地重新修改一遍柵格槽寬。由于我對響應規則判斷出錯，導致使用體驗存在不必要的冗余操作，這就是一個規則考慮不周的典型反例。

四、柵格生成：簡潔與易用的妥協與平衡

利用 Sketch 的JS API，我很快就實現了柵格的創建。如下左圖所示，是不是看上去非常簡潔？但是你有沒有看出其中的問題？

問題就是：這些智能柵格其實是由一堆圖層組成的。而在 Sketch 中，大家也知道，一旦成組之后，這些柵格圖層就失去了非常重要的能力：吸附。一旦沒了吸附，這個柵格工具就失去了大部分的意義。如果需要吸附，那么必須將這個組打散，這就會導致畫板中平白無故會多出 20+的柵格圖層。

這個時候，你覺得應該怎么做？是為了簡潔，忍痛割掉柵格吸附的能力？還是為了吸附的能力犧牲圖層上的簡潔？

綜合考量，我給本來很簡潔的面板多加了一個【吸附模式】切換器，打開這個模式后，不會對柵格圖層進行編組，從而保持原有的吸附能力。通過這樣曲折的方式了解決 Sketch 的這個問題。（這里又要罵一句辣雞的 Sketch 了）

這是第三層，設計穿透了 Sketch 的能力，繞過了已有的限制。

PS：在后來的迭代過程中，我發現了更上游的解決方案，所以后來又把這個模式取消了。

五、智能適配：柵格基礎能力的升華

其實在完成上述那些功能之后，我自己感覺這個柵格工具已經接近“擊穿”的狀態，似乎沒有更多更大快的地方可以優化了。但是，我仍然感覺到這個智能柵格工具并沒有那么“智能”，仿佛圍繞了這個“智能”做了很多很多的工作，但是就是還有一層紙擋在那邊，沒有捅破。

于是我與幾位同學進行溝通，其中一位同學的一句話間把這層紙捅破了：“要是這個柵格能夠幫我自動去匹配上柵格就好了。”我突然想到前端工程中很重要的一個能力是 lint，即校驗與自動修復代碼中的空格、標點等錯誤。

瞬間我的心中豁然開朗。柵格是什么？是布局的規范，同樣應該也是校驗與修復工具。一個合格的柵格工具，除了前面基礎的柵格生成、修改、校驗（相當于 Sketch 的吸附），也應該提供自動修復的能力。于是我連夜把這個功能實現了出來。

這個能力的實現并不復雜，甚至非常簡單（用了不到 30 分鐘），但是對于整個柵格工具卻是升華般的存在。

這是最后一層，設計穿透了平臺的能力枷鎖，帶來了工具質的飛躍。

在小組周會上演示這個功能時，大家都不約而同地鼓起掌來，足以證明這個能力有多被認可。

六、一點總結和感想

1. 設計的穿透力

越接近底層，需要掌握和了解的東西也越多，但另一方面，也帶來了足夠大的優化空間。如何全面分析和所有相關的限制條件，在這些限制條件下找出設計上的最優解法，我認為這就是設計的穿透力。

2. 工具與思維限制

工具不會限制人們的思考，但會潛移默化的影響人們思考的模式。 —— 前電腦時代的建筑圖紙是什么樣的？是怎么畫成的？

曾經在知乎看到過上面這一句話，現在再復盤這個工具的設計開發過程中，我對這句話又有了更深入的體會。

因為 Sketch 只有吸附功能，所以在設計和開發的時候，我就完全被 Sketch 已有的能力牽著鼻子走，為了「吸附」功能，繞彎路實現了吸附模式，而沒有去往上一層去思考出「適配」的能力。

事實上，在前端工程中，早已有 ESLint、Prettier 等自動約束和修正的工具。但是在設計側似乎一切都在刀耕火種時代，工具鏈的貧瘠導致無法孕育出工程化的思想。

這種時候，打破思想限制的最有效的方式，就是多獲得不同領域的信息輸入。很有可能當前領域的問題，在其他領域已經有成熟的解決方案了。所以我也愈發感覺到交流的必要性。

3. 設計工程化

所謂設計工程化需要的是類似前端工程中一樣的 lint 工具，能夠對大到顏色、字體、字號，小到圖層命名進行相應的約束與自動修復。

同時，工程化這個概念，也不應該靠大家喊出來、逼出來的。而是順應時代的發展，自然而然的事情。TechUI 周會結束的時候，有人跟我說，“我之前覺得柵格沒有什么用，但是你這個東西一出來，就立馬覺得柵格好有用?！蔽蚁脒@就是所謂的自然發生吧。

4. 我們需要哪種布局

我們需要的真的是自由畫布嗎？至少從柵格這個工具來說，完全的自由反而是降低效率。如果能夠給出一定的限制，反而會使得我們的設計效率提升。因為我們不必要關心三等分的組件，每一等分的具體值是多少，我們只需要關系是正確的三分了即可。所以限制不一定降低效率，有目的的限制反而能夠提升效率。

作者：空谷，螞蟻集團設計師

本文由 @Ant Design 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議