交互技能樹05 | 交互設計師的開發思維

04-20

本文是在我的微信公眾號「落羽敬齋（wingstudy）」上連載的交互設計師技能樹系列文章，感興趣的同學可以關注下~

「他們喜歡戴著鐐銬跳舞，而且是其他詩人的鐐銬。」
They love to dance in these fetters, and even when wearing the same fetters as another poet.
——布里斯·佩里（Bliss Perry)，美國文學評論家

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

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

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

理解限制，實現設計價值

「不要將系統的限制或條件視為局限性，把他們看成構建創意設計的根基。」
——Luke Miller，《用戶體驗方法論》

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

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

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

2. 尋找設計的支點

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

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

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

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

3. 實現設計的價值

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

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

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

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

擁抱限制，尋找技術邊界

「儘可能地去了解你為之設計的系統的性能和限制。這有助於你提升繪製用戶理想流程圖和在設計中加入新特色和交互的能力。」
——Luke Miller，《用戶體驗方法論》

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

演算法的本質

演算法（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)幫你解決的。

改變輸入方式

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

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

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

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

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

還記得我在視覺思維那篇文章里提到的電腦管家小火箭改版嗎？

交互技能樹 | 交互設計師的視覺思維

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

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

我和視覺：「%……稍等，我們想想辦法。」

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

出於保密原則，具體函數就不放出來了

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

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

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

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

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

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

「來來來，看這個，我們一點點改，保證完美還原，效果不好算我的。」

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

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

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

模塊化設計

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

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

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

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

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

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

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