在做1.0版App時(shí)，項目組為了控制成本、盡快達成里程碑，往往是功能開(kāi)發(fā)的優(yōu)先級較高，體驗的優(yōu)先級相對較低。如果PM的經(jīng)驗不足，一味做功能、趕進(jìn)度，很容易忽略App全局的一些體驗設計，給項目后期迭代挖坑；另一方面，如果沒(méi)有對這些基礎體驗進(jìn)行考慮，研發(fā)人員在開(kāi)發(fā)過(guò)程中會(huì )經(jīng)常提出疑問(wèn)，在一問(wèn)一答甚至是返工修改的過(guò)程中反而降低了效率，延長(cháng)了項目的周期。
本汪曾經(jīng)在兩天內畫(huà)出2個(gè)1.0版App的原型并寫(xiě)出需求，總體體會(huì )是設計功能簡(jiǎn)單的初期版本是容易的，難點(diǎn)在于如何在工期緊張的條件下保證App的整體體驗。
這篇文章是根據我過(guò)去幾年做工具類(lèi)App經(jīng)驗展開(kāi)的，講的是搭建App 1.0版時(shí)需要做好的全局設計，內容很基礎，分享給經(jīng)驗較淺的PM同行，老司機可直接繞行。
（以下僅以iOS的交互設計舉例，安卓的設計根據material design的原則轉化即可，再或者和iOS共用一套設計也無(wú)妨）
一、錯誤提示
大家都知道，越是復制的業(yè)務(wù)，在系統運行過(guò)程中出錯的情況就越多。出于對用戶(hù)體驗的考慮，我們不能把所有的錯誤都告訴用戶(hù)。即使是必須告訴用戶(hù)的，也應該盡量使錯誤看起來(lái)友好一點(diǎn)。除了業(yè)務(wù)方面的錯誤外，移動(dòng)端通常只需要給用戶(hù)兩類(lèi)錯誤——網(wǎng)絡(luò )錯誤和服務(wù)器錯誤?？赡軙?huì )有些同學(xué)認為多數用戶(hù)不理解何為服務(wù)器錯誤，而且在成熟的公司和項目上，服務(wù)器出錯導致前端無(wú)法訪(fǎng)問(wèn)的情況并不多，所以干脆連這類(lèi)報錯都省了。但是我個(gè)人認為還是應該區分開(kāi)的，因為一旦有用戶(hù)、運營(yíng)或者客服反饋時(shí)就能快速定位到是哪一類(lèi)錯誤。
網(wǎng)絡(luò )錯誤和服務(wù)器錯誤在操作過(guò)程中又區分為加載整頁(yè)時(shí)報錯、局部加載時(shí)報錯和點(diǎn)擊按鈕時(shí)報錯。第一個(gè)和第三個(gè)好理解，第二個(gè)（局部加載報錯）主要指的是上拉頁(yè)面加載更多時(shí)的錯誤。整頁(yè)加載出錯一般需要有單獨的提示頁(yè)面，局部加載報錯和點(diǎn)擊按鈕請求服務(wù)時(shí)出錯一般給個(gè)toast提示或者彈窗提示即可。
二、空頁(yè)面
在操作App的過(guò)程中，不可避免會(huì )遇到頁(yè)面內沒(méi)有數據或者頁(yè)面出錯的情況。這時(shí)候需要在頁(yè)面內顯示出空狀態(tài)，告訴用戶(hù)為什么出現這種情況、下一步需要做什么?？諣顟B(tài)也分整頁(yè)為空、局部為空兩種類(lèi)型，除了出現的位置不同外，在處理方式上可以采取一樣的辦法。
空狀態(tài)提示一般是圖片、提示標題、提示文案和操作按鈕的組合。如何根據實(shí)際需要進(jìn)行搭配，最好在第一版時(shí)就確定下來(lái)。雖然到了后期也能添加新的版式設計，但是對于開(kāi)發(fā)人員來(lái)說(shuō)，有可能前期就做了幾個(gè)通用的版式，如果要臨時(shí)添加就要看你的人品和RD是否積極配合了。常見(jiàn)的有以下幾種情況：
三、頁(yè)面內刷新/加載
如果頁(yè)面內容較少，可以一次性全部加載完；內容多的情況下，需要做分頁(yè)，則分頁(yè)內需要定義好每次加載多少條數據。頁(yè)面整體加載通常在頁(yè)面中部使用動(dòng)畫(huà)+提示文案，下拉刷新、上拉加載更多則在頁(yè)面頂部和底部添加相關(guān)提示。當滑動(dòng)頁(yè)面到了底部沒(méi)有更多時(shí)還也可以再增加一個(gè)提示，典型的如支付寶的“我是有底線(xiàn)的”。此外，現在有很多App都在加載中使用帶品牌標識的gif圖，這在第一版App中可以暫時(shí)不考慮，只要設計了全局加載并讓RD做了開(kāi)發(fā)，圖片可以等到后期再替換。
四、切換頁(yè)面的刷新/加載原則
頁(yè)面的整體刷新會(huì )影響錨點(diǎn)發(fā)揮作用。例如，用戶(hù)拖動(dòng)頁(yè)面中的列表，到了中部的某個(gè)位置，此時(shí)用戶(hù)切換到其它頁(yè)面然后再回到原來(lái)的頁(yè)面，如果頁(yè)面刷新了就會(huì )回到頁(yè)面的頂部，那么用戶(hù)還得拖動(dòng)頁(yè)面才能接著(zhù)看列表中的內容。在一些情況下，這種體驗是非常不好的。所以需要定義好各個(gè)頁(yè)面直接跳轉時(shí)刷新還是不刷新。下面給出一個(gè)參考思路，可以應用到整個(gè)App的所有頁(yè)面，也可以具體問(wèn)題具體分析。
五、彈窗
在A(yíng)pp中，彈窗樣式也是可以復用的。有經(jīng)驗的客戶(hù)端RD會(huì )把彈窗做成global，這樣一旦需要在大版本迭代中對彈窗UI樣式進(jìn)行修改時(shí)，只改動(dòng)global里的設計就能完成App里大部分的彈窗樣式。所以基于這點(diǎn)考慮，在1.0版本時(shí)可以把后期可能會(huì )用到的所有彈窗樣式都列舉出來(lái)給RD。各種樣式說(shuō)到底是圖片、標題、說(shuō)明文案、輸入交互和按鈕的組合。常見(jiàn)的彈窗樣式見(jiàn)下方，其中沒(méi)有交互（輸入項）的dialog會(huì )在A(yíng)pp中占大頭，其余的也可以讓RD在項目過(guò)程中遇到時(shí)再做特殊處理。
六、操作面板
屏幕底部彈出的操作面板本質(zhì)上是另一種彈窗，事實(shí)上有很多同樣的功能在不同的App上有用彈窗實(shí)現的也有用操作面板實(shí)現的（至于從開(kāi)發(fā)的角度看是否一樣，本汪就不知道了）。這里且不說(shuō)復制的操作面板——因為一旦功能復雜肯定是要做特殊處理的——就說(shuō)最常見(jiàn)的多選功能的操作面板，樣式如下。需要注意的是，帶有說(shuō)明標題和不帶說(shuō)明標題的面板對于RD來(lái)說(shuō)是兩個(gè)組件，需要做區分處理。
七、升級引導
最后說(shuō)說(shuō)App的升級引導。項目組辛苦做出App，第一個(gè)版本發(fā)布后用戶(hù)量上去了，但是在后臺看到各種吐槽。這時(shí)急忙迭代開(kāi)發(fā)出第二個(gè)版本，卻發(fā)現第一個(gè)版本沒(méi)有做升級引導——頓時(shí)奔潰有木有啊。所以本汪建議，但凡是要發(fā)布，那就必須有升級的機制，否則客戶(hù)不更新PM、RD哭死也沒(méi)用。升級無(wú)非分為強制升級和可選升級兩種。對于安卓來(lái)說(shuō)，因為各個(gè)市場(chǎng)放得較松，所以可以在發(fā)布新版本時(shí)由App直接先把apk下載到本地（一般是在wifi環(huán)境下），然后再詢(xún)問(wèn)客戶(hù)是否要升級；也可以先詢(xún)問(wèn)然后再由客戶(hù)決定是否下載。蘋(píng)果App Store大家懂得，對開(kāi)發(fā)者的約束較強，不允許開(kāi)發(fā)者引導用戶(hù)下載更新。所以如果直接把升級提示的邏輯卸載ipa包里，并且審核時(shí)被掃描到，蘋(píng)果是不會(huì )允許上架的。所以只能通過(guò)后臺控制繞過(guò)這個(gè)坑：
- 升級提示邏輯不能寫(xiě)在本地；
- 先發(fā)包審核，通過(guò)審核后再由服務(wù)端控制，在客戶(hù)端彈窗引導升級。
八、其它
以上所述的基本上都是產(chǎn)品設計層面的基礎搭建。除了這些之外還有緩存機制、crash收集、日志記錄、定位機制、消息推送、埋點(diǎn)等需要考慮，以上每一項單拿出來(lái)都可以寫(xiě)很多，此處不展開(kāi)，以后視了解的深度情況再分享。
來(lái)源：人人都是產(chǎn)品經(jīng)理，成都軟件開(kāi)發(fā)，APP開(kāi)發(fā)公司
