長篇大論以不適合這個時代，你需要醍醐灌頂?shù)撵`感和話語，這是一篇小短文，只講一件事，希望大家有所收獲。

設(shè)計的邏輯

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

• 第一種是：如何通過手中已有的資源和條件整合并能夠互相印證為自己的設(shè)計鋪墊。
• 第二種是：如何以用戶為中心，非常細(xì)致的將效果完整落地。

設(shè)計，非常像我們以前做的數(shù)學(xué)題，唯一不同的是設(shè)計沒有唯一答案。

在做數(shù)學(xué)題的過程中，我們發(fā)現(xiàn)了兩種條件，已知條件和未知條件，未知條件又可以稱為推導(dǎo)條件，最后將所有推導(dǎo)條件羅列并進(jìn)行再次整合加工，即可得到答案。

但是我們會發(fā)現(xiàn)：為什么我們所做的設(shè)計總是存在明顯的錯誤，甚至無法經(jīng)得起追問。

原因在這里：在做設(shè)計時，腦海中往往出現(xiàn)了很多已知條件，顏色為xxx，寬度為xxx，此信息優(yōu)先級為高等等。但是很多細(xì)節(jié)無法通過單一的已知條件得出推導(dǎo)條件，或者說我們的已知信息太少。這里的已知信息包括：規(guī)范、色彩排版、心理學(xué)、用戶畫像、業(yè)務(wù)訴求、用戶訴求、開發(fā)技術(shù)等等。

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

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

總結(jié)

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

什么是加載？

加載在互聯(lián)網(wǎng)環(huán)境中可以理解為等待數(shù)據(jù)呈現(xiàn)的過程，也是一種反饋的狀態(tài)。當(dāng)用戶對媒介進(jìn)行交互行為之后觸發(fā)的一種等待反饋。

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

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

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

但實(shí)際上，用戶在出發(fā)事件到最后看到呈現(xiàn)的內(nèi)容這一段時間都是在等待，也就是在等待加載完成。而客戶端和服務(wù)端的數(shù)據(jù)交互，都需要一定的時間來完成。

數(shù)據(jù)的發(fā)送和接受取決于網(wǎng)絡(luò)的好差，數(shù)據(jù)的查找和整合取決于服務(wù)端的性能和容量，最后呈現(xiàn)給用戶的渲染取決于客戶端的性能，高端手機(jī)和低端手機(jī)在顯示內(nèi)容的質(zhì)量及快慢都有不同的差距。

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

加載的類型和使用場景

1. 模態(tài)加載

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

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

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

2. 非模態(tài)加載

非模態(tài)加載相對來說就友好很多了，采用非模態(tài)加載，能夠在用戶等待獲取數(shù)據(jù)的同時，允許用戶對當(dāng)前頁面其他的內(nèi)容進(jìn)行操作。

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

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

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

1. 先加載文字等較小的資源，再加載圖片、視頻等較大的資源。
2. 根據(jù)用戶的瀏覽行為來逐漸加載內(nèi)容，當(dāng)用戶瀏覽到該區(qū)域再進(jìn)行加載。
3. 當(dāng)用戶的行為滿足某些條件之后再進(jìn)行加載。

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

（2）預(yù)加載

我們發(fā)現(xiàn)懶加載還是不能滿足用戶的需求，當(dāng)用戶瀏覽未加載的內(nèi)容時依然要等待。所以這里又出現(xiàn)了一個加載方式-預(yù)加載。

預(yù)加載可以理解為當(dāng)用戶在瀏覽內(nèi)容A的時候，系統(tǒng)預(yù)先判斷他接下來會進(jìn)行的操作行為，并對這部分內(nèi)容進(jìn)行提前的請求。他并不能解決網(wǎng)絡(luò)請求緩慢的問題，而只是提前發(fā)起網(wǎng)絡(luò)請求，緩解問題。

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

但是列表預(yù)加載嚴(yán)格上來說不屬于預(yù)加載，只是當(dāng)用戶滑動頁面到一定條件觸發(fā)了下一部分內(nèi)容的加載。

（3）智能加載

在不同網(wǎng)絡(luò)環(huán)境下，某些客戶端會采用加載不同的資源，不同的渲染效果來給用戶進(jìn)行視覺呈現(xiàn)，例如：在4g網(wǎng)絡(luò)下用戶瀏覽視頻，會默認(rèn)采用質(zhì)量最低的視頻資源提供給用戶。另外在wifi環(huán)境下客戶端會自動加載后續(xù)內(nèi)容。

總結(jié)

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

＃專欄作家＃

Yjjj，人人都是產(chǎn)品經(jīng)理專欄作家，公眾號：應(yīng)謀鬼計（shejishiyj）

本文由 @Yjjj 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖作者提供