設計師如何掌握工程師思維？

 　　這個問題的簡單回答是：根本沒有“工程師思維”。

　　當設計思維被廣泛談論的時候，慣性思維使然，出現了所謂“工程師思維”，直覺上，“工程師思維”仿佛站在了“設計思維”的對面，但事實上，工程師思維是並不存在的概念，設計思維跟設計師這個角色沒有多直接聯系。

　　於是，當你的問題是：設計師應該如何鍛煉自己的工程師思維的時候，真正的問題應該是：如何和工程師合作。

　　更好地和工程師合作並不是掌握所謂工程師思維，而是應該學會如何像工程師一樣的思考，那麼工程師是如何思考一個問題的呢?

　　工程師重要的思考習慣是從幾個方面的信息中產生模式(Pattern)，通過模式產生出代碼，因此，一個好的溝通模式是設計師盡可能提供足夠的信息幫助工程師形成“模式”。

　　另一個方面，設計師往往喜歡從用戶的角度講述流程，而工程師所習慣關注地往往是“數據交互”而非“人機交互”，這也是設計師和工程師思考方式的不同之一。

　　這並不代表向工程師講交互流程並不重要，而是我們需要結合“數據交互”和“人機交互”二者與工程師進行溝通。

　　數據交互

　　設計師通常擅長講解“人機交互”，那麼我們來看看設計師應該如何講解“數據交互”，我們推薦設計師思考以下四個方面：

　　條件(Condition)

　　異常(Exception)

　　邏輯(Logic)

　　數據(Data)

　　假設我們要向工程師表達一個登錄的設計：

　　一個用戶名輸入框

　　一個限定位數的密碼輸入框

　　一個按鈕

　　最傳統的溝通方式是使用頁面流圖的方式，從用戶的角度，把使用場景、信息架構、頁面流程、交互行為完整的展示，而如果我們考慮工程師的思維方式，我們可以體現以下信息：

　　條件

　　進入這個設計的觸發條件是什麼，例如登錄的入口，點擊什麼內容能夠觸發這個登錄界面;進入這個設計的前提條件是什麼，例如用戶未曾登錄。

　　異常

　　這裡的異常通常指異常的數據輸入，這有別於一個錯誤的結果，後者只是結果的一種，經過判斷邏輯，而前者的異常出現在邏輯執行前。

　　邏輯

　　邏輯用來處理1)異常的數據輸入;2)正確或錯誤的處理結果;3)後台其他的寫入邏輯。在我們的例子中它們分別對應：1)超過位數限制的密碼;2)密碼交驗邏輯;3)後台記錄一次登錄時間。

　　數據

　　數據記錄著在整個設計中，需要什麼樣的數據作為輸入、需要什麼樣的數據作為展示，以及數據的讀寫。

　　系統復雜度

　　系統復雜度往往是沒有工程背景的設計師所難以理解的概念，因為大部分“以用戶為中心”的設計師通常以用戶的感官設計體驗，而非系統，這並不是反對“以用戶為中心”的設計方式，而是多一種思維習慣去理解工程師對實現的擔憂。怎麼感覺系統復雜度呢?

　　其實很簡單，當你仔細思考上面提到的條件、異常、邏輯、和數據四個方面，當每個分類中的需求越多，復雜度自然變高，這樣的思考也會使得你逐漸簡化你的設計。

　　一個突破現有模式的“新模式”也會提高整個的系統復雜度，例如當我們已有一個模式叫做“點擊某個內容，彈出登錄界面”，如果要新增加一個模式叫做“點擊內容超過5次，彈出登錄頁面”，這裡需要對以前的現有模式進行修改，整體的復雜度也有所提升。

　　此外，數據的相關性也需要考慮，當數據來自於不同系統，或使用不同系統對已有邏輯進行數據處理，系統的復雜度也會大大提升。

　　因此當工程師進行估算時，你不妨去聽聽他們估算的方式，他們的語言往往不是基於頁面，而是舉出例子來評估系統復雜度，例如：“3個數據需要從第三方來、調用3個接口、有10條後台邏輯要寫、5個前台邏輯、2個新頁面模板、1個數據要寫入其他模塊、需要重構、需要修改以前的核心業務測試邏輯”。當你面對自己的設計，能夠掰出手指數出影響系統復雜度的幾個因子，在和工程師溝通時自然能夠理解他們所說的語言。

　　設計思維

　　之所以我認為設計思維的對面絕對不是工程師思維，是因為，設計思維本身就是工程師和設計師應該共同擁有的思維習慣，而並不區分角色。除去“數據交互”和“人機交互”，設計師應該幫助工程師了解的是上下文(Context)。

　　上下文是隱藏在“數據交互”和“人機交互”之下的東西，它通常包含很多方面，例如市場變化、客戶習慣、應用趨勢、行為數據等等。例如“點擊內容超過5次，彈出登錄頁面”背後的上下文可能是：用戶停留在“發現頁面”上的時間很長，但是一旦點擊一個內容彈出對話框後頁面離開率很高。

　　通常的情況下，這樣的信息甚至連設計師都無法掌握，更不用說傳遞給工程師了，而設計師真正應該做的，是將這“雙頭冰山”水上和水下的部分統統展示出來，這也是設計思維的真正體現。

　　真正的修煉

　　歸根結底，真正的修煉在於“去體驗程序員做的事情”，例如抽象模式、歸納邏輯、建立假設、建立標准。有人說，過度追求邏輯和模式可能使設計缺乏“人”的因素，事實上，大部分的設計師連“追求”都談不上、還不需要擔憂“過度追求”。

　　以前曾經提過關於網頁工程方面的技能積累，除了掌握一定的前端知識之外，培養自己的系統思維能力也是必不可少，培養系統思維主要分：

　　系統內部的關系

　　系統外部的聯系

　　了解系統內部關系幫助我們看穿一個看似封閉的系統(用戶通常無法感知也是以用戶為中心的設計無法解決的)。小時候特別喜歡看《魯布·戈德堡機械》，看似平常物之間奇妙的互動最後完成一個平常的任務，這就是系統的樂趣所在，此外仔細研究幾個著名的“系統故事”也可以逐漸培養你的邏輯和系統思維，例如“囚徒困境”、“啤酒游戲”。

　　了解系統外部的聯系幫助我們在更高的角度理解整個生態系統，這裡聯系除了工程師更多關注的數據聯系，包含經濟、人文、文化、政治、環境等諸多聯系，這並不意味著設計一個登錄界面需要考慮對環境有什麼影響，這只是一種思維方式，這樣的思維方式幫助設計師與工程師進行溝通和協作。

　　從設計師到營造者

　　建築師(Architect)一詞在希臘語詞源arkhitekton中包含兩個意思arkhi-, chief + tekton, builder，也就是Chief Builder，通過與工程投資方和施工方的合作，在技術、經濟、功能和造型上實現建築物的營造，他們兼具藝術家的審美眼光、工程師的力學和材料知識、還要有說服商業投資者的商業頭腦。在這裡，他們並不是“設計師”(Designer)，而是“營造者”(Builder)。

　　在軟件領域，也有“程序員(Developer)”和“架構師(Architect)” 的區別;有趣的是在我們所說的設計領域(數字產品設計)，卻鮮有“Architect”的概念，有的最多是“產品經理”這樣的角色(殘缺的)。相信在不久以後，我們所在的領域，也會出現這樣的角色，他們擁有：

　　人機交互設計師對於信息、界面、交互、視覺表現優秀的審美;

　　工程師對於邏輯、流程、數據、系統的思維方式;

　　對商業、環境、文化、人因、政治諸多因素的審視。

　　我們經常陷入一種誤區，害怕某種思維方式會影響我們現有的思維方式，例如過多的邏輯思維會不會影響我對人和直覺的關注，最後影響我的設計，當設計越來越不是一個單獨的技能而進化為一個“整體營造行為”中的一部分時，我們所執著的思維方式也需要演進。

　　這並不意味我們需要掌握並不存在的“工程師思維”、使用它和工程師進行合作，而是將工程師看待設計的方式融入到我們自己的思維習慣中，這也將幫助我們完成從設計師到營造者的轉化，作為“營造者”，你必將超越工程師、產品經理、和現在作為設計師的你。