談談小程式產品設計規範

編輯導語:如今微信小程式已經用的非常頻繁了,很多平臺也都開展了小程式板塊,小程式在一定程度上給使用者帶來了很多便利;對於小程式的設計,也一定要注意規範問題,以免使用者體驗不好;本文作者分享了關於小程式產品的設計規範,我們一起來了解一下。

談談小程式產品設計規範

無論從小程式上線時間上還是使用者規模上,小程式都不算是一個新的物種,但依然要秉著使用者最少的學習成本來達成產品目標;近期體驗過程中發現部分產品並沒有發揮小程式應有的特性和能力,也有部分產品把小程式當App一樣進行產品設計;給使用者帶來不友好的體驗,提煉了幾個出現頻率較高的事項和大家分享。

一、關於“新增到我的小程式”
談談小程式產品設計規範

(資料來自阿拉丁統計平臺)

在2020年小程式入口流量排行榜中排在Top1的就是微信訊息下拉入口,流量佔比達到21.54%,該場景值非常依賴使用者長期開啟形成倒序排在最近使用小程式列表前列,或者使用者曾經做過“新增到我的小程式”的操作;目前大多數使用者具備“新增到我的小程式”意識,但多數需要在恰當的場景下給予不一樣的引導方式。

1. 引導方式分為“氣泡引導”和“蒙層引導”
談談小程式產品設計規範

氣泡引導是一種較為輕量級引導,展現形式指向小程式膠囊的選單入口,氣泡引導優勢在於不會打斷使用者行為,它應在一定時間(建議5s)內自動消失,或提供關閉按鈕由使用者手動關閉。

蒙層引導偏強制性引導,優勢在於拆解新增步驟,流程較為清晰。缺點也在於蒙層引導能使使用者注意力聚焦在引導上,此時原頁面功能均無法使用;考慮到它會打斷使用者的任務路徑和沉浸式體驗,引導次數不宜過多,且在恰當的時機再進行引導。

2. 注意事項

不宜出現疊加引導,即同時出現2種引導,顯得冗餘且會干擾,根據使用者屬性和偏好選擇恰當的引導方式或者在不同場景下出現不同引導。

勿利用激勵進行誘導引導,從使用者價值導向來看,透過誘導產生的新增在後續產生的使用者價值是微乎其微的,因為是衝著獎勵/獎品來,而不是小程式本身提供的服務;除非是面向KPI來做產品和運營。同時也違反了小程式運營規範,遇到基本一個舉報一個準。

不宜多次重複引導,對於已經新增後的使用者引導氣泡/蒙層再次進來無需提示,目前無法監聽使用者是否做過“新增到我的小程式”;但可以從開啟小程式的場景值中去判斷,即從微信下拉或發現-小程式-我的小程式中開啟可判斷引導新增不予提示,減少無關頁面元素避免對使用者產生干擾。

二、關於授權

使用者授權的成功與否,一定會影響後續使用者行為和產品提供服務質量,好的授權方式應該是很自然且充分尊重使用者知情權與操作權的基礎之上進行授權引導,從授權類別上小程式總體可分為“賬號登入授權”和“其它服務授權”

1. 登入授權

大多數業務都需要登入後才能感受到小程式實際價值,整體核心業務流程漏斗上,讓使用者登入成功是第一個漏斗,現在小程式提供的登入能力很強大,所以流程很簡單,但觸發和互動方式不容輕視。

登入授權觸發機制均為使用者自主觸發,觸發方式大體分為“全功能”觸發和“區域性功能模組”觸發。

全功能觸發即小程式頁面中的所有內容均需要登入才能瀏覽/操作,區域性功能模組觸發即小程式頁面中的部分內容模組,需要登入才能瀏覽/操作。

針對“全域性功能”觸發建議以傳遞小程式價值為主進行引導授權,比如登入後可使用訂閱服務,釋出資訊服務等小程式特性或功能點羅列。

針對“區域性功能模組”觸發建議以傳遞該模組功能價值進行引導授權,如登入後可評論,登入後可檢視我的收藏;與“全域性功能”觸發授權不一樣的是, “區域性功能模組”觸發的授權,可以由不同頁面模組來傳遞不一樣的價值來引導授權登入。

2. 授權形式

授權形式大體分為兩種,一種是“頁面內”觸發授權,另一種是跳轉至授權中間頁授權。

談談小程式產品設計規範

“頁面內”觸發授權按鈕,只需要一步就觸發授權請求,比較合適於“區域性功能模組”觸發的授權形式。

跳轉至授權中間頁統一多場景的登入體驗,更大設計空間,比較合適於“全域性功能”觸發的授權形式。

3. 其它能力授權

其它能力授權包含常見的地理位置、相機、相簿等能力, 這類授權機制推薦使用者自主觸發授權;雖然可以做成自動觸發授權,大多數使用者對這些授權都非常敏感,只有在真正需要使用授權介面時,才向用戶發起授權申請,並在授權申請中說明清楚要使用該功能的理由。

授權透過率可能才有保障。一旦使用者明確同意或拒絕過授權,其授權關係會記錄在後臺,直到使用者主動刪除小程式。

談談小程式產品設計規範

使用者可以手動在小程式設定介面(右上角- 關於- 設定)中控制對該小程式的授權狀態,這路徑其實有點長;如果判斷拒絕授權時,可以呼叫 wx.openSetting 一步跳轉開啟許可權設定介面,引導使用者開啟授權。

4. 注意事項

請勿在使用者預期外彈出授權,比如切換底部tabr彈出登入授權,對使用者感到,即使該tab部分內容模組需要登入才能瀏覽/操作,也可讓使用者進入到該tab頁面中,進行引導授權,充分尊重使用者知情權與操作權的基礎之上進行授權引導。

不宜過於強制的引導,比如授權引導固定懸浮在底部,授權彈窗無法關閉,頻繁彈出授權等,會破壞使用者的原生體驗,只解決了“使用者該怎麼授權”並沒有解決“使用者為什麼要授權”的問題。

三、關於使用體驗

如微信小程式設計規範所說,一旦使用者進入我們的小程式頁面,我們就有責任和義務清晰明確地告知使用者身在何處、又可以往何處去;確保使用者在頁面中游刃有餘地穿梭而不迷路,這樣才能為使用者提供安全且愉悅的使用體驗。

1. 標準導航欄

標準導航欄標題具有可讀性高以及和頁面內容高匹配度,導航需要告訴使用者,當前在哪,可以去哪,標題長度保證主流機型能夠展示全;如果標題展示不全容易產生資訊丟失,理解有障礙;比如微信小程式示例二級面顯示的是具體元件名稱,而不是“元件詳情”。

談談小程式產品設計規範
2. 自定義導航欄

當使用自定義導航時,因注意頁面內容是否與小程式膠囊有重疊,小程式膠囊每個頁面的位置都是固定的,不可隱藏也不可調整位置。

3. 統一穩定性

不管從小程式上線時間上還是使用者規模上,小程式都不算是一個新的物種,但依然要秉著使用者最少的學習成本來達成目標,對話方塊作為最常見的互動元件之一;發現很多小程式只會使用dialog(對話方塊)或自定義一個dialog(對話方塊),稍微熟悉小程式元件的同學可能都知道還有一個叫half-screen-dialog(半屏彈窗)。

在half-screen-dialog出來前,包含微信在內,相關授權一直都是用dialog元件來進行授權,在half-screen-dialog出來後,不管是手機號碼授權還是地理位置授權都是用half-screen-dialog元件,這意味著half-screen-dialog比dialog更適用於授權方面。

談談小程式產品設計規範

其實不僅僅在授權方面,在整個互動反饋傳遞資訊上,dialog確實很有侷限性,一旦內容多顯得密度很高,沒有層次感,而half-screen-dialog很好的解決了這方面問題;但dialog也有自己的優勢,就是提示文字比較少的時候合適使用,比如“是否要刪除該圖片”,言簡意賅的提示用dialog是最佳選擇,此時用half-screen-dialog就顯得非常冗餘。

總之在元件方面,最理想的情況下是標準化,一能令使用者使用感知更加統一,二能達到降本增效的結果,使用微信提供的元件對頁面效能的提高有極大作用,無形之中提升了使用者體驗。

整體小程式迭代週期還是以周為單位進行更新,本文有較強實時性,更多最新知識需要大家及時洞察和探索。

#專欄作家#

動物園園長,微信公眾號:首席吹牛官,人人都是產品經理專欄作家。網際網路圈十八線作詞人,國家一級退堂鼓表演藝術家。顏良而文丑,歡迎交流。

本文原創釋出於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議

版權宣告:本文源自 網路, 於,由 楠木軒 整理釋出,共 3097 字。

轉載請註明: 談談小程式產品設計規範 - 楠木軒