黏性使用體驗:淺談 App 的通知與提醒設計

0

文/ UX四神湯 Nathan

最近 Nathan 在阿里巴巴參與的智能語音項目正式對外公佈了,正是在今年 8 月 8 號開始販售的天貓精靈 X1。

天貓精靈能聽懂華語中文的語音指令,目前已經支持透過語音,播放大量的音樂音頻內容,同時也是第一款具備中文聲紋辨識能力的智能音箱(智慧音響),實現聲紋辨識支付能力的同時,也應用到了語音購物、手機加值、叫外賣等功能。

當然除了目前所支持的技能外,也保持著每週大量新增技能的節奏正在快速成長中。

天貓精靈X1 from ChenYaoHsuan on Vimeo.

除了 2014 就開始佈局的 Amazon 以外,包含 Google、Apple、Microsoft …等,陸續在 2016~2017 年推出了自己的智慧音響產品以及開發者平台(Amazon Alexa、Google Assistant),各家互聯網巨頭可以說是在今年揭開了智慧音響的白熱戰。

因此阿里巴巴的天貓精靈 X1 除了結合目前業界的硬體、麥克風拾音、語音等技術外,也嘗試透過在語音購物以及聲紋支付技術的突破,各自做出自己的差異點。

作為剛從人工智能實驗室誕生的第一款對外商用產品,天貓精靈 X1 還有著許多的不成熟以及可以優化的地方,因此項目組也採用著高敏捷的方式,保持每兩週更新系統以及 App 的節奏。

Nathan 在這半年參與開發的過程,可以說是各種慘烈的血淚史,踩遍 IOT、A.I.、Voice 產品的各種坑,當然也收穫了許多非常寶貴的經驗以及沉澱。

由於產品的技術壁壘在短期內還是過於高,大部分的設計師與開發者很難碰觸到此類產品,開發過程中所摸索出的研究成果,都是十分寶貴的經驗。因此目前團隊也慢慢地開始以對外發佈文章、演講的方式,讓大家了解在設計此類產品時,可以參考使用的設計方法以及經驗。

相信這些內容在短時間內,還是非常有意義的資訊,可以讓設計師提前瞭解及儲備。因此 Nathan 後面也將會在四神湯中跟大家慢慢普及,設計類似 A.I. 、Voice 的產品時,可能會遇到的問題以及可以採用的設計方式。

還請期待囉~

OK, Anyway。由於目前產品還處於初期發布階段,還不能夠說明太詳細。本次文章將繼續延續上次話題,來談談提高 App 黏性使用的其他方式:設計「消息的通知與提醒」

目前市面上的智慧音響因為增加了語音的能力,因此已經能透過聲音提示的方式來與用戶互動。但使用的場景畢竟主要還是在家庭的固定空間環境,多多少少會遇到用戶不在當前場景的問題,因此許多時候智慧音響或是助手必須借助手機消息通知,來拓展受限的使用場景,幫助用戶同步當前進行的任務,以及提示後續的操作。

因此本文將說明目前的手機系統中有哪幾種消息類型,以及對應適合使用的場景。幫助大家能快速對手機的通知與提醒設計,有個初步的認識。

本文適合:(1)初進入移動端軟體設計 1~3 年的 UX/UI Designer(2)初進入移動端產品開發 1~3 年的 PM/PD (3)想知道如何打造黏性產品的 Anybody。

▲ iOS 11 Message Center Component(圖片來源:UX 四神湯)

了解不同的消息類型,適時引導、提示與警告

在使用手機應用的時候,我想每個人多少都會遇到不同類型的消息通知,尤其在剛打開 App 的時候,有些應用常常會在開頭就一連串的詢問用戶是否同意權限,很容易就造成用戶體驗的下降。

GUI 時代的應用需要提醒用戶關注某件事情的時候,由於互動方式有限,大多只能採用這種比較干擾的手段。但這些消息如果是在正確的時刻或場景出現時,帶來的反而是連接用戶以及產品的好處。

設計消息通知時,大多會配合幾種產品目標來進行:

  1. 希望引起用戶的關注
  2. 提示資訊給予用戶即時回饋
  3. 引導用戶到達正確的位置
  4. 明確用戶可以操作的選擇
  5. 重要時刻讓用戶再次確認

除了上面幾種的目標以外,其實還能再依使用場景繼續細分。而在 iOS & Android 的應用開發中,其實所提供的幾種通知與消息類型,也大多符合上面所列的幾種目標。

▲ iOS & Android 彈窗分類(圖片來源:UX 四神湯)

模態與非模態最簡單的分類依據,即是在需不需要用戶對彈窗進行互動操作。而無論是模態還是非模態彈窗,在應用中出現的時候常常會伴隨著半透明深色遮罩背景,來吸引用戶的視覺焦點突出消息彈窗本身。

模態彈窗:

會中斷用戶的當前操作行為,強制用戶必續對當下的彈窗進行回饋,否則不可以繼續其他的操作。

非模態彈窗:

不會影響用戶的當前操作,用戶可以不予回應繼續維持原先的使用,非模態彈窗通常都伴隨著時間限制,出現一段時間就會自動消失。

雖然 iOS、Android 各個原生平台所提供的系統組件有所差異,但互動方式還是大同小異的,像是 Toast 原本只支持在 Android 系統中使用,但也已經有許多開發者自己客製了類似的效果到 iOS上。

01 警告框、對話框

  • 定義:傳遞重要資訊,並明提示需要用戶進行的操作。
  • 組件規範:基礎的原生組件中,必須包含「標題」以及「按鍵」,「描述資訊」和「輸入框」為可選擇項。
  • 作用場景:大多是用在緊急或重要時刻,用戶進行重要性較高的操作,如退出、刪除、支付等類型時,進行二次確認和提醒。

▲ iOS & Android 彈窗分類(圖片來源:UX 四神湯)

▲ iOS 中的 Alerts / Dialog (圖片來源:UX 四神湯)

02 操作欄、操作列表、活動視圖

  • 定義:提供用戶進行大量的功能選擇或操作時使用,大多是輔助性質出現 ;
  • 組件規範:最基礎必須包含「退出」以及多種功能「按鍵」,「描述資訊」和其餘所需的功能都可以場景訂製 ;
  • 作用場景:主要是提供一系列可以在當前場景提供用戶幫助的功能,大多使用在文件操作、分享、多量選單等場景下使用。

▲ iOS & Android 中的 Activity Views(圖片來源:UX 四神湯)

03 浮出工作彈窗

  • 定義:用戶在當前頁面的臨時使用視圖,大多是用來延展輔助內容,或增加輔助操作的使用 ;
  • 組件規範:在較大的屏幕使用上會更合適,可以包含各種產品上所需訂製的元素 ;
  • 作用場景:主要是使用在收起屬於次級的內容,以及折疊頁面中的操作選項,避免過多的資訊息增加用戶操作的心智負擔。使用場景包含像是導航選項、工具欄、表格集合等。

▲ iOS 中的 Popover(圖片來源:UX 四神湯)

04 浮出提示彈層

  • 定義:屬於一種輕量的用戶回饋提示,幫助用戶了解以及同步當前的使用狀況 ;
  • 組件規範: 主要支持「描述資訊」以及「透出時間」,背景以及其他內容即需要訂製;
  • 作用場景:考慮到 Toast / HUD 出現時間較短(1~3秒),而且佔用當前頁面 UI 空間也不大,因此不適合用來傳遞過多的文字內容、詳細或是重要的資訊。

▲ iOS 中的 Toast/HUD(圖片來源:UX 四神湯)

雖然 Toast 最早只出現在 Android 系統中,但目前也慢慢在 iOS 中可以見到,像現在 IM 類應用中常常可以看到頂部的「你有幾條未讀」消息,就屬於 Toast 通知。

而 HUD 則是比較常看到又比較不會特別注意的提示方式,如果要簡單區分 HUD 和 Toast 的區別:

  1. HUD 只出現在螢幕的中央(成功/失敗、音量),而 Toast 則大多在底部或頂部。
  2. HUD 一般來說較常用的是毛玻璃透明、而 Toast 則没有特别頃向。
  3. HUD 中的內容可以連續變化(iOS 調節音量),但 Toast 中的內容每次都需一致。

▲ iOS11 中的 MBProgressHUD 组件(圖片來源:UX 四神湯)

使用 Toast/HUD 的好處就是佔用屏幕小,不會中斷用戶當前的操作,因此能較為輕量的融入使用過程中。但相對的缺點就是容易一閃而過,用戶容易錯過或不在意提示。

05 底部彈窗

  • 定義:原先是 Android 系統的特有互動方式,用在提供提示回饋同時,允許用戶進行輕量的操作 ,但目前某些 iOS 應用也採用了這類型的通知;
  • 組件規範:比「浮出提示彈層 Toast/HUD」多出来的,即是可進行的單一操作選項;
  • 作用場景:同樣用來回饋以及同步用戶當前的使用情形,其打擾用戶的程度大約在 Dialog 和 Toast 中間,主要是用來讓用戶進行當前場景的快捷反向操作(如撤銷、回復等)。

▲ SSSnackbar Component (圖片來源:stonesam92)

▲ SSSnackbar Component (圖片來源:stonesam92)

▲ Android Snackbar Example(圖片來源:UX 四神湯)

通過簡單的分析以及說明,可以了解這些模態以及非模態彈窗的定義,和相關的使用場景。設計師以及開發者可以結合各自的產品設計目標,來選擇正確的使用。好的消息通知設計,可以幫助你完善你的產品體驗,讓用戶能快速正確的了解你的產品。

對話式用戶體驗的重點,就是通過正確、適時的回饋和提示,一步步的讓應用和用戶雙方更了解彼此。因此正確的了解用戶使用場景,才能結合通知消息彈框,設計出滿足用戶心理需求的產品。

除了讓大家能更清楚的了解,目前 GUI 產品設計上可能會使用到的通知消息類型外,最後再簡單的介紹可以幫助應用資訊透傳,提供用戶黏性以及注意力的幾種方式。

善用小紅點,與用戶進行對話

UI 設計中常戲稱的小紅點,其實正式名稱是「微標 Badge」,通常會出現在圖標或文字右上角的紅色圓點、數字或者文字,表示有新內容或者待處理的資訊。

不可考的黑歷史是,小紅點最早被使用是出現在黑莓機中,後來被 iOS 取的專利後廣泛應用在自己的系統中,引起暴點後 Android 系統中也變為標配。

小紅點樣式以及應用場景,網路上已經有三方庫整理的很齊全,包含有「顏色」、「數字」、「文字」、「動效」和「點擊效果」等,許多效果可能看過但卻從沒注意過。

▲ Badge Animation (圖片來源:weng1250)

簡單一句話表達這種設計,最可恨也最有趣的點就是:

「 小紅點,逼死強迫症 !」

小紅點最核心的精神,最早一開始是抓住用戶避免錯失消息的心態,但在資訊社會中越來越爆炸多的資訊出現後,反而更偏向用戶喜歡統一、好奇的心態。帶有小紅點的圖標和按鈕,在一堆沒有小紅點的 icon 中顯得非常扎眼,讓人忍不著想點擊想消除它。

小紅點的設計目的就是為了提昇用戶啟動 App 的次數,提昇某個關鍵鏈路的點擊率、用戶的召回率。在 GUI 時代,對於每一個 App 而言,都是非常重視用戶的每一次啟動,哪怕是一點的停留或召回帶來的可能都是珍貴的轉化。

▲ 小红點被廣泛的應用在目前的 App 中(圖片來源:UX 四神湯)

小紅點最早的設計目的,是開發者或產品用來提醒用戶我們有了新的消息、新的升級或新的提醒,但在 App 的應用生態越來越蓬勃發展,用戶的點擊與停留時間也越來越寶貴後,現在常常能看到某些應用中充斥著大量的小紅點。

這種過度使用反而讓人生厭,反而帶來用戶直接卸載或無視的狀況。在 IM 類或有消息中心的應用中,尤其可以發現這種狀況。

▲ 叫車 APP 的 Message Center

為了用戶體驗的以及真正做到「對話」,設計小紅點時務必記得僅在重要且必須的地方加入,也避免在不必要的場景下在小紅點上附帶數字,簡單一點反而比較好。同時要確保小紅點的消失機制,符合產品的使用邏輯。

 Less is More,小紅點雖好,但還是要把握使用力度!

這次的文章是 Nathan 在整理,目前可配合智能音箱使用的手機通知與消息類型,因此偏向較為基礎的介紹內容,幫助剛進入這個領域的產品設計者,能有較為概括的認識。

具體的使用當然還是要依據各自的產品特性,以及你(妳)想打造的「產品對話體驗」了。

另外值得一提的是,iOS 的通知中心在 10 與 11 中,有個特別不一樣的差別,雖然已經一陣子了,但有興趣的或還不知道的話,建議可以看看這篇文章:〈了不起的减法:iOS 11 的通知中心与锁屏 | 具透

參考資料

  1. iOS Human Interface Guideline
  2. Google Material Design

授權來源:UX 四神湯 uxeastmeetswest〈黏性使用體驗(二)淺談 App 的通知與提醒設計〉

Share.

About Author

vide 編輯群

Leave A Reply