開發思惟方式淺談

以前看了騰訊高級交互設計師WingST寫的一篇《交互設計技能書——開發思惟》的文章提到的「開發思惟」深有感觸，結合實際工做中遇到的一些問題，談談我對「開發思惟」的理解。

身爲一個網絡公司的UI組成員，公司裏幾乎都是有開發背景的同事，當組成一個項目組時，咱們根據本身的專業各司其職，可是愈來愈多的問題開始出現，其中一個很是重要也很是常見的問題就是——跨領域溝通問題。

最初的計算機是沒有界面的，經過一些列複雜的命令運算使用，外形也很是複雜龐大；隨着科技的進步，漸漸出現了我的電腦（PC），做爲施樂最出名的研究機構，PARC爲隨後大範圍普及的我的電腦的設計型態和交互邏輯定下了基調。Bob Taylor，做爲一名訓練有素的心理學家和工程師，帶領着他的團隊構建出了人機交互領域最重要也是最普及的工具，包括圖形化界面（GUI）和鼠標。（隨後喬布斯和蓋茨前後訪問了PARC，參考了施樂之星的設計，爲今天的蘋果和微軟開闢了通向將來的道路。）

（第一臺搭載圖形界面的蘋果電腦）

若是看看整個計算機的發展史，很早以前，前輩們就開始注重「用戶體驗」了。設計師做爲用戶和產品開發之間的橋樑，不只應該有用戶思惟，也須要有開發思惟。由於若是不明白自家的產品究竟用的是什麼技術，那設計出的產品極可能是天馬行空的。

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

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

設計師最擅長的是構想

開發關心如何實現這個功能，邏輯是否是和其餘功能相容等；設計師關心這個功能能不能幫到用戶，怎麼讓這個功能一會兒就讓用戶找到，同時讓用戶眼前一亮，欣喜的使用咱們的軟件。正由於咱們的專業背景不一樣，角度不一樣，若是隻是各想各的各說自話，就很容易致使設計構想與技術基礎都漂浮着，沒有鏈接在一塊兒。我舉個栗子：

有一次，爲了不用戶等待時間過長形成煩躁和重複操做，咱們用AE畫了一個很具公司特點的小動畫，一個開發拿到手以後，這個不行，很差實現，我得寫一個星期；另一個開發拿到手以後，沉吟了幾秒，說「我能夠試試，可是你得把xxxxx參數給我」，咱們的設計人員傻眼，「啥？」猶豫了一下，「我能夠把AE裏的公式給你，而後它是這麼這麼轉的」，設計人員用手勢表達了一下這個動畫的運起色制。開發人員說，「再見！」。這個動畫基本上是開發猜着寫的，結果可想而知，效果仍是差那麼一丟丟，對於咱們「像素眼」來講，但是大事，一直讓開發人員調整，調來調去仍是不對，開發人員大怒，直接撂挑子不幹了。設計人員很委屈，我就是是讓你改改，一點小細節不行在用戶看來都是不專業的表現；開發人員也委屈，你就扔給我一個gif，就讓我本身把過程猜出來寫，能寫出來都不錯了，還挑！

讓咱們時光倒流，若是，咱們稍微瞭解一下動畫的實現機制。是否是能夠把開發人員須要的參數給他呢？若是能夠這樣，開發人員可能就不會猜着寫，偏差就不會那麼大，結果可能就不會鬧的那麼僵。

再舉個例子，咱們用代碼寫段文字時，會有一個行高的概念，好比一個tab標籤的標題，選中時下面會有一條橫線，咱們爲了實現這個效果，會給這個標題加一個行高，這樣能夠直接給盒子加底部線條。可是呢，在設計人員標註時，其實是沒有行高的概念的，通常都是貼邊算間距，這樣比較規矩。這時候咱們又產生了分歧，致使的是，設計這邊辛辛苦苦標註了好久，到開發那邊沒什麼用，最終出來了效果圖仍是差距很大，一度讓設計人員認爲，我標那麼就你根本不看！可是開發人員也一肚子苦水，你只給我兩行字的間距，這個行高你讓我咋算，其餘的行高是否是都是一致的我也不知道！爲了解決這個問題，咱們兩個組就標註的問題，開了好幾回會，最終定下來的標註規範，效果甚微。由於設計人員的不理解，行高標註了可能也不適用。

後來，爲了兩個組更好的溝通，設計人員開始學習html+css，前端開發開始熟讀交互設計規範；到真正本身去用代碼還原一個頁面時，才瞭解到，什麼樣的行高是有效的，即便咱們對比着設計稿一比一還原，仍是有視覺差等等等等。設計組和前端組的溝通才漸漸好轉。

尋找設計的支點

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

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

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

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

實現設計的價值

只有基於這些和技術鏈接的支點，你的設計構想才能真正落地，構成了一圈新的「承重牆」。因爲技術基礎和開發週期的限制，你的設計一般沒辦法100%實現，但只要你的支點夠牢，你的設計構想就可以最大程度地進行還原。

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

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

千萬不要讓你的設計變成了天馬行空的「大膽構想」，想得再好卻缺少實現的可能，落地就會變成薄薄的一層爛泥，那些只是無價值的設計。常常看到dribble、站酷上很華麗、炫酷的移動端概念稿，這樣的概念稿僅限於拓展思路，若是盲目的使用...看你的開發搭檔會不會打你。

無價值的設計

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

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

要理解開發思惟，就要先解釋一下程序員經常掛在嘴邊的「算法」到底是什麼，只有理解了算法，纔算真正理解了開發思惟。

算法的本質

算法（Algorithm）是指解題方案的準確而完整的描述，是一系列解決問題的清晰指令，算法表明着用系統的方法描述解決問題的策略機制。也就是說，可以對必定規範的輸入，在有限時間內得到所要求的輸出。——百度百科

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

根據這三個關鍵字咱們能夠得出算法的數學方程式：

Y = U(X)

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

好比，你的拇指按下了手機的HOME鍵，手機屏幕亮了。你按下HOME鍵的動做是輸入X，手機屏幕亮是輸出Y。當咱們拇指按下HOME鍵後，手機的系統可能須要判斷是否是手機主人的指紋、是否解鎖手機，解鎖手機後是否是屏幕亮起等等一些列的判斷過程，這整個的過程就是算法U（X），它解決了按下HOME鍵讓手機屏幕亮的需求。

開發同窗的偉大之處就在於，他們會不少厲害的算法，能把你的設計經過代碼還原成 APP、Web 網站以及各類形態的軟件產品，你的設計方案對於他們來講就是輸入，最終的產品就是輸出。

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

改變輸入方式

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

你的設計構想是很完美很厲害，可是你給開發同窗的不過是一張簡單的原型圖和交互說明的交互稿，以及一張看起來華麗卻不會動的視覺稿，你以爲他們對你的這種輸入方式能理解多少？恐怕只有不到一半吧。剩下的那些，開發同窗只好自由發揮了，否則東西作出來但是會有Bug 的。況且開發時間還那麼少，老大們可不會找設計師催進度。

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

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

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

接下來是原做者超厲害的例子

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

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

我和視覺：「稍等，咱們想一想辦法。」

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

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

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

因此我只好使出「終極大招」，我自學了 Visual Basic，本身看懂了函數，而後在紙上一番埋頭苦算，終於給出了一份詳盡的動畫「說明書」，

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

整個小火箭的動畫，從點擊開始，小火箭每一步的動畫分解，細緻到了每毫秒的動做； 在每毫秒的過程當中，每一個組件分別是怎麼動做的，方向、速度如何，固然也包括了小火箭上升的幾段過程的分解； 小火箭旋轉須要播放一套序列幀動畫，開發能實現的最小顆粒度是10毫秒播放一幀，我就寫明白了每一個時刻要從哪一幀播放到哪一幀。 寫完，我帶着這份說明書，搬一把椅子就坐在開發同窗後面了。

這樣一來，咱們的設計支點就提升了，離咱們的設計構想近了不少，最終實現的效果很是贊。

原做者的不屈不撓的精神很讓人佩服，咱們在工做過程當中，何不試試優化本身輸入的方式呢？咱們在尋找最優「輸入方式」的同時，其實也就有了算法的思惟，不斷改進本身的「輸入」，開發給出的「輸出」就越接近咱們想要的。

模塊化設計

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

咱們設計這邊的「模板」或者開發用到的「組件」，就是模塊化的設計。

好比說一個彈窗組件，開發人員引用後，只須要修改幾個參數就能夠直接複用了。

模塊化設計對於設計的意義：

• 是在特定場景下的最佳展示方式
• 能保持產品的交互、視覺風格一致性
• 便於協做、修改

模塊化設計對於開發的意義：

• 下降耦合度
• 減小冗餘代碼，提升性能
• 便於協做、修改
• 便於查錯

...

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