一個人對錯誤的反應(yīng)——無論是自己犯的還是他人犯的——是一個復(fù)雜且常常令人痛苦的心理過程。在本文中,我將解釋為什么幾乎所有的錯誤提示信息的設(shè)計都公然無視用戶體驗理論。我將使用交互式原型來展示如何解決這個問題。我還將轉(zhuǎn)向交互理論,回顧模式的概念,并解釋可逆性、恰當(dāng)性和及時性的原則。
我們的用戶不是程序員
每個設(shè)計師的清單里都會包含“設(shè)計錯誤界面”。但即使完成了,程序員仍然會回來說:“還有另一種情況——我們也需要一個錯誤界面。”在這種情況下,程序員是設(shè)計的客戶,這很有道理:程序員比任何人都更了解錯誤。設(shè)計師和經(jīng)理們都認(rèn)同這種方法——但它存在嚴(yán)重缺陷。
“我們不是我們的用戶。”設(shè)計師們不斷重復(fù)這句話。他們想表達(dá)的是:不要僅僅依賴自己的專業(yè)知識(這不可避免地會過時,而且容易產(chǎn)生職業(yè)偏見),而要關(guān)注用戶在自然環(huán)境中的行為。
所以,問題在于——程序員不是我們的用戶。程序員的行為、思維方式,以及與計算機的聯(lián)系與其他人截然不同。我知道我在說什么。我的大多數(shù)朋友都是程序員和工程師。我在工作中也經(jīng)常和程序員交流。我自己也是一名程序員,使用多種語言(從 Swift 和 GLSL 到 Forth 和 Assembly)。但幸運的是,我也是一名非常關(guān)注心理學(xué)的設(shè)計師。那么,讓我來告訴你程序員的一天通常是怎樣度過的:
程序員甚至還沒來得及好好寫點東西——他們停頓了一下,砰,一個錯誤出現(xiàn)了:“空白符缺失”。不知何故,下一行也出現(xiàn)了錯誤(盡管那一行完全沒問題)。左側(cè)面板也滿是錯誤。這還不算編譯錯誤。除了紅色圓圈,可能還有黃色圓圈——程序員的大腦已經(jīng)習(xí)慣了忽略這些警告。
如果錯誤來自硬件故障、第三方庫的 bug 或文檔不清晰,程序員不會把這些錯誤當(dāng)回事。他們會把這些錯誤視為一種有用的工具,幫助找出別人的錯誤。而有些煩人的拼寫錯誤,你會在自己的代碼中苦苦追尋,希望編譯器能自動捕獲它們。那么,關(guān)于拼寫錯誤的錯誤消息就是程序員最好的朋友。
簡而言之,程序員對錯誤消息產(chǎn)生了一種容忍度——所有那些帶有感嘆號的圓圈和冗長、說教的紅色文字。
心理學(xué)家會怎么說?
從人體工程學(xué)的角度來看,程序員的環(huán)境與普通用戶的環(huán)境有著根本的不同。因此,設(shè)計師絕對不應(yīng)該采用程序員對待錯誤的態(tài)度。如果我們負(fù)責(zé)設(shè)計一個 IDE(集成開發(fā)環(huán)境),那么我們當(dāng)然會咨詢程序員——他們是我們的用戶。但在開發(fā)其他產(chǎn)品時,最好不要依賴他們的觀點。相反,我們應(yīng)該 咨詢心理學(xué)家 。
紅色感嘆號會讓用戶想起老師在課堂筆記中批改的內(nèi)容,并被理解為一種懲罰(當(dāng)然,除非有人已經(jīng)培養(yǎng)了對懲罰的耐受力,比如程序員)。那么,心理學(xué)是如何看待對錯誤的懲罰的呢?
重要的是不要用消極情緒來強化錯誤,因為大腦對此非常敏感,并會將這種行為標(biāo)記為不值得投入精力的事情。
我知道有些人看到錯誤信息就會慌亂不已。他們開始點擊所有按鈕,只為讓它盡快消失。這些人很難適應(yīng)界面,因此他們傾向于完全避免與界面交互。這并不是因為他們愚蠢,而是因為他們是普通人——而不是程序員。
看看這個!幾乎每個字段都用紅墨水劃了線,界面提示你輸入姓名,并要求你填寫,而且是必填項!
但程序員對此完全沒意見。程序員堅信,把笨蛋塞進(jìn)錯誤里是有用的,這樣他們就不會再試圖用 null 或 undefined 來破壞程序了。程序員和工程師稱之為“傻瓜式防錯”,展現(xiàn)了他們獨特的同理心。
焦點切換時驗證
當(dāng)用戶從一個輸入字段切換到另一個輸入字段時,第一個字段會觸發(fā)一個名字很不靠譜的事件:“onblur”。開發(fā)者經(jīng)常用它來進(jìn)行驗證——以防用戶漏填字段、輸錯生日或忘記郵件中的“@”。問題是:當(dāng)用戶切換到另一個應(yīng)用時,“onblur”也會觸發(fā)。過去,表單跨越三頁時,空字段是個問題。如今,所有內(nèi)容都能放在一個屏幕上——很難忽略一個空字段。至于其他的檢查——它們對用戶沒有任何幫助。它們只是另一種“傻瓜式”的玩意兒。但用戶不是傻瓜。當(dāng)他們想要什么東西時——他們會發(fā)揮創(chuàng)造力。我知道有人會修改頁面代碼,以獲取他們嚴(yán)格意義上不應(yīng)該獲得的政府服務(wù)。而如今,他們甚至不需要知道如何編寫代碼:只需單擊一下即可打開 DevTools,再單擊幾下——所有驗證都消失了。輸入任何你想要的內(nèi)容。
通過像傻瓜一樣對待用戶,開發(fā)人員產(chǎn)生了兩個問題:第一 - 他們浪費時間構(gòu)建“保護(hù)”,第二 - 他們陷入了一種虛假的安全感(沒有比“通過模糊性實現(xiàn)安全”更糟糕的保護(hù))。
在焦點切換時進(jìn)行驗證毫無意義,而且問題重重,我甚至不想在這里討論它。讓我們繼續(xù)討論主按鈕上的驗證:“繼續(xù)”、“提交”等等。
通常如何做
我們與雅虎界面的交互分為三個階段:
開始。所有字段均為空。無錯誤。“繼續(xù)”按鈕可用。
按下“繼續(xù)”按鈕。所有空白字段均被標(biāo)記為錯誤。
焦點從第一個字段移開。突然間,它不再被標(biāo)記為錯誤了。
讓我們來分析一下。
激活按鈕——這很好,雅虎點贊了。我有一篇名為“ 禁用按鈕 ”的文章,解釋了這背后的理論和實踐。如果你仍然認(rèn)為禁用按鈕對用戶有幫助,那你絕對應(yīng)該讀一讀。
接下來是可逆性 原則。這意味著你可以將界面恢復(fù)到初始狀態(tài)。雅虎又贏了——你可以重置界面。但只能通過逐個點擊每個字段來實現(xiàn)。這有什么意義呢?為什么僅僅因為你移開焦點,錯誤信息就會消失?這純粹是算法故障!在我 關(guān)于設(shè)計流程的文章 中,我指出即使是頂級公司有時也會設(shè)計出糟糕的界面,所以不要盲目追隨權(quán)威。要遵循科學(xué)。
下一個原則是 恰當(dāng)性 。用戶點擊了“繼續(xù)”按鈕——交互的對象是按鈕,而不是輸入字段。如果按鈕發(fā)出某種震動或吱吱聲來表達(dá)不滿,這可以理解。但是輸入字段呢?根本沒人碰過它們!它們怎么可能感知到按鈕的情緒呢?只有程序員知道,在代碼中,這些對象是相互關(guān)聯(lián)的——但外部觀察者一無所知,因為它們之間沒有視覺聯(lián)系。
現(xiàn)在來談?wù)剷r效性 原則。設(shè)計師用紅色高亮顯示幾個字段,期望用戶做出什么反應(yīng)?如果所有字段的重要性都一樣,用戶應(yīng)該先解決哪個字段?這需要對 注意力中心 進(jìn)行復(fù)雜的討論(這里的注意力中心不是指某個具體的輸入字段,而是“出了點問題”的整體感覺),但我建議保持簡單:界面基本上就是按照“坐下-停留-過來”的順序排列,打破了“一次一個動作”的原則。
這里,一切都非常不對勁!
調(diào)試模式
界面有“模式”的概念。在我的大學(xué)里,程序員選修了一門名為“界面設(shè)計”的課程,課程內(nèi)容包括解釋為什么彈出窗口被稱為“模態(tài)窗口”。現(xiàn)在,我驚訝地發(fā)現(xiàn),程序員和設(shè)計師似乎對如何處理模式一無所知。
老式計算機有一種特殊的“HALT”模式,用于調(diào)試錯誤,也稱為“控制臺模式”。如果處理器嘗試執(zhí)行無效操作,程序?qū)⒈恢袛啵幚砥鲗⑼V惯\行,并切換到控制臺模式。您也可以通過按下物理“HALT”按鈕手動觸發(fā) HALT 中斷。使用開關(guān)或調(diào)試程序(在單獨的控制臺上運行),您可以修復(fù)錯誤并返回程序執(zhí)行模式。
“處理器”一詞并非偶然——它源于“進(jìn)程”。錯誤中斷只能在進(jìn)程運行期間發(fā)生,而不會在處理器停止并處于調(diào)試模式時發(fā)生。這一事實在我們稍后討論進(jìn)程和狀態(tài)之間的區(qū)別時會很有用。
向用戶清晰解釋他們最終進(jìn)入不同模式的原因和方式至關(guān)重要。例如,調(diào)試器會顯示導(dǎo)致無效操作的指令地址。同樣重要的是解釋如何返回(記住可逆性原則)。經(jīng)典的 Norton Commander 完美地詮釋了各種模式:
文件選擇模式
復(fù)印模式
管理員模式,需要對硬件錯誤做出響應(yīng)
我見過有人批評這類解決方案:“窗口疊在其他窗口上看起來很丑”。即便接受了這種說法,我仍然無法認(rèn)同設(shè)計師通常提出的替代方案:“我們把這個窗口移除,把錯誤顯示到別的地方,這樣更美觀。” 就好像設(shè)計師忘記了自己是工程師,只是拿起畫筆,像個泥水匠一樣把瑕疵掩蓋起來。
如果你真的想擺脫窗口,正確的方法是記住什么是模式、它們來自哪里以及它們是如何工作的——然后弄清楚如何避免切換到其他模式(如果你想深入了解模式,請閱讀 Jef Raskin 的《人性化界面》)。例如:軟盤空間不足?不允許復(fù)制文件。軟盤未插入?不要將其顯示在目標(biāo)列表中。現(xiàn)代操作系統(tǒng)就是這樣做的——它們消除了執(zhí)行可能導(dǎo)致錯誤中斷的操作的可能性。
現(xiàn)在我們可以猜一下雅虎上的“繼續(xù)”按鈕的作用了:它啟動了一個錯誤調(diào)試模式。在該模式下,用戶被賦予了程序員的角色,并被迫修復(fù)所有導(dǎo)致程序崩潰的空值和未定義值。不幸的是,開發(fā)人員并沒有意識到這對普通用戶來說有多么糟糕。我希望他們至少明白,他們剝奪了用戶返回上一個模式的能力——這違反了良好用戶體驗的最基本規(guī)則。
糟糕的算法變成了“最佳實踐”
乍一看,似乎所有網(wǎng)站的錯誤顯示都和雅虎一模一樣。所以這肯定是“最佳實踐”,是行業(yè)標(biāo)準(zhǔn)……但事實并非如此!每個人的做法都不一樣。我們來看看亞馬遜:
開始:所有字段均為空。無錯誤。“繼續(xù)”按鈕可用。
按下“繼續(xù)”按鈕。所有空白字段均標(biāo)記為錯誤(最后一個字段除外)。
要消除錯誤,僅僅切換到另一個字段是不夠的——您實際上必須輸入一個值。
再次按下“繼續(xù)”按鈕。除第一個字段外,所有字段均為空,并標(biāo)記為錯誤(第一個和最后一個字段除外)。
讓我們來分析一下。
一個活動按鈕——很好。亞馬遜正在跟上雅虎的步伐。
自動聚焦到第一個字段——太棒了(雅虎沒有這個功能):用戶可以立即開始輸入。填完第一個字段后,按“繼續(xù)”鍵會直接將光標(biāo)移動到第二個字段,也就是錯誤所在的地方。真是聰明的舉動!
有人會反對:自動對焦在桌面端運行良好,但在移動設(shè)備上鍵盤會遮擋半個屏幕,所以最好隱藏它,直到用戶點擊輸入。這樣一來,你解決了一個問題,又制造了另一個問題。然后你選擇你的毒藥……問題是,你會認(rèn)為一種弊端較小,而有些用戶會認(rèn)為另一種弊端更嚴(yán)重。無論哪種情況,你都在選擇一種弊端。不要這樣做(我稍后會解釋如何做)。
界面可逆性。你輸入一些內(nèi)容,錯誤消失;然后你刪除它并切換到另一個字段——哇,一個沒有錯誤的空字段。所有字段都一樣。將界面恢復(fù)到初始狀態(tài)比雅虎要難,但由于算法不穩(wěn)定,仍然是可能的。
與雅虎的同事一樣,亞馬遜的程序員在“繼續(xù)”按鈕和輸入字段之間建立了心靈感應(yīng):按鈕不想繼續(xù),但輸入字段都大聲喊出來(突然變成輸出字段)。
特別要提一下密碼確認(rèn)框——為什么它不變成紅色?不填就無法繼續(xù)。想說要等到前一個框填完后才進(jìn)行校驗?當(dāng)然,你得給用戶解釋一下錯誤校驗算法,再給他們看源代碼——這真的會很有幫助(諷刺)。
現(xiàn)在,我們來快速看一下IBM的解決方案:
激活按鈕——不錯。沒有自動對焦,但至少界面會自動滾動到第一個字段并顯示錯誤。
界面不可逆——無法將字段恢復(fù)到第一個屏幕上的樣子。換句話說,你無法退出調(diào)試模式。那么,為什么還要有第一個屏幕(調(diào)試模式)呢?如果你認(rèn)為空字段是錯誤,那就直接顯示第二個屏幕吧。哦,你不想立刻嚇到用戶?還記得感知心理學(xué)嗎?你決定稍后再嚇唬他們,作為對他們錯誤的懲罰?讓我再重復(fù)一遍心理學(xué)家的話:
重要的是不要用消極情緒來強化錯誤,因為大腦對此非常敏感,并會將這種行為記錄為不值得花費精力的事情。
例子不勝枚舉。以網(wǎng)站 capital.xyz 為例:
日期字段為空,點擊“下一步”按鈕,字段自動對焦。手機字段為空,點擊“下一步”——完全沒有自動對焦。為什么?這背后的想法是什么?劇透:根本沒這回事。只是算法出了問題。
谷歌甚至更進(jìn)一步——你輸入的每一個字符它都會責(zé)罵你……
即使你不同意我的批評,你也必須承認(rèn),知名公司的頂級設(shè)計師和程序員在實現(xiàn)同一項任務(wù)時,都采用了截然不同的方式。這意味著完美的解決方案尚未找到。很可能,根本沒人真正去尋找它。程序員只是在缺乏對用戶交互原則清晰理解的情況下編寫代碼,然后跑來找設(shè)計師說:“嘿,這里又有一個錯誤需要顯示出來。”
當(dāng)我為自己的項目設(shè)計錯誤顯示時,我沒有依賴別人的解決方案——我依靠科學(xué)。我在撰寫本文時收集了來自雅虎、亞馬遜和 IBM 的示例。在對所設(shè)計機制背后的原理沒有深入理解之前,研究參考文獻(xiàn)是有害的。你只會撿起別人的錯誤,然后引用權(quán)威文獻(xiàn)來為自己辯護(hù)。幾乎每個人都這樣做。沒有人愿意重新發(fā)明輪子——工業(yè)程序員沒有時間或動力去做這件事。所以每個人都堅持使用老式的命令行、字母數(shù)字顯示方法。還記得當(dāng)時錯誤是如何顯示的嗎?如果沒有,來看看控制臺:
如今,界面開發(fā)人員仍在做著同樣的事情:直接把錯誤日志直接倒在屏幕上。21世紀(jì)唯一的升級?把文本涂成紅色,然后把信息分散到屏幕的不同位置。
這可不行。我們趕緊解決吧!
事件與狀態(tài)
我們用“錯誤”這個詞來描述兩種截然不同的事物: 事件 和 狀態(tài) 。快速回顧一下:當(dāng)處理器嘗試執(zhí)行無效操作時,它會觸發(fā)中斷并進(jìn)入調(diào)試模式。這是一次性事件。我們說“發(fā)生了錯誤”。然后,我們?nèi)ふ覍?dǎo)致崩潰的內(nèi)存中的特定值。該值——或者更準(zhǔn)確地說,存儲單元的狀態(tài)——也稱為“錯誤”。換句話說,我們模糊了因果之間的界限——僅僅是因為我們沒有想出單獨的詞。為了避免混淆,我將使用兩個術(shù)語: 進(jìn)程錯誤 (事件,某個時間點)和 數(shù)據(jù)錯誤 (內(nèi)存中的錯誤值,一種狀態(tài))。
我們來看一個郵箱輸入框。缺少“@”符號?這是 數(shù)據(jù)錯誤 。被郵件服務(wù)器退回郵件?這是 流程錯誤 。或者以郵政編碼為例。位數(shù)太少?這是數(shù)據(jù)錯誤。數(shù)據(jù)庫中找不到郵政編碼?這是流程錯誤。
空字段
輸入字段只是一個數(shù)據(jù)容器。數(shù)據(jù)可能會缺失。如果你沒有輸入生日,并不意味著你出生在零日。這個輸入字段根本沒有數(shù)字,只有占位符“日”。數(shù)據(jù)缺失了。
因此,空白字段并非數(shù)據(jù)錯誤。不存在的東西本身就不是什么錯誤。空白字段是創(chuàng)建數(shù)據(jù)的 機會 ,是一個良好的起點,也是一個互動的邀請。你可能已經(jīng)注意到,空白表單看起來比已填充的表單更優(yōu)雅。那么,為什么要用有毒的紅色來破壞它呢?誰會喜歡與標(biāo)記為危險的字段互動呢?
不要這么做。我準(zhǔn)備了一個交互式原型來向你展示應(yīng)該怎么做。
狀態(tài)改變
讓我們看看電水壺中按鈕和水的狀態(tài)是如何變化的。打開電水壺。水沸騰后,按鈕會彈開。但觸發(fā)按鈕的不是水,而是溫度傳感器。如果傳感器損壞或丟失,按鈕就不會彈開。
現(xiàn)在手動按下按鈕——水不會突然變冷。了解導(dǎo)致狀態(tài)變化的具體原因 很重要。
規(guī)則如下: 如果對對象 A 執(zhí)行了某個操作,那么只有 A 的狀態(tài)可以改變 ,而對象 B 的狀態(tài)則不能改變。要更改 B 的狀態(tài),需要一個直接作用于 B 的獨立進(jìn)程。
例如,數(shù)據(jù)庫搜索可能會觸發(fā)索引重建——這會更改數(shù)據(jù)庫本身,但 不會 改變您搜索的值。
讓我們來看一個常見的 UI 設(shè)計錯誤。用戶想通過郵政編碼查找城市。他們輸入郵政編碼,點擊“搜索”,然后……輸入框變紅,或者值消失了。發(fā)生了什么?這是一個 流程錯誤 ——數(shù)據(jù)庫中沒有結(jié)果。但 UI 卻將其顯示為 數(shù)據(jù)錯誤 ,就好像用戶輸入了錯誤的郵政編碼一樣。但也許郵政編碼是有效的——只是城市還沒有添加到數(shù)據(jù)庫中。也許五分鐘后就會添加。用戶并沒有輸入錯誤數(shù)據(jù)。輸入框不應(yīng)該受到指責(zé)。我們無權(quán)觸碰它。流程錯誤需要 以不同的方式 顯示(稍后會詳細(xì)介紹)。
一次一個動作
根據(jù)希克-海曼定律,提供的選項越少,用戶選擇所需內(nèi)容的速度就越快。將這一原理推向極致,便可得出“一屏一操作”原則。有人可能會說,復(fù)雜的程序不可能簡化到這種程度,但讓我們回想一下 Hanx Writer 文本編輯器——蘋果設(shè)計獎得主——它幾乎精簡了所有內(nèi)容。或者想想在 Photoshop 中按下一個按鈕就可以隱藏整個界面,只留下一個工具可見。在某些情況下,“一屏一操作”原則非常有效。至少,在放棄它之前,先嘗試一下。
在優(yōu)化了 開立經(jīng)紀(jì)賬戶的網(wǎng)頁工作流程后,我決定在移動應(yīng)用中測試這種方法。看看我的 交互式原型吧 ——它通過了 17 位用戶的快速測試,與舊版本(每個屏幕有多個輸入字段)相比,速度提升了 13%。
有人可能會說,時間的提升并不大——少了52秒,而不是整整一分鐘。但首先,試著數(shù)到8——這實際上是一段相當(dāng)長的時間內(nèi),任何事情都可能發(fā)生。其次,測試表明時間 減少了 ,而不是像一些人擔(dān)心的那樣增加了。他們假設(shè)額外的屏幕轉(zhuǎn)換會減慢用戶的速度,但結(jié)果卻恰恰相反:信息越少,用戶處理速度就越快。當(dāng)只有一個操作可選時,用戶會毫不猶豫地執(zhí)行。
原型 就是這樣。屏幕上只有一個輸入字段。用戶輸入數(shù)據(jù),按下“繼續(xù)”,屏幕就會滾動到下一步。如果你手動嘗試在空白字段處向前滾動,屏幕會迅速彈回:“不行,不行”。輸入字段保持焦點,提示用戶輸入數(shù)據(jù)。無需任何額外的高亮——畢竟,它是屏幕上唯一的字段。完美。
如果你點擊“繼續(xù)”,但輸入框為空或郵箱地址缺少“@”符號,鍵盤會彈回來,仿佛在說:“想繼續(xù)嗎?那就繼續(xù)填寫吧。” 沒有任何錯誤信息!
我再強調(diào)一遍:我們 不會 隱藏錯誤信息。相反,我們設(shè)計的系統(tǒng)絕對不會出錯。沒有數(shù)據(jù)就意味著沒有數(shù)據(jù)錯誤。沒有流程就意味著沒有中斷或調(diào)試模式。這里唯一的期望是數(shù)據(jù)以正確的格式輸入。順便說一句,這里有一個很棒的方法——接受任何合理格式的數(shù)據(jù)。例如,Sberbank.ru 允許您輸入帶有國家代碼 (+7)、本地前綴 (8) 或完全不帶區(qū)號的電話號碼。
從本文俄語版的評論來看,并非所有人都理解原型的用途。有些人期望看到一個完美無瑕、隨時可用的產(chǎn)品(一個他們可以直接復(fù)制的產(chǎn)品),結(jié)果卻大失所望,對諸如缺少重新發(fā)送短信驗證碼的選項之類的問題吹毛求疵。讓我再次澄清:本文中的原型并非成品的精確復(fù)制品。它們的唯一目的是展示如何消除錯誤信息。
現(xiàn)在,讓我們將此解決方案擴(kuò)展到界面無法簡化為“一屏一操作”模式的情況。 “Ingos Investments”的 原型 反映了數(shù)據(jù)量巨大,以至于每個屏幕上必須顯示多個字段的情況。
讓我們設(shè)想一個場景:用戶尚未填寫所有字段,點擊了“繼續(xù)”按鈕。界面立即聚焦于 第一個 空白字段,調(diào)出屏幕鍵盤,并滾動到該字段正上方,方便用戶查看正在輸入的內(nèi)容。即使屏幕上有多個字段,我們?nèi)匀粓猿?ldquo;一次一個操作”的原則,巧妙地將其他字段隱藏在鍵盤下方。在活動字段下方,會出現(xiàn)一條提示:“所有字段必須填寫”。這不是錯誤消息,而是一個有用的提示,沒有任何令人擔(dān)憂的危險信號。
當(dāng)用戶點擊屏幕鍵盤上的“下一步”時,他們只會跳轉(zhuǎn)到下一個字段——這和填寫表單的常規(guī)流程一樣,而不是笨重的錯誤調(diào)試模式。提示已經(jīng)給出,所以用戶不太可能再次嘗試填寫空白字段。但如果他們真的這么做了,那么他們會再次看到這個溫馨提示。
懷疑論者可能會說:“但如果空白字段位于屏幕最頂部,無法滾動到鍵盤上方怎么辦?或者,如果網(wǎng)站是在桌面上打開的,根本沒有屏幕鍵盤怎么辦?” 答案是:沒什么大不了的。所有這些極端情況都在原型中得到了完美的體現(xiàn)。我也聽到過這樣的擔(dān)憂:“如果我們不把每個字段都涂成紅色,用戶就不會意識到需要填寫”。測試表明,這些擔(dān)憂是毫無根據(jù)的。這些擔(dān)憂背后真正的恐懼,是害怕打破常規(guī),嘗試一些真正新穎的東西——一些對用戶更有利,而不僅僅是對我們自己更有利的東西。
州經(jīng)理
為了創(chuàng)建“Ingos Investments”的原型,我編寫了一個狀態(tài)管理調(diào)度器。交互元素將其內(nèi)容報告給管理器,然后管理器決定如何處理它們。
程序員常說輸入字段是獨立的元素。郵箱字段不知道電話字段里的內(nèi)容。當(dāng)你切換輸入字段時,它會觸發(fā)對其內(nèi)容的驗證。當(dāng)你點擊“繼續(xù)”按鈕時,所有輸入字段都會收到一個命令——檢查你的數(shù)據(jù)。這就是為什么它們會突然一起亮起紅燈。這就是它的構(gòu)造方式。程序員說你無法改變它。設(shè)計師也相信這一點。不過亞馬遜的例子表明,密碼確認(rèn)字段確實知道前一個字段的內(nèi)容。所以他們可以隨時修改。
這意味著你可以而且應(yīng)該創(chuàng)建一個狀態(tài)管理器。當(dāng)用戶嘗試跳轉(zhuǎn)到下一個屏幕時,狀態(tài)管理器會檢查所有字段,找到 第 一個包含不完整或無效數(shù)據(jù)的字段,將用戶帶回該輸入框并顯示提示。本質(zhì)上,這是一次時光之旅——回到用戶出錯的點。因此,將后續(xù)字段標(biāo)記為錯誤是沒有意義的——它們發(fā)生在將來,而用戶尚未到達(dá)它們。
使用狀態(tài)管理器,您還可以在鼠標(biāo)懸停在“繼續(xù)”按鈕上時檢查字段內(nèi)容。如果數(shù)據(jù)缺失,按鈕的標(biāo)簽會更改為特定的字段名稱,例如“輸入街道”——這遵循了時效性原則(用戶嘗試?yán)^續(xù),但需要填寫字段,我們會通知他們)。這個新標(biāo)簽在按鈕和字段之間建立了視覺聯(lián)系,使程序員有理由將這兩個元素的行為聯(lián)系在一起。
程序員可能會問:“為什么要把事情復(fù)雜化?” 沒錯——對程序員來說越復(fù)雜,對用戶來說就越容易。這是規(guī)則。說實話,這只需要一兩天的時間。需要更多精力的是通知系統(tǒng)。數(shù)據(jù)錯誤和流程錯誤應(yīng)該顯示在各自的層級結(jié)構(gòu)中:數(shù)據(jù)錯誤應(yīng)該顯示在數(shù)據(jù)容器中,而流程錯誤應(yīng)該顯示在應(yīng)用程序范圍的通知中。這是一個完全獨立的主題,我希望有時間寫一篇關(guān)于通知設(shè)計的文章。
結(jié)論
因此,我們發(fā)現(xiàn)了以下事實:
絕大多數(shù)現(xiàn)有解決方案都?xì)w結(jié)為切換到“錯誤糾正模式”,而退出該模式要么不可能,要么極其困難(只能通過算法中的錯誤)。這種方法雖然被廣泛接受,但各地的實現(xiàn)方式卻有所不同:空白字段可能被視為錯誤,也可能被視為正常,有時甚至?xí)谕黄聊簧匣旌铣霈F(xiàn)。用戶會背負(fù)負(fù)面情緒,因為系統(tǒng)會“懲罰”他們破壞程序。這種方法絕對不可接受,必須予以糾正。
缺少數(shù)據(jù)并不意味著數(shù)據(jù)錯誤。空白字段是互動的邀請,而非危險信號。
我們不需要兩種模式:數(shù)據(jù)錄入和糾錯。一種模式——數(shù)據(jù)錄入——就足夠了。
數(shù)據(jù)錯誤和流程錯誤是不同的。它們應(yīng)該顯示在相應(yīng)的層級結(jié)構(gòu)中:數(shù)據(jù)錯誤應(yīng)該顯示在數(shù)據(jù)容器中,而流程錯誤應(yīng)該顯示在全局通知中。
如果您希望對一個對象執(zhí)行的操作影響另一個對象,請在它們之間建立清晰的視覺聯(lián)系。
“一屏一操作”原則一定要試一下。如果有效,那你太棒了!
編寫一個簡單的狀態(tài)管理調(diào)度程序。借助它,你可以引導(dǎo)用戶回到最早未完成的步驟。
創(chuàng)建原型——它們是新想法的最佳概念證明。
蘭亭妙微(m.sdgs6788.com ) 是一家專注而深入的界面設(shè)計公司,為期望卓越的國內(nèi)外企業(yè)提供卓越的大數(shù)據(jù)可視化界面設(shè)計、B端界面設(shè)計、桌面端界面設(shè)計、APP界面設(shè)計、圖標(biāo)定制、用戶體驗設(shè)計、交互設(shè)計、UI咨詢、高端網(wǎng)站設(shè)計、平面設(shè)計,以及相關(guān)的軟件開發(fā)服務(wù),咨詢電話:01063334945。我們建立了一個微信群,每天分享國內(nèi)外優(yōu)秀的設(shè)計,有興趣請加入一起學(xué)習(xí)成長,咨詢及進(jìn)群請加藍(lán)小助微信ben_lanlan