奧推網

選單
科技

來談談,如何用程式設計師思維服務設計

在產品設計業務推進的過程中,設計人員需要兼顧多方需求,並嘗試用更有效、更便捷的思維來服務於產品設計,從而達成更完善的使用者體驗。那麼,“程式設計師思維”作為思維方式的一種,是不是也是產品設計中可以採用的角度之一呢?不如來看看作者的解答吧!

我們在平時的產品實現過程中會經常與產品吵架,與開發撕逼。這是因為我們這些產品實現的參與者因為分工不同都有很強的邊界感,這種邊界感同樣也體現在思維模式上。

產品經理看待問題是以產品思維來思考;設計師做設計時也是以設計思維來思考;程式設計師更多是以程式碼實現的程式設計師思維來思考。

不同的思考方式,難免會出現不同的理解,同時也會出現描述問題時完全不懂對方在說什麼。

作為設計師,除了本職工作必須具備的設計思維外,更多的是要求我們需要有產品思維,將產品思維運用到日常的產品設計工作中,卻很少見到設計師去了解或掌握開發思維。

當然從開發實現角度來做設計儼然不現實,但是否可以運用程式設計師思維來服務設計呢,個人覺得是可以的。將程式設計師的思維方式應用到產品的設計實現中,是能夠提升產品體驗和提高團隊協作效率的。

一、什麼是程式設計師思維

什麼是程式設計師思維?沒有標準答案。

馬克思·韋伯在《新教倫理與資本主義精神》中提出過一個概念——工具理性。所謂“工具理性”,就是透過實踐的途徑確認工具(手段)的有用性,從而追求事物的最大功效,為人的某種功利的實現服務。

工具理性是透過精確計算功利的方法最有效達到目的的理性,是一種以工具崇拜和技術主義為生存目標的價值觀,所以“工具理性”又叫“功效理性”或者說“效率理性”。

相似的,程式設計也是根據客戶的需求,利用自己的專業技能將其編譯成計算機語言,生產出一個軟體產品,來幫助解決現實生活中的問題,從而實現產品的商業價值。因此,可以將程式設計師思維定義為是在理性思維的框架下,利用相應工具,來解決相應實際問題。

二、程式設計師一般都具備哪些思維

1. 底層思維能力:邏輯思維

處於不同階段的程式設計師所具備的思維能力會有所不同。但作為以邏輯思維縝密自居的程式設計師們,邏輯思維算得上是他們最底層的一種思維能力。

其實任何人都應該具備一定的邏輯思維能力,這樣在面對“槓精”的時候,能發現對方的邏輯謬誤;在思考問題的時候,能儘量做到邏輯完整;在表達的時候,能儘量做到邏輯清晰。

那什麼是邏輯,邏輯的起源經歷了從自然哲學到形而上學的發展,我們也無需深究其發展過程。借用大師的總結,邏輯是指思維的規律和規則。或者更簡單的理解,邏輯就是關係。

邏輯思維基本包含三個方面的要素:概念、判斷和推理,邏輯思維的要義,就在於正確運用概念、判斷、推理的思維形式。

概念是思維的基本單位;透過概念對事物是否具有某種屬性進行肯定或否定的回答,這就是判斷;由一個或幾個判斷推出另一判斷的思維形式,就是推理。

實際上閱讀一本書的邏輯也是包含這三個要素,如果你看過《如何閱讀一本書》,裡面提到的分析閱讀,說的就是如何透過提煉一本書的關鍵字詞(概念),關鍵句子(判斷),以及關鍵論述(推理)來分析一本書的主旨。

2. 必備思維能力:抽象思維和結構化思維

程式設計師每天面對的工作並不只是簡單的敲程式碼,而是需要對拿到的需求及問題進行分析、歸納、綜合、判斷、推理。從而抽象出各種概念,挖掘概念和概念之間的關係,對問題進行有序建模,然後透過程式語言實現業務功能。這裡面就需要應用到抽象思維和結構化思維。

1)抽象思維

抽象是有層次性的,抽象層次越高,內涵越小,外延越大,擴充套件性越好;反之,抽象層次越低,內涵越大,外延越小,擴充套件性越差,但語義表達能力越強。

我們可以根據畢加索的畫《公牛圖》來理解一下抽象思維:

抽象的三個特點:

第一,抽象是忽略細節的。抽象類是最抽象的,忽略的細節也最多,就像抽象牛,只是幾根線條而已。在程式碼中,這種抽象可以是Abstract Class,也可以是Interface。

第二,抽象代表了共同性質。類(Class)代表了一組例項(Instance)的共同性質,抽象類(Abstract Class)代表了一組類的共同性質。對於我們上面的案例來說,這些共同性質就是抽象牛的那幾根線條。

第三,抽象具有層次性。抽象層次越高,內涵越小,外延越大,也就是說它的涵義越小,泛化能力越強。比如,牛就要比水牛更抽象,因為它可以表達所有的牛,水牛隻是牛的一個種類(Class)。

2)結構化思維

結構化思維,是一種以邏輯(事物內在規律)為基礎,從無序到有序,將蒐集到的資訊、資料、知識等素材按一定的邏輯進行分析、整理,呈現出有序的結構,繼而化繁為簡的思考過程。其目的是減少複雜度和認知成本。

舉個簡單的例子說明結構化思維,嘗試用10秒鐘記住下面20個數字:

估計大多數人都很難在限定時間內記住。

但換一種方式,同樣讓你10秒鐘記住下面的這20個數字:

是不是so easy,甚至完全不用10秒,掃一眼就可以記住了。

事實上,這是兩組相同的數字,只是排列方式不同,第一組是無序的,第二組是有序的(有結構),也更有規律。

我們之所以能夠輕鬆記憶第二組數字,是因為其有結構、有規律,從而降低了複雜度和記憶負擔。面對無序的20個數字,我們需要記住20個記憶專案,套用設計心理學中的7+—2法則【米勒定律】,人類短暫記憶無法容納7個以上的記憶專案,因此我們很難記住這一組數字。

而正序排列的20個數字,我們實際上只要記憶兩個專案:一個是有0到9的20個數字,另一個是他們是正序排列的。

說到結構化思維,其實運用最多的要屬結構化思維的聖經——芭芭拉·明託的《金字塔原理》。至於為什麼是金字塔結構,大家可以自行去了解。

三、程式設計師思維與設計思維的不同

設計思維,本質上是一種以人為本的問題解決方法。這裡所說的設計是廣義的設計,是以探索人的需求為出發點,創造出符合其需求的解決方案。與傳統解決問題的方法不同的是,設計思維是面向過程的解決方案,而且是一個沒有標準答案的探索過程。

面對問題我們需要深入理解問題,這是一個發散的思考,從多方面瞭解問題發生的原因,然後歸納出問題的關鍵點。解決問題時也需要探索各種解決問題的可能性,具有創造性的給出合理的解決方案,並從中收斂選擇最佳解決方案。其實透過“雙鑽模型”就能很好的理解這一過程。

以人為本:

認識到一切問題歸根結底都是人的問題,從不同視角出發,對具體的人進行共情,而不是對抽象的事進行處理。

資訊澄清:

以人為中心重新組織和定義問題。在資訊澄清通常可以用一句話來描述問題:誰?(使用者User)有什麼需要?(需求Need)我發現了什麼?(洞察Insight),簡稱POV法。讓大家對問題形成統一的認識,因為在討論問題時,不同人理解與表達能力會有區別,造成的誤會可以在過程中逐漸排除。

視覺化:

可以表現更多資訊間的關係,更易被記憶和傳遞,讓資訊共享效率更高。

反覆迭代:

認識到設計過程中的不確定性與靈活性,反覆迭代是一種非線性目標向線性流程妥協的變通做法。在實際應用上,我們需要不斷的明確收穫然後繼續推進下去。

簡單瞭解設計思維後,我們可以簡單總結程式設計師思維與設計思維的不同之處:

① 程式設計師思維在解決問題時多為趨於嚴謹的線性推理,而設計思維則更趨向於創造性,多線並行的發散性思維解決方案。

② 某些共性問題的解決方案上,程式設計師需要提煉更抽象的特徵從而能夠做到結構更加清晰;而設計需要從不同視角考慮,對具體問題面向物件進行共情,從而提出不同符合使用者心理的解決方案。

③ 最表象的不同點就在於,程式設計師完成需求程式碼化,優先考慮是否可以程式碼實現,過程中會有哪些限制條件;設計則更多考慮可用性和視覺化,以一種更合理的狀態傳遞相關的資訊。設計師不只是基本需求的實現,同時要讓使用者有一種更優的體驗,能夠產生心理上的滿足感和愉悅感。

其實程式設計師思維和設計思維還是有共通點的,比如結構化思維的應用上,設計師需要以某種邏輯關係形成結構清晰的介面呈現給使用者,大大增強頁面的可讀性和可理解性。同樣的滿足金字塔原理的程式碼,其可讀性和可理解性也會極大的被增強。

程式碼也是一種表達,很多人以為程式碼是寫給機器執行的,實際上,程式碼是寫給人讀的,只是偶爾會被機器執行。

四、程式設計師思維如何應用到設計中?

1. 底層邏輯

底層邏輯的應用其實是貫穿整個產品生命週期的,不論是需求階段還是介面設計階段亦或是開發實現和產品測試,都是基於底層業務邏輯去實現產品的。

產品在互動設計上除了要符合業務邏輯,還需要符合開發實現邏輯。

比如頁面在進行資料互動時,介面的呼叫是同步還是非同步,這也將影響到介面的互動形式。在開始設計前,我們就需要弄明白資料互動介面的呼叫方式,什麼是同步什麼是非同步?

這裡我們先舉個栗子。

比如在正常工作中,我們需要和業務溝通需求。

如果在會議室進行面對面溝通,當你丟擲對需求的疑問後,需要業務當面給予你解答才算溝通結束。

這種就是

同步

如果在辦公室用郵件的方式溝通,當你發出對需求的疑問後,不需要在郵箱介面等他回覆,你可以關閉郵箱視窗去做其他的工作內容,不管多久,等他回覆你郵件後,你都會即時收到郵箱訊息提醒。

這種就是

非同步

所以,和溝通一樣,介面呼叫的方式分為同步呼叫和非同步呼叫。

同步呼叫是最常見的介面呼叫形式,在同步呼叫模式下,介面的呼叫方在一定時間範圍內一直等待,直到被呼叫方返回執行結果。比如頁面的載入,你需要停留在此頁面等待載入完成才能繼續後面的步驟。

非同步呼叫是介面呼叫方給被呼叫方發出指令,但不會愣在那等待結果,呼叫方會給被呼叫方提供一個回撥介面,處理完成後,再呼叫回撥介面返回結果。比如應用的更新升級下載,開始下載後我們可以將其置於後臺下載,無需等待下載結果,同時可以去完成其他任務。

我們無需去考慮通訊的底層協議是什麼,只單純的考慮場景,電話溝通和頁面載入就是同步,郵件溝通和升級下載就是非同步。

所以在實際互動設計過程中,我們需要找開發確認介面呼叫方式的底層邏輯,對於無需或者不能即時響應的工作考慮採用非同步呼叫的互動設計方式。

2. 抽象思維

抽象思維看似與設計思維相沖突,一個是需要抽離高層次共性,考慮程式碼的可擴充套件性;一個是需要深入場景,精準的傳遞資訊。實際上在設計中也有經常使用抽象思維,例如為了提高生產效率,我們會設計對應的元件庫,提取常用的基礎控制元件,普遍應用於各種產品。

我認為大多數情況下,我們是將抽象思維逆向使用的。

相同的元件,因為其功能是固定的,在大多數情況下都可以複用,但在一些特殊的場景,我們可以發散思維,設計出更多符合場景的元件樣式,從而傳達更具象的內容。

比如簡單的載入,比較大眾的設計樣式就是轉菊花,這種載入可以應用到任何載入場景,常見得會讓使用者感覺很low,沒有任何辨識度。

在實際設計中,我們是可以結合產品特性或品牌形象將其例項化或者內涵化,例如,B站載入樣式,融合了品牌LOGO,將品牌基因也融入到簡單的載入設計之中,加強使用者對於產品的印象及幫助品牌傳播。

這種以抽象出來的類為出發點,逆向運用抽象思維,再結合自身的設計思維去發散,最後收斂得出一個有效的問題解決方案,也能很好的服務於我們的設計。

3. 結構化思維

人類很早以前就認識到,大腦會自動將發現的所有事物以某種秩序組織起來。基本上,大腦會認為同時發生的任何事物之間都存在某種聯絡,並且會將這些事物以某種邏輯模式組織起來。

比如,透過對下圖的觀察,你可以看到什麼?

任何人,看到上面的8個方塊,都會認為共有兩組方塊,每組4個。這是因為人類大腦天性所致,大腦會認為同時發生的任何事物之間都存在某種聯絡,並且會將事物按某種邏輯模式組織起來。這種“聯絡”指的是某種類似的共同點或所處的位置比較接近。

這種將事物組成邏輯單元無疑具有很大的作用。我們更容易記住那些具有邏輯關係的東西,而遺忘那些散點的東西。

其實以上的結構化思維方式也就是設計中的格式塔原理。

為了更好的理解結構化思維的應用,我們可以以做簡歷設計為例,簡歷製作其實就是把個人相關的資訊整理成結構化資訊的過程。

每個人的簡歷上大致會包含姓名、性別、民族、籍貫、出生年月、聯絡方式、電子郵箱、工作單位、工作時間、職位、工作職責、離職原因、畢業院校、學習時間、所學專業、獲得證書等資訊。

這麼多資訊,如果不加整理的一一羅列,會顯得非常繁雜,可讀性非常差。

我們可以將這些資訊按一定的邏輯關係整理分組,讀起來就會輕鬆很多。將資訊進行結構化梳理後,會更清晰、更有條理。資訊的傳遞效率也會大大提高。

最後,無論是產品思維、設計思維,還是程式設計師思維,不應該成為職業的邊界限制,亦或是不同職位間爭議的起點。我們可以相互學習與瞭解不同的思維方式,共同更好地服務於產品。

作者:WOWdesign,研究設計價值最大化,涉及使用者體驗、品牌體驗、空間體驗。

本文由 @WOWdesign 原創釋出於人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基於 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。