B端設計|設計走查
編輯導語:B端的走查過程需要看各項指標數據以及業務、組件等是否搭配得當,同時也是對許久為參與的項目產品進行一致性的修改,并整理出一套可行并且規范的標準,用于應對后續新的設計。本文對設計走查過程進行了一個詳細的梳理,一起來看看。
前言:B端的走查過程和C端差異的比較明顯,看數據、看業務、看操作,看組件是否搭配得當。從設計角度來看,結合交互,結合部分的業務需求、業務場景去來完成這個過程。
需要對長久未參與的項目產品進行一致性的修改。也借此做一次設計走查,整理出一套合適的規范標準需要設計、開發遵循,來應對新的需求。
搞清楚幾個問題:
- 什么時候做設計走查
- 為什么決定要做設計走查
- 怎么做設計走查
一、什么時候做走查
以真實內容說明這個問題。
參與的項目,開發到現在兩年了,持續迭代中,目前階段處于平穩迭代中。平穩期間開始做走查任務。
原因:初期項目開發,業務復雜,場景變化多,現成的前端框架能夠滿足需求,后續的項目推進,加入更多的場景,更多的需求,前端被迫忽略了組件規范要求。
目前:操作上出現的問題也越來越多,控件套用,體驗上的問題也顯著出現。比如說標簽導航,也用作按鈕功能;切換篩查標簽也當作按鈕使用了
二、為什么決定要做設計走查
對小公司來說,做走查不是件容易的事,所以只能邊走邊看,邊修改邊完善。
通過和產品進行一個小時的討論,主要有以下幾點:
- 前期設計參與,有對布局一致性有把控,在之后一年多時間,設計退出,問題出現了;
- 討論過程中,容易偏離主題(比如開始是討論布局間距,到按鈕,之后容易被場景帶入,聊到按鈕應用場景,越來越偏離中心);
- 系統中存在組件混用,濫用情況。
希望設計給出一個標準化的規范指導界限,明確哪些內容應該怎么做,做到什么程度。盡可能避免一些操作上的問題。
三、怎么做設計走查
1. 找問題
所見即所得,引起大家共識,明白哪里的問題。
把所有不合適的,不準確的頁面截圖,找出來,合集到一塊,再對這些截圖進行分類,并配相應的文字說明。
一定要找全類型問題,一定要,一定要,重要事說三遍。
只有問題找全才能更全面解決好問題。
找問題的方式,等同于設計組件前期的對所有問題組件的歸納分類。
2. 分類
找完問題后需要對這些問題進行分類,從兩個角度考慮:
一是從數據組件的分級(即組件的應用);二是從業務的核心度,將涉及主流業務打上標簽,便于優先處理;三是考慮擴展性,數據是動態的,所以在邊走查邊考量擴展性。
這里不對數據組件進行特別的說明,組件從設計規范的時候就已經有完整的交互樣式了,但在走查表中也要標識出來。組件不能滿足的業務需要的才會增加新的組件。
走查主要從操作業務流程出發,檢查組件應用的合理性,即組件是否滿足場景需求。
帶著業務場景去操作一遍,通用的方式,了解主流程,操作分流程,分流程完成了,主流程不會斷。
整理操作依據表(業務相關的,還是由產品出)。
對于查找出的問題,也將其區分等級:
緊急:數據丟失、缺失,功能不可用,按鈕點擊無反應;
嚴重:功能設計與需求嚴重不符,數據結果錯誤,程序接口調用錯誤等;
一般:功能未實現但不影響使用,操作時間長,數據字段過長,頁面樣式(頁面布局不規范、顯示重疊、不該顯示不隱藏、描述不清,晦澀難懂未注釋、默認提示不準確、文字排列不對齊、光標圖標寓意不正確);
次要:建議問題,不影響使用,只是體驗差點;
與之相對應的處理等級是緊急處理、優先處理、一般處理、暫不處理。
3. 實施
找茬小分隊的人員分配。
產品主要找緊急與嚴重等級的,設計主要找一般和次要的以及部分嚴重等級的。其他人根據上邊的表格查找流程的問題。將體驗出的問題以表格內容記錄下來,并給這些問題標記路徑、等級和處理等級,以及修改建議。并將重復內容合并。
之后將開發(前端+后端)也拉出來,展開一次會議討論,將問題處理人指派到人。
四、總結
建立一套規范切切實實的讓組成員遵守規則。也通過每一次的總結,將每一次的任務內容沉淀下來。
本文由 @Ychen(啊嗚計) 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
有點靠經驗,缺少系統方法,所以,說不清怎么樣才算問題?更說不清怎么才算找全了?建議進一步研究。
一個小白選手看的懵懵懂懂 希望以后能看懂
收藏下,說不定哪天能用得上,??
寫得很詳細,邏輯分明,一下子就看懂了
做好設計走查,一定能在2b2c的的運營中事半功倍,而且很具有針對性的說
設計走查是一項艱巨而繁瑣的工作,一份優秀的設計走查也同樣需要耗費很多的心血
是的,繁瑣的很
最近正好做這方面的工作,很有用!
有幫助就好