"APP設計,這5件事千萬不能忘"

文章總結了APP設計中容易忽略的幾個問題,並分享了相關方法。希望給大家帶來些啟發。

我剛開始工作時經常遇到這種情況,拿到一個需求感覺很容易,刷刷刷弄出好幾個方案。然而方向確定後,才是問題的開始。

每一個頁面都會有一些相差不多“配件”,例如字段、提示、模塊、按鈕等。因為他們都太過基礎了,以至於很容易被我們忽視,直到……同時維護近百個頁面時,初步進入開發階段時,才被開發問起:

  • “XX部分的設計怎麼在不同頁面不一樣啊?”
  • “XX的規範有嗎?”
  • “XX的設計在特殊狀態可能會出問題……”

這裡我總結一下自己踩過的坑,希望大家在設計產品時不要和以前的我一樣,把這些東西拖到最後才解決。因為欠債不還只會利滾利,最基本的東西反倒是最麻煩的。

一、時間戳

我不得不摸著自己的良心承認,時間戳這個坑,我做設計這麼多年來還沒有爬出。不單我沒有爬出,我見過的所有設計團隊都很少有能避開且輕鬆解決的。真是印證那句老話,“看不出問題的問題才是最大的問題“(我瞎編的)。

這東西有多難搞,看我之前的原創文章就知道了,這是當時的各家產品的時間戳規範:

總的來說,時間戳的規範需要考慮以下三點:

1. 用什麼日期分隔符?

比較常見的有YYYY年MM月DD日、YYYY.MM.DD、YYYY/MM/DD和YYYY-MM-DD。需要註意的是,YYYY-MM-DD在時間區間的表達上會有問題,例如“YYYY-MM-DD-YYYY-MM-DD”肯定看不懂。

2. 信息具有多強的時效性?

SNS和新聞這種時效性很強的內容,對於時效期內的信息,會傾向於提供“相對時間”。例如剛剛、X分鐘前、X小時前、X天前,甚至X年前。

原因很明顯,人們對相對時間更加敏感。例如日常對話裡面,除非是太久遠的東西,我們通常不會說哪年幾月幾號,而是更加喜歡說剛剛、X分鐘前、X小時前、X天前,甚至X年前。

3. 精確時間有必要嗎?

數據庫里,每一條時間記錄都必須很精確,而對於人來說,卻未必如此。

例如看一年前的普通新聞時,我們可能頂多對於哪年幾月幾號的信息感興趣,而幾點幾分幾秒就是幾乎毫無意義的,寫上去還挺占地方。

而看一年前的聊天記錄時,時間信息卻又很重要。例如早上發的信息還是晚上發的信息,意義是完全不同的。

Youtube 甚至把老視頻的時間戳模糊到“X年前”,這不但給大部分用戶提供了更加簡單明瞭的信息,而且還節約了不少界面空間。

真正高明的設計,其實並一定是驚艷的概念稿。將每一個信息露出都計算到極致,才是我們那些很多讓人引起視覺疲勞的產品所缺乏的。

二、超長信息

我們在設(fē)計(jī)稿上,經常會填充一些假信息,然而這些信息通常都不會太長以至於破壞畫面美感。

然而現實情況是,尤其是像標題和描述這種東西,會有大量長度的超出範圍的情況。於是開發們自由發揮一通後,其結果就不是你能想象的了:

別說內邊框保留多少,會不會超出、要不要換行這些基本問題都要搞清楚才行。等到要測試上線才發現,可能大家都懶得改了。

三、空數據

所有的列表都可能出現空數據的情況,所以說設計方案不可或缺。

如果是整頁空白,那很好辦,一般常見的情況是一張圖配一行字。

如果是分段式列表,會出現部分為空的情況。是整段移除,還是展空位,這就需要具體情況具體分析了。

還有可能是必須有圖的地方沒有圖,也就是要提供一個默認圖片。

四、加載

雖然理想中所有頁面應該在一秒內加載出來,很多設計師甚至程序員都會高估了用戶的網絡環境。但是想想你自己平時的使用經驗,由於各種亂七八糟的問題,頁面加載三五秒是相當常見的情況。

而這幾秒甚至半分鐘的加載時間,很有可能是用戶體驗最糟糕的時候,你還不用心設計安慰安慰他們呢嗎?

方法一:看見沒在加載啦,等等吧

方法二:快出來了,喏,它會是長這樣子

方法三:看看這動畫打發一下時間吧,一不小心就到時間了

方法四:倫家可努力了,求別怪我慢!

五、異常狀態

有句話叫做不怕一萬就怕萬一,這是世界上奇怪的狀況太多了,我們設計產品時也不能至意外意外場景於不顧,何況有的異常狀態根本不算意外。

異常一:加載失敗

異常二:失效操作

異常三:提示

作者:Z Yuhan,一名前華為騰訊交互設計,在英國學習了人機交互,樂意帶你由淺入深瞭解產品體驗;公眾號:體驗進階。

本文由 @Z Yuhan 原創發佈於人人都是產品經理,未經作者許可,禁止轉載。

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

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *