0755-26913476
您的當前位置:主頁 > 經驗交流 > 用戶體驗 >

1.0版App如何做全局產品設計

時間:2018-01-23

    在做1.0版APP時,項目組為了控制成本,盡快達成里程碑,往往功能開發的優先級較高,體驗的優先級相對較低。如果PM經驗不足,一味做功能,趕進度,很容易忽略APP全局的一些體驗設計,給項目后期迭代挖坑;另一方面,如果沒有對這些基礎體驗進行考慮,研發人員在開發過程中會經常提出疑問,在一問一答甚至是返工修改的過程中反而降低了效率,延長了項目的周期。

    本汪曾經在兩天 內畫出2個1.0版APP的原型并寫出需求,總體體會是設計功能簡單的初期版本是容易的,難點在于如何在工期緊張的條件下保證APP的整體體驗。

    這篇文章是根據我過去幾年做工具類APP經驗展開的,講的是搭建APP,1.0版時需要做好的全局設計,內容很基礎,分享給經驗淺薄的PM同行,老司機可直接繞行。

一、錯誤提示

    大家都知道,越是復雜的業務,在系統運行過程中出錯的情況就越多。出于對用戶體驗的考慮,我們不能把所有的錯誤都告訴用戶。即便是必須告訴用戶的,也應該盡量使錯誤看起來友好一點。除了業務方面的錯誤外,移動端通常只需要給用戶兩類錯誤--網絡錯誤和服務器錯誤??赡苡行┩瑢W認為多數用戶不理解何為服務器錯誤,而且在成熟的公司和項目上,服務器出錯導致前端無法訪問的情況并不多,所以干錯連這類報錯都省了。但是我個人認為還是應該區分開的,因為一旦有用戶,運營或者客服反饋時就能快速定位到哪一類錯誤。

    網絡錯誤和服務器錯誤在操作過程中又區分為加載整頁時報錯,局部加載時報錯和點擊按鈕時報錯。第一個和第三個好理解,第二個(局部加載時報錯)主要指的是 上拉頁面加載更多時的錯誤。整頁加載出錯一般需要有單獨的提示頁面,局部加載報錯和點擊按鈕請求服務時出錯一般給個toast提示或彈窗提示即可。

 

二、空頁面

    在操作APP過程中,難免會遇到頁面內沒有數據或頁面出錯的情況。這時候需要在頁面內顯示出空狀態,告訴用戶為什么出現這種情況,下一步需要做什么??諣顟B頁分整頁為空、局部為空兩種類型,除了出現的位置不同外,在處理方式上可以采取一樣的辦法。

    空狀態提示一般是圖片、提示標題、提示文案和操作按鈕的組合。如何根據實際需要進行搭配,最好在第一版時就確定下來。雖然到了后期能添加新的版式設計,但對于開發人員來說,有可能前期就做了幾個通用版式,如果要臨時添加就要看你的人品和RD是否積極配合了。常見的有以下幾種情況:

 

三、頁面內刷新/加載

    如果頁面內容較少,可以一次性全部加載完;內容多的情況下需要做分頁,則分頁內需要定義好每次加載多少條數據。頁面整體加載通常在頁面中部使用動畫+提示文案,下拉刷新、上拉加載更多則在頁面頂部和底部添加相關提示。當滑動頁面到了底部沒有更多時還頁可以增加一個提示,典型的如支付寶的“我是有底線的”。此外,現在有很多APP都在加載中使用帶品牌標識的GIF圖,這在第一版APP中可以暫時不考慮,只要設計了全局加載并讓RD做了開發,圖片可以等到后期再替換。

 

四、切換頁面的刷新/加載原則

    頁面的整體刷新會影響錨點發揮作用。例如,用戶拖動頁面中的列表,到了中部的某個位置,此時用戶切換到其他頁面然后再回到原來的頁面,如果頁面刷新了就會回到頁面的頂部,那么用戶還得拖動頁面才能接著看列表中的內容。在一些情況下,這種體驗是非常不好的。所以許喲啊定義好哥哥頁面直接跳轉時刷新還時不刷新。下面給出一個參考思路,可以應用到整個APP的所有頁面,頁可以具體問題具體分析。

 

五、彈窗

    在APP中,彈窗樣式頁時可以復用的。有經驗的客戶端RD會把彈窗做成global,這樣一旦需要大版本迭代中隊彈窗UI樣式進行修改時,只改動global里的設計就能完成APP里大部分的彈窗樣式。所以基于這點考慮,在1.0版本時可以把后期可能會用到的所有彈窗樣式都列舉出來給RD。各種樣式說到底時圖片、標題、說明文案、輸入交互的按鈕組合。常見的彈窗樣式見下方,其中沒有交互(輸入項)的dialog會在APP中占大頭,其余的頁可以讓RD在項目過程中遇到時再做特殊處理。

 

六、操作面板

    屏幕底部彈出的操作面板本質上是另一種彈窗,事實上很多同樣的功能在不同的APP上有用彈窗實現的也有用操作面板實現的(至于從開發的角度看是否一樣,本汪就不知道了)。這里且不說復制的操作面板---因為一旦功能復雜勘定是喲啊做特殊處理的--就說最常見的多選共功能的操作面板,樣式如下。許喲啊注意的是,帶有說明標題和不帶說明標題的面板對于RD來說是兩個組件,需要做區分處理。

 

七、升級引導

    最后說說APP的升級引導。項目組辛苦做出APP,第一個版本發布后用戶量上去了,但是在后臺看到各種吐槽。這時急忙迭代開發出第二個版本,卻發現第一個版本沒有做升級引導---頓時奔潰有木有啊。所以本汪建議,但凡是要發布,那就必須有升級的機制,否則客戶不更新PM、RD哭死也沒用。升級無非分為強制升級和可選升級兩種。對于安卓來說,因為各個市場放得較松,所以可以在發布新版本時由APP直接先把apk下載到本地(一般時在wifi環境下),然后再詢問客戶是否要升級;也可以先詢問然后再由客戶決定是否下載。蘋果APP Store大家懂的,對開發者的約束較強,不允許開發者引導用戶下載更新。所以如果直接把升級提示的邏輯卸載ipa包里,并且審核時被掃描到,蘋果時不會允許上架的。所以只能通過后臺控制繞過這個坑。

    1.升級提示邏輯不能寫再本地

    2.先發包審核,通過審核后再由服務端控制,再客戶端彈窗引導升級。

 

八、其他

    以上所述的基本上都是產品設計層面的基礎搭建。除了這些之外還有緩存機制、crash收集、日志記錄、定位機制、消息推送、埋點等需要考慮,以上每一項單拿出來都可以寫很多,此處不展開,以后視了解的深度情況再分享。