2023年TO B產(chǎn)品設(shè)計專題：報錯體系

TOB產(chǎn)品設(shè)計專題：報錯體系一、為何需要建立體系化的報錯模塊

無論哪種IT系統(tǒng)，無論面對哪類人群，系統(tǒng)中最常見的功能就是“報錯”，可能不少小伙伴會說，報錯soeasy！

哪需要特地爭論。可在深化設(shè)計產(chǎn)品之后，經(jīng)受過從0到1去設(shè)計一款產(chǎn)品的時候。你肯定會發(fā)覺。報錯遠遠沒有這么簡潔。報錯體系涉及到多方面問題。

比如報錯內(nèi)容標準化問題、報錯樣式體驗最佳問題、報錯方案自助解決率問題、報錯轉(zhuǎn)換器問題等等。

報錯需要體系化的產(chǎn)品設(shè)計。特殊是一些TOB的產(chǎn)品。由于業(yè)務簡單、行業(yè)專業(yè)、對接頻繁、投入有效。更需要一套優(yōu)秀的報錯設(shè)計模塊。

二、背景分析：哪些不良的報錯設(shè)計

首先，我們需要做一個報錯模塊的背景分析，圍繞報錯這種業(yè)務形態(tài)，我們可以分析下有哪些常常消失的不良點。從背景上去推演我們需要一款什么樣的報錯產(chǎn)品。

1.報錯內(nèi)容不良問題：報錯指向位置不明、報錯內(nèi)容泰國專業(yè)、報錯內(nèi)容和緣由存在1對多狀況

許多TOB產(chǎn)品由于業(yè)務特別簡單、關(guān)聯(lián)外部系統(tǒng)接口較多、行業(yè)比較專業(yè)。故而在報錯層面常常會消失報錯內(nèi)容太專業(yè)的狀況。比如銀行系統(tǒng)、財務系統(tǒng)、供應鏈系統(tǒng)等；

然后報錯內(nèi)容也存在指向不明的狀況、比如不知道哪個位置、不知道哪個緣由。

還有的不良狀況就是報錯內(nèi)容和報錯緣由存在1對多狀況，比如報錯內(nèi)容為“預算不足、無法實現(xiàn)扣減”，而實際的報錯緣由可能存在多種狀況，有預算部門選錯了、有日期選錯了、有的確沒有預算、有沖銷未關(guān)聯(lián)問題造成。而系統(tǒng)粗暴的說了一個報錯內(nèi)容，發(fā)生緣由讓用戶去猜想。這也無形之中增加了企業(yè)的運營成本。

2.報錯樣式不良問題：報錯位置不統(tǒng)一、強弱控圖標不統(tǒng)一、報錯顏色不規(guī)范

人類是感官動物，而且經(jīng)過千百年的感官訓練。人類已對一些固有的顏色、固有的圖標有很強的辨識力和歸屬定位。比如紅色代表警告和禁止、綠色代表通過和贊同。叉叉圖標代表不允許、感嘆號圖標代表提示。系統(tǒng)也要沿用固有的設(shè)計模式，不要去挑戰(zhàn)常規(guī)認知。

不過有些系統(tǒng)并沒有這么做，常常會消失圖標不規(guī)范、顏色不規(guī)范的問題。同時也會存在報錯位置不統(tǒng)一問題。比如報錯在頁面頂部、報錯在頁面居中、報錯在輸入框下面、報錯在右下角等等。讓人琢磨不透。

3.報錯無閉環(huán)方案問題：只是報錯不供應方案、只有方案無跳轉(zhuǎn)路徑、只有方案沒有制度說明

這種不良問題是最為常見的，只有報錯問題，沒有解決方案。

緣由不外乎如下3種：

第一種為產(chǎn)品經(jīng)理沒有閱歷，只是給出問題；其次種為系統(tǒng)許多報錯是無法在產(chǎn)品側(cè)定義好，而產(chǎn)品和開發(fā)又沒有形成協(xié)同機制；第三種為團隊不關(guān)注經(jīng)營，只負責IT系統(tǒng)搭建，缺失問題解決率、用戶應用體驗度、系統(tǒng)運營成本的考量。4.報錯無擴展性設(shè)計問題：報錯采納硬編碼形式

這種是產(chǎn)品設(shè)計問題，整個系統(tǒng)缺失整體架構(gòu)。所以報錯均采納硬編碼形式，全部寫在代碼上。結(jié)果一上線后，發(fā)覺報錯看不懂、不好用。又需要花費時間去代碼上修改。而且針對多語言環(huán)境沒有綜合考慮，增加一種新的語言環(huán)境后，要全部的代碼均要去修改報錯。這造成整個團隊的開發(fā)效率低下、系統(tǒng)敏捷性不足、運營成本偏高。

5.報錯無法分析問題：很多據(jù)分析意識、很多據(jù)分析埋點

這種不良是許多IT團隊最為忽視的。許多IT團隊在企業(yè)內(nèi)不受到待見、其實有一部分緣由就是IT團隊缺失產(chǎn)品運營思維。在整個產(chǎn)品價值鏈之中，干得最具有技術(shù)性的活、而職責卻自我定位為執(zhí)行者。軟件好不好用我不管、軟件可不行用我不屑。當然就不會去關(guān)注報錯的可分析性。

報錯是最能體現(xiàn)軟件可用性的內(nèi)容了，報錯是實際運營中的數(shù)字化反映，哪里模塊報錯最為頻繁、哪個時間點報錯最多。可以第一時間定位出產(chǎn)品優(yōu)化方向。

三、調(diào)研：哪些報錯場景

經(jīng)過背景分析后，下來就需要對整個系統(tǒng)的報錯場景做一次整理，歸納下報錯的類型。從而對接下來的報錯做體系化的設(shè)計。

1.根據(jù)是否影響正常運作

強控報錯形式：消失了該特別后，則系統(tǒng)會無法正常運作、該類報錯必需在事故發(fā)生的那一刻得到解決。若忽視或由后期流程進行補充，則會存在事故風險和規(guī)章風險。弱控警告形式：消失了該特別后，則系統(tǒng)依舊正常運作、用戶可以選擇忽視；或者這是一種偏提示類問題，用戶只需要知悉即可。2.按錯誤的觸發(fā)緣由

自身的系統(tǒng)規(guī)律：這類特別是系統(tǒng)本身的規(guī)律要求，不受到外部系統(tǒng)的影響，在系統(tǒng)內(nèi)通過代碼修正、配置調(diào)整即可修復。外部的系統(tǒng)要求：外部接口報錯；這類特別不是系統(tǒng)本身的規(guī)律要求，而是由外部系統(tǒng)引發(fā)的，比如許多系統(tǒng)均要對接SAP、而在傳輸數(shù)據(jù)到SAP的時候，則SAP會返回報錯信息。這類特別大部分是由于數(shù)據(jù)不同步、數(shù)據(jù)為空造成。人為的報錯形式：審批人的駁回緣由報錯，這類特別不是系統(tǒng)規(guī)律造成的，而是在業(yè)務流轉(zhuǎn)過程中，由人工維護的。比如在流程審批中、審批人駁回給填單人，則填單人收到的駁回緣由。這類特別若無標準，也會造成大量的運營成本。底層框架的標準：系統(tǒng)底層報錯（SQL層）、框架（Hibernate），這類特別是工具框架造成的，是一些工具性軟件、硬件、服務器、操作系統(tǒng)的報錯。該類報錯對于大部分IT團隊而言是束手無策的。當然這類問題發(fā)生的概率很低。四、設(shè)計：報錯體系的產(chǎn)品設(shè)計方法論（雙輪驅(qū)動模型）

筆者也針對報錯體系總結(jié)了一套設(shè)計方法論，總結(jié)名稱為“雙輪驅(qū)動報錯設(shè)計模型”，下圖為該模型的結(jié)構(gòu)圖。

整個模型由兩個輪組合而成，外輪為運營輪、內(nèi)輪為設(shè)計輪。

在設(shè)計輪層面，要求報錯產(chǎn)品要滿意四個要素，報錯的樣式和內(nèi)容是標準的、報錯的解決是閉環(huán)的、報錯的內(nèi)容和方案是可配置的、報錯的可用性是可分析的。

在有了這四個設(shè)計要素后，則全部的報錯信息都要用運營三步閉環(huán)方法法進行推動。

第一步先將報錯進行分解；其次步進行報錯的配置；第三步要通過實際運行進行分析，最終又回歸到分析后，對報錯進行更細顆粒度的分解。

五、運營：報錯的數(shù)據(jù)化運營

報錯在產(chǎn)品運營中也是特別重要的數(shù)據(jù)指標，筆者在做產(chǎn)品經(jīng)理的時候，常常會去分析報錯內(nèi)容。個人總結(jié)有如下價值：

1.價值1：查找產(chǎn)品新的優(yōu)化點

對報錯做模塊分類、時間分類、組織分類、人群分類。可以從報錯上找出許多產(chǎn)品優(yōu)化點。

2.價值2：增加方案的勸說力

在做需求評審、做方案研討時，并不是誰的嗓門大，誰就更有話語權(quán)。若產(chǎn)品能在溝通中，甩出幾個報錯數(shù)據(jù)分析，是很具備勸說力的。

3.價值3：驅(qū)動業(yè)務資源投入

產(chǎn)品2/8原則在任何產(chǎn)品中都是適用的，20%的工作在軟件開發(fā)中，80%的工作上線后運營。而通過分析報錯，可以快速找到業(yè)務協(xié)作不良的地方，從而驅(qū)動業(yè)務協(xié)作產(chǎn)品推廣、驅(qū)動業(yè)務調(diào)整工作機制。就比如搶單模式若不做薪酬改造，就很難推行。

六、總結(jié)復盤

報錯雖然是整個系統(tǒng)中特別小的一個產(chǎn)品模塊，也是產(chǎn)品人員最為忽視的一個產(chǎn)品模塊。可細究下來、每一個產(chǎn)品