「他們喜歡戴著鐐銬跳舞， 而且是其他詩人的鐐銬。 」
They love to dance in these fetters, and even when wearing the same fetters as another poet.
——布裡斯·佩里（Bliss Perry)， 美國文學評論家
聞一多最早在他的《詩的格律》一文中引用了佩里的這句話， 想表達的是詩詞的格律對詩人的約束是有益的——「恐怕越有魄力的作家， 越是要戴著鐐銬跳舞才跳得痛快， 跳得好。 只有不會跳舞的才怪腳鐐礙事， 只有不會作詩的才會覺得格律是束縛。 」
我覺得這句話不僅是說給詩人們聽的， 也可以說給設計師們聽。 連藝術創作者們都要受到格律、繪畫材料、風格的限制， 更不用說為產品和使用者代言而生的設計師了。 以前的產品可是沒有設計師的，
正因為設計師是使用者和產品開發之間的橋樑， 所以設計師不僅應該有使用者思維， 也需要有開發思維。 因為如果不明白自家的產品究竟用的是什麼技術， 那設計出的產品很可能是天馬行空的。 俗話說得好（by WingST）， 「比創意誰不會， 能落地才算本事！」
「不要將系統的限制或條件視為局限性， 把他們看成構建創意設計的根基。 」
——Luke Miller， 《用戶體驗方法論》
Miller 的這句話道出了設計和技術之間的關係， 我深以為然。
1. 設計師最擅長的是構想
在沒有設計介入時， 光是技術構成的產品易用性和易學性都是很差的， 就像一個光禿禿的地表， 確實很踏實， 但毫無生氣， 還容易迷路。 這時設計師來了， 說這不行啊， 我可以給你做這樣那樣的優化， 給出了一個完整的設計構想， 確實很漂亮。 這時地表上有了植被、建築和大氣層， 構成了一個新的產品， 老闆一拍桌子說， 「看著不錯啊， 我們開工吧！」
2. 尋找設計的支點
給出的設計構想是很漂亮， 但是很多設計師到了實現的這步就傻眼了：剩下的交給開發啊， 我切圖你實現不就好了， 怎麼這也不能做， 那也實現不了？
很多時候其實並不能怪開發， 不如一起來幫開發同學想想， 你的設計究竟要怎麼落地才能實現地更好？
比如你想快速掌握用戶的地理位置， 你就應該知道手機上是有 GPS 模組的，
比如你想做一個可以根據使用者的手機傾斜角度改變形態的設計， 你就應該知道手機上有一個叫陀螺儀的模組， 它具體是怎樣感知手機的傾斜角度的， 又能傳回怎樣的參數來代表這些角度？它的精度如何， 能夠很好地還原你的設計嗎？
比如你想實現一個很酷炫的動畫效果， 你就應該知道 Android、iOS 這兩個系統上的動畫實現原理。 如果你做的是 Web 或者是 PC 端的設計， 那和移動端的動畫實現方式又不一樣， 這些實現方式能還原你的動畫效果嗎？
比如你想做一個圖像智慧識別的功能或者智慧語音翻譯的功能， 你就應該明白這種功能是哪些公司做得比較強， 他們分別能實現的程度是怎樣的？你們的開發團隊有相應的技術儲備嗎？是否能直接找這些公司合作呢？
就算你做的不是什麼創新的設計，但是要保證你做出的設計能夠很好地被開發還原出來，你也應該知道點九切圖法、Retina 螢幕的切圖比例、iOS 的基本控制項庫、回應式設計的實現原理等等，明白這些，你的設計才算找到了和技術連接的支點。
3. 實現設計的價值
只有基於這些和技術連接的支點，你的設計構想才能真正落地，構成了一圈新的「大氣層」。由於技術基礎和開發週期的限制，你的設計通常沒辦法100%實現，但只要你的支點夠牢，你的設計構想就能夠最大程度地進行還原。
只有真正還原了的設計，才構成了設計的價值。
就像符合格律的詩歌才有韻味一樣，設計師也是戴著鐐銬跳舞的舞者，這些「技術鐐銬」不是羈絆你舞步的阻礙，相反的，正是因為戴著它們你還能跳得比別人好，你才變得與眾不同，你的設計才比別人的更有價值。
千萬不要讓你的設計變成了天馬行空的「大膽構想」，想得再好卻缺乏實現的可能，落地就會變成薄薄的一層爛泥，那些只是無價值的設計。
「盡可能地去瞭解你為之設計的系統的性能和限制。這有助於你提升繪製用戶理想流程圖和在設計中加入新特色和交互的能力。」
——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 了，至於和你想的一不一樣我不知道，先做出來看看再說。
但現實是殘酷的，最終實現出來的往往是南轅北轍。
何不試著改變一下輸入方式？
還記得我在<騰訊設計師：交互知識樹系列之視覺思維>文章裡提到的電腦管家小火箭改版嗎？
我們為小火箭重新設計了一套新的發射動畫，相比原來的時間更短、加速感更強，火箭在上升過程中還會旋轉，確實很酷。這要靠交互稿和視覺稿當然都是說不清楚的，為此我們為它做了個高保真視頻 Demo：
開發同學：「嗯，看懂了，確實很快，但快到我都看不清啊，這要怎麼做？」
我和視覺：「稍等，我們想想辦法。」
我們當然不會讓開發同學對著視頻一幀一幀研究，他們沒那個功夫，我們反其道行之。我們用 Visual Basic 語言寫了個程式 Demo，用一個很精簡的函數就實現了視頻 Demo 中的那種多段加速的動畫：
按我們老大的說法，把這套代碼直接丟給開發就行了，他們能看得懂的。
然而，對方長久的沉默讓我看出了他的心聲：「這什麼鬼，懶得研究！」
所以我只好使出「終極大招」，我自學了 Visual Basic，自己看懂了函數，然後在紙上一番埋頭苦算，終於給出了一份詳盡的動畫「說明書」，
這份說明書包含什麼內容呢？
整個小火箭的動畫，從點擊開始，小火箭每一步的動畫分解，細緻到了每毫秒的動作；
在每毫秒的過程中，每個元件分別是怎麼動作的，方向、速度如何，當然也包括了小火箭上升的幾段過程的分解；
小火箭旋轉需要播放一套序列幀動畫，開發能實現的最小顆粒度是10毫秒播放一幀，我就寫明白了每個時刻要從哪一幀播放到哪一幀。
寫完，我帶著這份說明書，搬一把椅子就坐在開發同學後面了。
「來來來，看這個，我們一點點改，保證完美還原，效果不好算我的。」
這樣一來，我們的設計支點就提高了，離我們的設計構想近了很多，最終實現的效果非常贊。
如果你想要做的是一個創新型的設計，那不妨換成這種「輸入方式」：用高保真原型（Demo）來一比一展示你要的設計效果，再通過動畫說明書來完整說明設計的每一個細節，確保傳達給開發同學的「輸入 X」足夠精准，這樣他才能夠通過演算法來幫你實現足夠完美的「輸出 Y」。
細心的朋友可能發現了，我們在尋找最優「輸入方式」的過程中，其實也用了演算法的思維（我們甚至連代碼都寫了），不斷改進自己給出的「輸入材料」，才有了最後的「動畫說明書」。
3. 模組化設計
為什麼每次我們都要這麼麻煩地搞什麼輸入、輸出和演算法？為什麼不能把已有的演算法給固定下來呢？
當然可以，開發同學最喜歡的就是把演算法給固定下來了，這就是「模組化」。
熟悉 iOS 平臺的同學一定知道，蘋果公司會給每個版本的系統都提供「Design Template」（設計範本），其實這些就是開發同學在Xcode開發環境裡可以用的「演算法模組」。如果你設計的時候用的是這些模組，那他只要修改幾個參數就能直接複用了。
舉個例子，在 iOS 系統裡有種從下往上彈的功能表叫做「Action Sheets」，蘋果的設計和開發人員考慮到了它的各種使用的情況，然後把它包裝成了一個「演算法模組」。
當你要使用的時候，可以只用1個「Action」，也可以用3個甚至更多的「Action」，你甚至還可以用到包含可以橫向滾動圖示的方案。這一切的修改，對於你來說只是在設計範本中複製粘貼和改幾個文字而已，對於開發同學來說也一樣，他也只要在蘋果給的控制項庫裡調出這個 ActionSheets 控制項，然後改幾個參數就行。
這種極大簡化設計和開發流程的東西，就是演算法模組，主動製造這種模組的過程，就叫做「模組化設計」。
可能看這種控制項還沒感覺，再來看看蘋果的官網吧。
這個 iPhone 的產品頁面你一定很熟悉了，它用的其實就是典型的模組化設計，我們來找找看。
如上圖，其實它包含了頁面導航模組、機型選擇模組、頁面主副標題模組、相關連結模組和產品圖片模組等，這些內容都是可以根據需要自由定制的，只要簡單做一個更換，就能馬上變成另一個頁面，如下圖。
是不是很省事？
不要小看模組化設計，用它設計出一套好看的頁面之後再複用，對於設計來說就形成了設計規範，而對於開發同學來說，他能讓這些代碼變成可複用的演算法模組 U(X)，以後你可以隨意更換輸入 X，他都能用這個模組給你快速地生成你想要的輸出 Y。
因此，時刻心中都有模組意識的交互設計師，他會在合理設計頁面功能的情況下，盡可能地複用設計，和視覺設計師一起把它們固化成模組，就像在生產樂高積木一樣。這樣一來，只要完成了主要頁面和主風格的設計，剩下再多的頁面也不過是一種理性地拼裝和因地制宜地修改而已。
現在你是否明白了為什麼開發們那麼喜歡上 GitHub 這類開源網站？就像我們上 Dribbble 和 Behance 尋找設計靈感一樣，他們也是在學習別人的演算法模組。
------
作者：落羽敬齋，原創發佈，如需轉載請聯繫原文作者
商業轉載請聯繫作者獲得授權，非商業轉載請注明出處！
他們分別能實現的程度是怎樣的？你們的開發團隊有相應的技術儲備嗎？是否能直接找這些公司合作呢？就算你做的不是什麼創新的設計，但是要保證你做出的設計能夠很好地被開發還原出來，你也應該知道點九切圖法、Retina 螢幕的切圖比例、iOS 的基本控制項庫、回應式設計的實現原理等等，明白這些，你的設計才算找到了和技術連接的支點。
3. 實現設計的價值
只有基於這些和技術連接的支點，你的設計構想才能真正落地，構成了一圈新的「大氣層」。由於技術基礎和開發週期的限制，你的設計通常沒辦法100%實現，但只要你的支點夠牢，你的設計構想就能夠最大程度地進行還原。
只有真正還原了的設計，才構成了設計的價值。
就像符合格律的詩歌才有韻味一樣，設計師也是戴著鐐銬跳舞的舞者，這些「技術鐐銬」不是羈絆你舞步的阻礙，相反的，正是因為戴著它們你還能跳得比別人好，你才變得與眾不同，你的設計才比別人的更有價值。
千萬不要讓你的設計變成了天馬行空的「大膽構想」，想得再好卻缺乏實現的可能，落地就會變成薄薄的一層爛泥，那些只是無價值的設計。
「盡可能地去瞭解你為之設計的系統的性能和限制。這有助於你提升繪製用戶理想流程圖和在設計中加入新特色和交互的能力。」
——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 了，至於和你想的一不一樣我不知道，先做出來看看再說。
但現實是殘酷的，最終實現出來的往往是南轅北轍。
何不試著改變一下輸入方式？
還記得我在<騰訊設計師：交互知識樹系列之視覺思維>文章裡提到的電腦管家小火箭改版嗎？
我們為小火箭重新設計了一套新的發射動畫，相比原來的時間更短、加速感更強，火箭在上升過程中還會旋轉，確實很酷。這要靠交互稿和視覺稿當然都是說不清楚的，為此我們為它做了個高保真視頻 Demo：
開發同學：「嗯，看懂了，確實很快，但快到我都看不清啊，這要怎麼做？」
我和視覺：「稍等，我們想想辦法。」
我們當然不會讓開發同學對著視頻一幀一幀研究，他們沒那個功夫，我們反其道行之。我們用 Visual Basic 語言寫了個程式 Demo，用一個很精簡的函數就實現了視頻 Demo 中的那種多段加速的動畫：
按我們老大的說法，把這套代碼直接丟給開發就行了，他們能看得懂的。
然而，對方長久的沉默讓我看出了他的心聲：「這什麼鬼，懶得研究！」
所以我只好使出「終極大招」，我自學了 Visual Basic，自己看懂了函數，然後在紙上一番埋頭苦算，終於給出了一份詳盡的動畫「說明書」，
這份說明書包含什麼內容呢？
整個小火箭的動畫，從點擊開始，小火箭每一步的動畫分解，細緻到了每毫秒的動作；
在每毫秒的過程中，每個元件分別是怎麼動作的，方向、速度如何，當然也包括了小火箭上升的幾段過程的分解；
小火箭旋轉需要播放一套序列幀動畫，開發能實現的最小顆粒度是10毫秒播放一幀，我就寫明白了每個時刻要從哪一幀播放到哪一幀。
寫完，我帶著這份說明書，搬一把椅子就坐在開發同學後面了。
「來來來，看這個，我們一點點改，保證完美還原，效果不好算我的。」
這樣一來，我們的設計支點就提高了，離我們的設計構想近了很多，最終實現的效果非常贊。
如果你想要做的是一個創新型的設計，那不妨換成這種「輸入方式」：用高保真原型（Demo）來一比一展示你要的設計效果，再通過動畫說明書來完整說明設計的每一個細節，確保傳達給開發同學的「輸入 X」足夠精准，這樣他才能夠通過演算法來幫你實現足夠完美的「輸出 Y」。
細心的朋友可能發現了，我們在尋找最優「輸入方式」的過程中，其實也用了演算法的思維（我們甚至連代碼都寫了），不斷改進自己給出的「輸入材料」，才有了最後的「動畫說明書」。
3. 模組化設計
為什麼每次我們都要這麼麻煩地搞什麼輸入、輸出和演算法？為什麼不能把已有的演算法給固定下來呢？
當然可以，開發同學最喜歡的就是把演算法給固定下來了，這就是「模組化」。
熟悉 iOS 平臺的同學一定知道，蘋果公司會給每個版本的系統都提供「Design Template」（設計範本），其實這些就是開發同學在Xcode開發環境裡可以用的「演算法模組」。如果你設計的時候用的是這些模組，那他只要修改幾個參數就能直接複用了。
舉個例子，在 iOS 系統裡有種從下往上彈的功能表叫做「Action Sheets」，蘋果的設計和開發人員考慮到了它的各種使用的情況，然後把它包裝成了一個「演算法模組」。
當你要使用的時候，可以只用1個「Action」，也可以用3個甚至更多的「Action」，你甚至還可以用到包含可以橫向滾動圖示的方案。這一切的修改，對於你來說只是在設計範本中複製粘貼和改幾個文字而已，對於開發同學來說也一樣，他也只要在蘋果給的控制項庫裡調出這個 ActionSheets 控制項，然後改幾個參數就行。
這種極大簡化設計和開發流程的東西，就是演算法模組，主動製造這種模組的過程，就叫做「模組化設計」。
可能看這種控制項還沒感覺，再來看看蘋果的官網吧。
這個 iPhone 的產品頁面你一定很熟悉了，它用的其實就是典型的模組化設計，我們來找找看。
如上圖，其實它包含了頁面導航模組、機型選擇模組、頁面主副標題模組、相關連結模組和產品圖片模組等，這些內容都是可以根據需要自由定制的，只要簡單做一個更換，就能馬上變成另一個頁面，如下圖。
是不是很省事？
不要小看模組化設計，用它設計出一套好看的頁面之後再複用，對於設計來說就形成了設計規範，而對於開發同學來說，他能讓這些代碼變成可複用的演算法模組 U(X)，以後你可以隨意更換輸入 X，他都能用這個模組給你快速地生成你想要的輸出 Y。
因此，時刻心中都有模組意識的交互設計師，他會在合理設計頁面功能的情況下，盡可能地複用設計，和視覺設計師一起把它們固化成模組，就像在生產樂高積木一樣。這樣一來，只要完成了主要頁面和主風格的設計，剩下再多的頁面也不過是一種理性地拼裝和因地制宜地修改而已。
現在你是否明白了為什麼開發們那麼喜歡上 GitHub 這類開源網站？就像我們上 Dribbble 和 Behance 尋找設計靈感一樣，他們也是在學習別人的演算法模組。
------
作者：落羽敬齋，原創發佈，如需轉載請聯繫原文作者
商業轉載請聯繫作者獲得授權，非商業轉載請注明出處！