「他們喜歡戴著鐐銬跳舞，而且是其他詩人的鐐銬?！?/p>

They love to dance in these fetters, and even when wearing the same fetters as another poet.

——布里斯·佩里（Bliss Perry)，美國文學評論家

聞一多最早在他的《詩的格律》一文中引用了佩里的這句話，想表達的是詩詞的格律對詩人的約束是有益的——「恐怕越有魄力的作家，越是要戴著鐐銬跳舞才跳得痛快，跳得好。只有不會跳舞的才怪腳鐐礙事，只有不會作詩的才會覺得格律是束縛?！?/p>

我覺得這句話不僅是說給詩人們聽的，也可以說給設計師們聽。連藝術創作者們都要受到格律、繪畫材料、風格的限制，更不用說為產品和用戶代言而生的設計師了。以前的產品可是沒有設計師的，只需要開發人員就可以做出 DOS、Windows、Linux 這樣的操作系統，以及初代的 OICQ 和 Foxmail 等軟件，直到他們意識到產品思維的重要性、用戶的重要性、界面美觀的重要性，才誕生了用戶體驗設計師這個職業，也就是后來的交互設計師和視覺設計師。

正因為設計師是用戶和產品開發之間的橋梁，所以設計師不僅應該有用戶思維，也需要有開發思維。因為如果不明白自家的產品究竟用的是什么技術，那設計出的產品很可能是天馬行空的。俗話說得好（by WingST），「比創意誰不會，能落地才算本事！」

一、理解限制，實現設計價值

「不要將系統的限制或條件視為局限性，把他們看成構建創意設計的根基?！?/p>

——Luke Miller，《用戶體驗方法論》

Miller 的這句話道出了設計和技術之間的關系，我深以為然。

1. 設計師最擅長的是構想

在沒有設計介入時，光是技術構成的產品易用性和易學性都是很差的，就像一個光禿禿的地表，確實很踏實，但毫無生氣，還容易迷路。這時設計師來了，說這不行啊，我可以給你做這樣那樣的優化，給出了一個完整的設計構想，確實很漂亮。這時地表上有了植被、建筑和大氣層，構成了一個新的產品，老板一拍桌子說，「看著不錯啊，我們開工吧！」

2. 尋找設計的支點

給出的設計構想是很漂亮，但是很多設計師到了實現的這步就傻眼了：剩下的交給開發啊，我切圖你實現不就好了，怎么這也不能做，那也實現不了？

很多時候其實并不能怪開發，不如一起來幫開發同學想想，你的設計究竟要怎么落地才能實現地更好？

• 比如你想快速掌握用戶的地理位置，你就應該知道手機上是有 GPS 模塊的，APP 有接口能夠快速獲取到用戶的手機定位信息，定位的經緯度可以換算成省市地區；
• 比如你想做一個可以根據用戶的手機傾斜角度改變形態的設計，你就應該知道手機上有一個叫陀螺儀的模塊，它具體是怎樣感知手機的傾斜角度的，又能傳回怎樣的參數來代表這些角度？它的精度如何，能夠很好地還原你的設計嗎？
• 比如你想實現一個很酷炫的動畫效果，你就應該知道 Android、iOS 這兩個系統上的動畫實現原理。如果你做的是 Web 或者是 PC 端的設計，那和移動端的動畫實現方式又不一樣，這些實現方式能還原你的動畫效果嗎？
• 比如你想做一個圖像智能識別的功能或者智能語音翻譯的功能，你就應該明白這種功能是哪些公司做得比較強，他們分別能實現的程度是怎樣的？你們的開發團隊有相應的技術儲備嗎？是否能直接找這些公司合作呢？

就算你做的不是什么創新的設計，但是要保證你做出的設計能夠很好地被開發還原出來，你也應該知道點九切圖法、Retina 屏幕的切圖比例、iOS 的基本控件庫、響應式設計的實現原理等等，明白這些，你的設計才算找到了和技術連接的支點。

3. 實現設計的價值

只有基于這些和技術連接的支點，你的設計構想才能真正落地，構成了一圈新的「大氣層」。由于技術基礎和開發周期的限制，你的設計通常沒辦法100%實現，但只要你的支點夠牢，你的設計構想就能夠最大程度地進行還原。

只有真正還原了的設計，才構成了設計的價值。

就像符合格律的詩歌才有韻味一樣，設計師也是戴著鐐銬跳舞的舞者，這些「技術鐐銬」不是羈絆你舞步的阻礙，相反的，正是因為戴著它們你還能跳得比別人好，你才變得與眾不同，你的設計才比別人的更有價值。

千萬不要讓你的設計變成了天馬行空的「大膽構想」，想得再好卻缺乏實現的可能，落地就會變成薄薄的一層爛泥，那些只是無價值的設計。

二、擁抱限制，尋找技術邊界

「盡可能地去了解你為之設計的系統的性能和限制。這有助于你提升繪制用戶理想流程圖和在設計中加入新特色和交互的能力?！?/p>

——Luke Miller，《用戶體驗方法論》

要理解開發思維，就要先解釋一下程序員常常掛在嘴邊的「算法」究竟是什么，只有理解了算法，才算真正理解了開發思維。

1. 算法的本質

算法（Algorithm）是指解題方案的準確而完整的描述，是一系列解決問題的清晰指令，算法代表著用系統的方法描述解決問題的策略機制。也就是說，能夠對一定規范的輸入，在有限時間內獲得所要求的輸出。

——百度百科

關鍵字：解題方案、輸入和輸出。

根據這三個關鍵字我們可以得出算法的數學方程式：

Y = U(X)

X 是輸入，Y 是輸出，U(X) 是基于參數 X 最終能得出 Y 的函數（解題方案），也就是算法。

舉個最簡單的算法，你按下了開關，電燈亮了。你按下開關的動作是輸入 X，電燈亮是輸出 Y，而從開關的結構到電線的排布、電源的引入，這一整套電路方案和開關的設計就是算法 U(X)，它解決了按下開關讓電燈亮的問題。

同樣的，你在微信上長按發送一段語音，這是輸入 X，朋友收到你發來的語音，這是輸出 Y，讓這段語音從你的微信到朋友的微信的解決方案，就是算法 U(X)。你還可以繼續想其他的例子，比如你在京東上下單，把貨物從電商平臺的倉庫轉移到你手里，這也是算法做到的。再比如你女朋友說她想要套房子，那你想盡辦法最終買來房子的過程，當然也是算法。

開發同學的偉大之處就在于，他們會很多厲害的算法，能把你的設計通過代碼還原成 APP、Web 網站以及各種形態的軟件產品，你的設計方案對于他們來說就是輸入，最終的產品就是輸出。

所以說，上面的這個方程式 Y=U(X)，其實就是算法的本質：你想要得到輸出 Y，那就給我輸入 X，我會找到一個算法 U(X) 幫你解決的。

2. 改變輸入方式

很多同學會抱怨開發同學水平不行，實現不了他們的設計，這種時候不妨想想，你給開發同學的是不是下面這種傳統的輸入方式：

你的設計構想是很完美很厲害，但是你給開發同學的不過是一張畫滿黑白線框和流程說明的交互稿，以及一張看起來華麗卻不會動的視覺稿，你覺得他們對你的這種輸入方式能理解多少？恐怕只有不到一半吧。剩下的那些，開發同學只好自由發揮了，不然東西做出來可是會有Bug 的。何況開發時間還那么少，老大們可不會找設計師催進度。

這下你明白了，在開發同學眼中，你給的輸入 X 就這些，我只能盡量用算法實現我想象中的輸出 Y 了，至于和你想的一不一樣我不知道，先做出來看看再說。

但現實是殘酷的，最終實現出來的往往是南轅北轍。

何不試著改變一下輸入方式？

還記得我在《交互設計師應具備的技能樹（4） ：交互設計師的視覺思維》文章里提到的電腦管家小火箭改版嗎？

我們為小火箭重新設計了一套新的發射動畫，相比原來的時間更短、加速感更強，火箭在上升過程中還會旋轉，確實很酷。這要靠交互稿和視覺稿當然都是說不清楚的，為此我們為它做了個高保真視頻 Demo：

開發同學：「嗯，看懂了，確實很快，但快到我都看不清啊，這要怎么做？」

我和視覺：「稍等，我們想想辦法?！?/p>

我們當然不會讓開發同學對著視頻一幀一幀研究，他們沒那個功夫，我們反其道行之。我們用 Visual Basic 語言寫了個程序 Demo，用一個很精簡的函數就實現了視頻 Demo 中的那種多段加速的動畫：

按我們老大的說法，把這套代碼直接丟給開發就行了，他們能看得懂的。

然而，對方長久的沉默讓我看出了他的心聲：「這什么鬼，懶得研究！」

所以我只好使出「終極大招」，我自學了 Visual Basic，自己看懂了函數，然后在紙上一番埋頭苦算，終于給出了一份詳盡的動畫「說明書」，

這份說明書包含什么內容呢？

• 整個小火箭的動畫，從點擊開始，小火箭每一步的動畫分解，細致到了每毫秒的動作；
• 在每毫秒的過程中，每個組件分別是怎么動作的，方向、速度如何，當然也包括了小火箭上升的幾段過程的分解；
• 小火箭旋轉需要播放一套序列幀動畫，開發能實現的最小顆粒度是10毫秒播放一幀，我就寫明白了每個時刻要從哪一幀播放到哪一幀。

寫完，我帶著這份說明書，搬一把椅子就坐在開發同學后面了。

「來來來，看這個，我們一點點改，保證完美還原，效果不好算我的?！?/p>

這樣一來，我們的設計支點就提高了，離我們的設計構想近了很多，最終實現的效果非常贊。

如果你想要做的是一個創新型的設計，那不妨換成這種「輸入方式」：用高保真原型（Demo）來一比一展示你要的設計效果，再通過動畫說明書來完整說明設計的每一個細節，確保傳達給開發同學的「輸入 X」足夠精準，這樣他才能夠通過算法來幫你實現足夠完美的「輸出 Y」。

細心的朋友可能發現了，我們在尋找最優「輸入方式」的過程中，其實也用了算法的思維（我們甚至連代碼都寫了），不斷改進自己給出的「輸入材料」，才有了最后的「動畫說明書」。

3. 模塊化設計

為什么每次我們都要這么麻煩地搞什么輸入、輸出和算法？為什么不能把已有的算法給固定下來呢？

當然可以，開發同學最喜歡的就是把算法給固定下來了，這就是「模塊化」。

熟悉 iOS 平臺的同學一定知道，蘋果公司會給每個版本的系統都提供「Design Template」（設計模板），其實這些就是開發同學在Xcode開發環境里可以用的「算法模塊」。如果你設計的時候用的是這些模塊，那他只要修改幾個參數就能直接復用了。

舉個例子，在 iOS 系統里有種從下往上彈的菜單叫做「Action Sheets」，蘋果的設計和開發人員考慮到了它的各種使用的情況，然后把它包裝成了一個「算法模塊」。

當你要使用的時候，可以只用1個「Action」，也可以用3個甚至更多的「Action」，你甚至還可以用到包含可以橫向滾動圖標的方案。這一切的修改，對于你來說只是在設計模板中復制粘貼和改幾個文字而已，對于開發同學來說也一樣，他也只要在蘋果給的控件庫里調出這個 ActionSheets 控件，然后改幾個參數就行。

這種極大簡化設計和開發流程的東西，就是算法模塊，主動制造這種模塊的過程，就叫做「模塊化設計」。

可能看這種控件還沒感覺，再來看看蘋果的官網吧。

這個 iPhone 的產品頁面你一定很熟悉了，它用的其實就是典型的模塊化設計，我們來找找看。

如上圖，其實它包含了頁面導航模塊、機型選擇模塊、頁面主副標題模塊、相關鏈接模塊和產品圖片模塊等，這些內容都是可以根據需要自由定制的，只要簡單做一個更換，就能馬上變成另一個頁面，如下圖。

是不是很省事？

不要小看模塊化設計，用它設計出一套好看的頁面之后再復用，對于設計來說就形成了設計規范，而對于開發同學來說，他能讓這些代碼變成可復用的算法模塊 U(X)，以后你可以隨意更換輸入 X，他都能用這個模塊給你快速地生成你想要的輸出 Y。

因此，時刻心中都有模塊意識的交互設計師，他會在合理設計頁面功能的情況下，盡可能地復用設計，和視覺設計師一起把它們固化成模塊，就像在生產樂高積木一樣。這樣一來，只要完成了主要頁面和主風格的設計，剩下再多的頁面也不過是一種理性地拼裝和因地制宜地修改而已。

現在你是否明白了為什么開發們那么喜歡上 GitHub 這類開源網站？就像我們上 Dribbble 和 Behance 尋找設計靈感一樣，他們也是在學習別人的算法模塊。

相關閱讀

交互設計師應具備的技能樹（1）：產品思維

交互設計師應具備的技能樹（2）：設計師的用戶思維

交互設計師應具備的技能樹（3）：設計師的邏輯思維

交互設計師應具備的技能樹（4） ：交互設計師的視覺思維

作者：WingST，騰訊高級交互設計師，微信公眾號“落羽敬齋（ID：wingstudy）”

本文由 @WingST 授權發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議