小白問題,如本人描述上有不適的地方,請見諒!
傳統的toc產品可以對客戶進行問卷調查,收集使用者反饋,而ToB的產品因為是直接面向B端客戶,有些b端客戶並不會也不願意花時間填問卷,那麼針對這種b端客戶,如何才能有效的收集產品反饋?
謝謝!
回覆列表
-
1 # 憤怒的developer
-
2 # 憤怒的developer
1. 操作確認常見的需要使用者進行二次確認的場景有:付款、覆蓋、退出、刪除、提交、離開、修改、替換……對於一些具有“破壞性”或不可逆的操作,在使用者操作前,我們應當讓使用者“再次確認”。2. 操作結果常見場景有:提交、新增、刪除、儲存、傳送、搜尋、查詢、下載、上傳……3. 任務程序常見場景有:刪除、匯入、查詢、上傳、下載、重新整理、安裝、更新、解除安裝……在這些場景中,可能任務不會馬上完成,系統需要有一個載入、校驗、查詢或計算的過程。4. 表單校驗:表單狀態、欄位錄入格式、長度;使用者在填寫表單後,點選“儲存”、“提交”等操作時,我們需要對使用者輸入的內容進行校驗。這樣做除了避免或減少使用者錯誤,也可以規範使用者的操作,使系統儲存的資訊可控、規範化、結構化。5. 操作暗示/提示常見場景有:指示控制元件狀態、顯示/隱藏功能、漸進式的資訊展示、操作提示……對於一些可以發生互動的頁面元素,除了在視覺上應該與靜態元素有所區別之外,在使用者滑鼠懸停時,滑鼠指標及對應的元素應當有變化,以此來告訴使用者:當前控制元件可以被執行點選、拖拽等操作的,最簡單如輸入框,在滑鼠懸停時會變變為“手形”且在獲取焦點時會變為高亮,用來告知使用者它是可用的和正在輸入狀態。
1. 操作確認常見的需要使用者進行二次確認的場景有:付款、覆蓋、退出、刪除、提交、離開、修改、替換……對於一些具有“破壞性”或不可逆的操作,在使用者操作前,我們應當讓使用者“再次確認”。2. 操作結果常見場景有:提交、新增、刪除、儲存、傳送、搜尋、查詢、下載、上傳……3. 任務程序常見場景有:刪除、匯入、查詢、上傳、下載、重新整理、安裝、更新、解除安裝……在這些場景中,可能任務不會馬上完成,系統需要有一個載入、校驗、查詢或計算的過程。4. 表單校驗:表單狀態、欄位錄入格式、長度;使用者在填寫表單後,點選“儲存”、“提交”等操作時,我們需要對使用者輸入的內容進行校驗。這樣做除了避免或減少使用者錯誤,也可以規範使用者的操作,使系統儲存的資訊可控、規範化、結構化。5. 操作暗示/提示常見場景有:指示控制元件狀態、顯示/隱藏功能、漸進式的資訊展示、操作提示……對於一些可以發生互動的頁面元素,除了在視覺上應該與靜態元素有所區別之外,在使用者滑鼠懸停時,滑鼠指標及對應的元素應當有變化,以此來告訴使用者:當前控制元件可以被執行點選、拖拽等操作的,最簡單如輸入框,在滑鼠懸停時會變變為“手形”且在獲取焦點時會變為高亮,用來告知使用者它是可用的和正在輸入狀態。