代碼複雜度只是研發的問題嗎？—在設計思維中注入一劑技術思維
原文作者：Kevin Gates
翻譯：張慶霖、張秋儀、劉娟
審校編譯：丁教練
預計閱讀時間：8分鐘
作為一名設計師，我經歷過太多次如下場景：「項目組全員聚集在會議室里，一起評審剛完成的界面設計。一段漫長的沉默後，研發哥哥嚴肅地問：「我們真的要實現這些功能嗎？」全場與會人員雙臂交叉，氣氛緊張。
研發和設計之間的這種「貓狗」對立關係是時候結束了。設計師應積極地去理解和共情研發哥哥，特別是去關注他們的擔憂和顧慮，並在設計過程中給他們一個重要位置。
在互聯網行業中,設計並不直接傳遞用戶價值，代碼是傳遞價值的唯一「馬車」。舉個栗子：以圖片、草圖、原型為載體的所謂「世上最好的設計」，我們欽佩它美麗、精妙的交互和創新, 但它並不為用戶提供直接價值。代碼是用戶與產品交互並獲取其價值的實際媒介。
因此，設計者需要學會關心代碼的質量。
產品的複雜稅
某些情況下,代碼質量對於良好用戶體驗的重要性顯而易見。比如，低質量代碼容易造成程序運行速度緩慢，就會直接影響到體驗。bug的頻繁出現，也容易造成用戶流失。
但於代碼設計者而言, 某些起決定性影響的因素往往是非常微妙的: 如緩慢增長的代碼複雜度*（即「熵」）。處理起這種複雜度很是棘手。它通常不會突然出現，而隨著時間的推移, 這種累積的複雜度會減緩產品的迭代、適應或增長的能力。你想在產品上嘗試的一切，它都會對其造成一定阻礙，就如像你強制性地征「稅」。
（*譯者註：代碼複雜程度可以用「熵」表示，一個經歷持續修改的軟體系統，例如有新的功能添加到它的最初設計上或適合於最新的技術環境，將隨著它的增長變得更加複雜和紊亂，在迭代過程中不斷增加軟體熵，代碼越來越難以維護。）
代碼複雜度其實與項目息息相關，但通常只有程序員群體關注到這一點，這點是急需改變的。為什麼呢？多數研發團隊優先考慮成本，而大部分設計團隊優先考慮用戶價值。但產品的潛在成本應同時兼顧技術成本和用戶價值。我們需要儘早討論項目的複雜性——越早越好。整個團隊若想針對成本和價值開展富有成效的對話，就需要一同去明確正在解決的問題及其原因。
下面我們將具體討論如何促進設計師與程序員之間的協作，以共同降低代碼複雜度。
一次性的設計
當設計師透徹地理解用戶問題時，解決方案的可取性更高：
· 能夠更安全地錨定在用戶的具體需求上；
· 趨向於更簡單，也因此更豐富。
當豐富的解決方案在低保真原型中被表達時，它們便具備一個新特性：一次性。面對用戶給出的任何問題，設計師應儘可能低成本地呈現他們的想法——線框或簡單的草圖。一次性的想法不會過分講究，也易於丟棄。
丟棄想法，使用戶受益
如果兩個想法對用戶產生相同的影響，但研發非常擔心其中之一會使代碼日益複雜，你就需要在形成高成本前將其扼殺。想法是一次性且廉價的，但代碼則是昂貴且持久的。
設計師應積極處理具有高成本/價值比的創意，並與研發一起尋找更好的方法。雙方合力減少未來可能產生的代價。長遠來看這有益於用戶，一個健康的設計過程應該捨棄那些「必掛」的想法，以產品未來的成功為導向。
捍衛想法，使用戶受益
當研發不願去實現設計稿時，設計同事們便會覺得很沮喪。更糟糕的是，他們會把設計規範扔給研發，讓他們「自謀生路」，到頭來又驚訝於差勁的還原度。這樣很可能導致研發在未理解用戶價值的情況下陷入高度的複雜性。由於設計師沒有跟進與協作，研發只能無奈地拼湊出一個解決方案。
如果你對研發所擔憂的解決方案報以強硬的態度，你首先要去了解它的成本，然後確保你能說服研發它是值得的。幫助他們理解這一功能點為什麼重要，並展現出替代方案不會令人滿意的理由。
建立橋樑
以程序員的視角審視設計過程可以幫助我們建立融洽的關係。這裡有兩個技巧：
與程序員共同創造
什麼樣的好方法可以早早獲取程序員的反饋呢？讓程序員與你一起設計！！！
程序員會不自覺地從技術角度思量解決方案可行性。一方面，他們能朝著切實可行性的方向來引導你的想法；另一方面，他們亦能引導你反向思考什麼才是具有可行性想法的。
「合作創造的最佳時機是在項目初期階段」——這一階段你可以合理規避前期所產生的一些問題，並與開發者建立起融洽關係。這一技巧如果應用在代碼已實施階段，往往無法奏效。創建一個執行性強的解決方案是研發在代碼實施階段的首要目標，其餘的事都被其認為是分心。也就是說，在項目迭代的壓力下，我不指望他們會不時地與你合作。
上圖是程序員與我們一起設計數據儀錶盤。她最近忙於解決MySQL的相關問題。我們會先讓她講解自己的工作經歷，然後我們一同設計了她心中的理想儀錶盤。我們記錄下設計過程中的對話，並對設計進行了注釋，之後我們把這次過程得到的見解應用到解決方案中。
怎麼做：根據項目大小，讓一或兩個程序員在白板前待上一個小時或更長時間。
· 首先，以非正式的形式來討論研究結果，向大家展示你想解決的用戶目標和相關論據，如列舉一些痛點。
· 接著介紹這一產品在現實世界使用的一些流程，我個人喜歡用場景劇本，有時候一些其他簡單方法也奏效。最重要的是你以框定問題、明確需求或動機開始，以解決方案結束討論。
你和工程師合力畫的原型會把問題和解決方案串接起來。
專業Tips：如果工程師不願畫出他的想法（這種情況經常發生），你可以用這種簡單的技巧引導他下筆：開始繪製UI原型然後故意在某個地方犯錯，當他指出來時，就問他怎麼處理。在恰當的時機將備好的筆遞給他，結果總會如你所願。
設計評審
在設計過程中一直跟研發合作固然很好，但是現實中他們總是特別忙。設計評審是在尊重研發人員迭代開發的前提下，獲取其前期反饋的一項方法制度。
怎麼做：定期（一周或兩周一次），將整個團隊聚在一起。
· 首先，花費30分鐘時間展示設計進程：低保真草圖、用戶流程、線框圖、UI組件等。
· 然後讓程序員拋出任何想法與疑慮。你所追求的是讓他們用直覺檢查複雜性，以便儘早地開始價值／成本的討論。如果程序員表達了疑慮，就反問他們：「是什麼讓你覺得擔憂」或者「我們能怎麼更好地處理這個問題」。
盡量安排好設計評審的結束時間，避免打斷程序員的節奏。另外，請牢記你是在要求程序員切換思維環境，為產品的未來形態思考，所以一定要花時間準備好展示文檔，讓他們能更快速了解你所講的東西。
使用時機：當產品團隊處於生產模式，且程序員忙於構建高執行性解決方案時，就可以使用設計評審。
下方是一個設計評審中產出的筆記：
雖然這是一個非常低保真的草圖，但這個原型已經表達了所有我們想要的。我們將這個展示給了用戶，並且對於這個概念得到了非常正向的反饋。可是當我們將這個草圖展示給我們的研發團隊時，它引起了一些超出範圍的擔憂。
設計評審的目標不僅是改善產品的產出，還希望有助於在設計和工程之間建立一段健康且融洽的工作關係。代碼複雜性嚴重影響程序員的工作，而設計評審對這一問題有所幫助。因為通過設計評審每個人對解決方案都已經很熟悉了，而且大多數問題已經基本被解決掉或被簡單處理了。
-------------------------------------------
原文標題：CodeComplexity is a Design Problem
發布日期：April 2,2018
版權聲明：本譯文僅用於學習和交流目的，謝絕商業轉載。非商業轉載請註明譯者、出處，並保留原作者信息。
今日互動
你有什麼好方法來促進設計師和工程師之間的協作嗎？在文章下方留言一起討論呦～
TAG:SFUED |