設計的邏輯

商業設計始終是用來解決設計的一個過程，我們在設計過程中，首先會想到色彩與排版，往往忽視了背后信息呈現的邏輯。

• 第一種是：如何通過手中已有的資源和條件整合并能夠互相印證為自己的設計鋪墊。

• 第二種是：如何以用戶為中心，非常細致的將效果完整落地。

設計，非常像我們以前做的數學題，唯一不同的是設計沒有唯一答案。

在做數學題的過程中，我們發現了兩種條件，已知條件和未知條件，未知條件又可以稱為推導條件，最后將所有推導條件羅列并進行再次整合加工，即可得到答案。

但是我們會發現：為什么我們所做的設計總是存在明顯的錯誤，甚至無法經得起追問。

原因在這里：在做設計時，腦海中往往出現了很多已知條件，顏色為xxx，寬度為xxx，此信息優先級為高等等。但是很多細節無法通過單一的已知條件得出推導條件，或者說我們的已知信息太少。這里的已知信息包括：規范、色彩排版、心理學、用戶畫像、業務訴求、用戶訴求、開發技術等等。

可想而知，如此復雜的“已知”條件都還沒有完全歸納，如何得出最后的推導條件呢？其實每個人的邏輯能力并不相差太大，只不過很多人不夠細心，這就導致了已知條件越缺失，推導條件差距越大，最終方案的準確度也就想差的越大。

推導也是一個平衡的過程，一個在多方角色轉換的過程，提前考慮他人的假設才能更游刃有余。當方案最終產出之后，設計師依然需要對方案的落地更盡心盡力，真正的流程還未走完，完整產品邏輯，才能最終服務用戶。

總結

設計師的邏輯來源于對已知信息的整理歸納，以及對未知信息的洞察及推導，當我們能夠多角度，多層次看待一個設計的時候，我們就能做出更加精準的設計。

什么是加載？

加載在互聯網環境中可以理解為等待數據呈現的過程，也是一種反饋的狀態。當用戶對媒介進行交互行為之后觸發的一種等待反饋。

換個說法：你去飯店點菜，等待后廚上菜的過程，就是加載。

我們再以圖示幫助大家更好的理解，數據是如何通過一些列復雜的流轉最終呈現給用戶的。用戶在客戶端中進行操作，觸發一個事件，例如：點擊外賣商品列表。然后客戶端向服務端發送一個信號：“用戶要一只烤雞、一只燒鵝、一盤豬大腸”。

這時服務端收到了這個信號，并開始尋找材料（數據），對材料進行烹飪（整理數據打包）。再之后服務端需要對最后的成果進行擺盤（美化／渲染），最終送到用戶的手中。

但實際上，用戶在出發事件到最后看到呈現的內容這一段時間都是在等待，也就是在等待加載完成。而客戶端和服務端的數據交互，都需要一定的時間來完成。

數據的發送和接受取決于網絡的好差，數據的查找和整合取決于服務端的性能和容量，最后呈現給用戶的渲染取決于客戶端的性能，高端手機和低端手機在顯示內容的質量及快慢都有不同的差距。

所以，我們希望能減少用戶等待的時間，對每個步驟進行優化，針對數據信息類型的不同采取不同的加載方式，以滿足用戶的心里預期和更好的體驗。

加載的類型和使用場景

1. 模態加載

模態加載比較暴力，當用戶出發事件后模態加載將會獨占客戶端。意思就是：我正在幫你做菜，并且我要全部做完才能給你，這時你只能等待。這種體驗并不是很好，如果數據相當龐大，那么大部分用戶會失去耐心。除非是不完整加載出來就會導致嚴重失誤的場景，否則盡量不使用模態加載。

當我們需要一起讓用戶顯示但是減少用戶內容焦慮的時候，我們通常會采用占位圖布局預先加載的展示樣式，以及情感化動效／插畫。

例如：豆瓣，在點擊首頁列表中的內容后跳轉到詳情，此時由于數據還未返回，他使用了一張資源較小的圖片來展示給用戶，告訴了用戶即將加載出來的信息大致的布局和輪廓，讓用戶提前有心理預期。但是需要注意的是：如果該頁面會有多種變化時就不要用該方法。

2. 非模態加載

非模態加載相對來說就友好很多了，采用非模態加載，能夠在用戶等待獲取數據的同時，允許用戶對當前頁面其他的內容進行操作。

（1）分步加載（懶加載／分頁加載）

懶加載是我們通常會使用到的加載，舉個例子：用戶點完餐之后，通常所有菜一起烹飪完再交給用戶需要 10 分鐘，但是一般飯館都是做一道菜就交給了用戶，這樣不會使用戶等待時間太久而產生負面情緒或流失。

所以，懶加載通常還會有以下幾種不同的選擇方式：

• 先加載文字等較小的資源，再加載圖片、視頻等較大的資源。

• 根據用戶的瀏覽行為來逐漸加載內容，當用戶瀏覽到該區域再進行加載。

• 當用戶的行為滿足某些條件之后再進行加載。

所以這樣加載的好處就是減少用戶的等待時間，以及提高信息渲染的效率。分頁加載可以理解為當前獲取到 100 條數據，但是將 100 條數據分別拆成 5 頁每頁 20 條數據提供給用戶，這樣也可以讓用戶減少等待時間。

（2）預加載

我們發現懶加載還是不能滿足用戶的需求，當用戶瀏覽未加載的內容時依然要等待。所以這里又出現了一個加載方式-預加載。

預加載可以理解為當用戶在瀏覽內容A的時候，系統預先判斷他接下來會進行的操作行為，并對這部分內容進行提前的請求。他并不能解決網絡請求緩慢的問題，而只是提前發起網絡請求，緩解問題。

但是預加載的邏輯會更加復雜，比如：如何判斷何時進行預加載，以及預加載呈現的時間。需要考慮用戶在當前頁面的核心場景考慮使用不同的加載方式。例如：咨詢類app，會在用戶瀏覽資訊列表時，對當前或者某一部分列表的詳情內容進行文字加載，以及判斷列表頁面滾動的占比來觸發接下來內容的機制。

但是列表預加載嚴格上來說不屬于預加載，只是當用戶滑動頁面到一定條件觸發了下一部分內容的加載。

（3）智能加載

在不同網絡環境下，某些客戶端會采用加載不同的資源，不同的渲染效果來給用戶進行視覺呈現，例如：在4g網絡下用戶瀏覽視頻，會默認采用質量最低的視頻資源提供給用戶。另外在wifi環境下客戶端會自動加載后續內容。

總結

加載的方式多種多樣，但是我們在選擇使用時，需要考慮用戶具體的場景而定，所有加載方式都有其優缺點，并沒有最優的方式。一旦選對了合適的加載方式以及優化加載的過程之后，用戶體驗必定會有所提升。