在B端場景中，文本域是一個相對常見的控件，而一個適合業(yè)務(wù)場景的文本域設(shè)計，可以很大程度地提升工作效率。這篇文章里，作者就對文本域的設(shè)計優(yōu)化進行了思考與總結(jié)，一起來看一下，或許會對你有所啟發(fā)。

一、前言

文本域是B端常見控件之一，主要是用于長文本段落的錄入與查閱。一個適合業(yè)務(wù)場景的文本域設(shè)計，可以提高執(zhí)行人員的錄入效率和管理層的查看效率，從而提高管理與執(zhí)行雙角色用戶的工作效率和體驗。接下來從雙視覺角度來拆解文本域的優(yōu)化方案。

二、業(yè)務(wù)背景

長文本輸入在測試業(yè)務(wù)之中的價值非常重要，其一是用例的有效性的結(jié)論影響到了產(chǎn)品的性能，有影響到了主管判斷一個執(zhí)行者專業(yè)度以及程序同學(xué)的專業(yè)度呈現(xiàn)，涉及到了執(zhí)行人員以及主管的績效。對外也能展現(xiàn)研發(fā)團隊的專業(yè)度。

在測試報告詳情中，所有角色最關(guān)注的點就是測試結(jié)論，主要是關(guān)注測試用例的結(jié)果查找開發(fā)過程中的問題，降低后續(xù)產(chǎn)品出現(xiàn)問題的概率影響到了執(zhí)行者的工作效率。目前存在的問題是，不僅僅是執(zhí)行者書寫錄入成本較高/完成度較低/對于字數(shù)顯示無法掌控，而且管理者也是存在查看成本高的問題影響到了決策成本。

接下來分析雙視角進行拆解和分析。

三、雙視角拆解

涉及到文本域的使用和查看的主要是2類：

1. 執(zhí)行者：核心訴求是快速完成錄入信息。
2. 管理者：針對用例測試情況進行掌控，排查代碼問題。

1. 執(zhí)行者

一個測試工程師每天按照任務(wù)規(guī)劃，開始手動測試流程或者是功能模塊的代碼是否走的通順，同時檢查是否有相應(yīng)的bug問題，測試結(jié)果是每天大量寫的工作項。如果文本域填寫效率過低的話會導(dǎo)致任務(wù)堆積，工作效率下降就有可能遺漏測試任務(wù)。

2. 管理者

而管理者更加關(guān)注自動化測試和手動測試的結(jié)果，以及測試工程師的任務(wù)完成情況，具體的成果要向上進行匯報。由于每個執(zhí)行人員錄入的習(xí)慣不一致，且最終的效果呈現(xiàn)不夠明顯，就導(dǎo)致了查看成本過高的話，就會提高策略判斷成本，從而降低管理效率。

理論上文本域不優(yōu)化沒有任何問題，直接拖拽的組件也能滿足基本訴求，但是一個好的文本域技能提執(zhí)行者的工作效率，也能提高管理層用戶的決策能力。

四、如何知道用戶的需求呢？

團隊開始時候是采用的用戶訪談以及邀請伙伴一起使用并且建群收集意見的方式，但是這個方式在執(zhí)行中有著明顯的弊端：

1. 需求很散：每個人提的需求都只是他/她個人的個性需求點而不是職位的共性需求點。
2. 描述不清：很多用戶大部分的時候更多是描述的是主管的感受不如“有點高”“有點窄”，對于產(chǎn)品優(yōu)化并無作用。
3. 執(zhí)行錄入習(xí)慣不同：同一個文本域，每個執(zhí)行人員的書寫習(xí)慣導(dǎo)致了描繪的重點并不同，可以理解為“一千個人里面有一千個哈姆雷特”。
4. 態(tài)度敷衍：除了少數(shù)關(guān)系好的伙伴，其他伙伴更多的是為了配合部門老大下的配合任務(wù)，更多的時候為了自己KPI，而不是產(chǎn)品優(yōu)化所以給的意見通常是不靠譜的。

改進后的調(diào)研措施

之前的調(diào)研偏向于主管調(diào)研，效果并不好，用戶需求篩選成本極高。后面團隊商討之后，決定從交付物（報告）入手，產(chǎn)品與設(shè)計拿到授權(quán)查看了執(zhí)行人員的任務(wù)KPI和300份左右最新的測試報告進行拆分。

針對于主管的調(diào)研，更多的是查看各個主管的對于部門老大交付物（報告）進行查看與分析。

五、如何解決問題

1. 編輯

1）強推模板化——提高錄入效率與查看效率

經(jīng)過了300多份報告分分析之后，將報告內(nèi)容拆解為：「總」「分」「詳」形式，分別解析為：

1. 總“數(shù)據(jù)總覽”：主要是描述版本號，執(zhí)行總數(shù)，成功/失敗了多少，通過率如何。
2. 分“版本統(tǒng)計”“缺陷詳細統(tǒng)計”：版本統(tǒng)計：一般統(tǒng)計的是缺陷數(shù)，修復(fù)的數(shù)量以及修復(fù)率如何一類的監(jiān)督開發(fā)的數(shù)量 。缺陷詳細統(tǒng)計：一般統(tǒng)計的是缺陷的遺留問題的分類等。
3. 詳情“具體測試的詳情”：主要是包含了風(fēng)險詳情等內(nèi)容。

2）錯別字提示——降低修改成本

業(yè)務(wù)中因為通常要寫的很多，難免會出現(xiàn)錯別字。為此當(dāng)用戶錄入錯別字時候，交互上會給他一個下劃線進行提示，懸浮狀態(tài)給與正確詞匯的提示，點擊可以轉(zhuǎn)換文字。如若是執(zhí)行人員任務(wù)系統(tǒng)判斷錯誤的場景，點擊報錯文字即可取消錯別字提示效果。

3）優(yōu)化操作——結(jié)果以選代錄入

以往的結(jié)果需要執(zhí)行者自動錄入最后的結(jié)果，優(yōu)化交互之后講文本替換成為了表單進行下拉選擇，簡化了用戶填寫的時長。

4）情感化插畫——降低浮躁感

人不是機器，在工作量達到一定量之后就會煩躁，所以采用了結(jié)束狀態(tài)一些情感化插畫來安撫用戶的心靈，至少在工作中找到一些樂趣。

2. 查看

1）模版文案數(shù)據(jù)化且前置——降低理解成本

主管需要在幾秒鐘內(nèi)了解到本次測試的詳細的情況，而“數(shù)字”是最快能表現(xiàn)方式。因此在設(shè)計末班上上，將數(shù)據(jù)總覽以及版本和缺陷統(tǒng)計以數(shù)字單獨呈現(xiàn)，并且前置且加粗文字來凸顯文字的重要性，降低用戶的理解成本。

2）結(jié)果印章化——降低理解成本

原先的設(shè)計之中結(jié)果只是小小的一項并不明顯，后面在做迭代的時候，設(shè)計將結(jié)果印章話。這里面出現(xiàn)了一點點波折，原先按照業(yè)務(wù)放置的位置是測試報告的右上方，但是在設(shè)計中發(fā)現(xiàn)了問題：文本域高度是不固定的，有可能極高有可能極低，這里要考慮到開發(fā)的適配問題（很難進行適配）。

然后參考了全局頁面決定與基本信息放置到一起，主管瀏覽的基本信息，看到一個明晃晃的“大印章”就知道了測試結(jié)果，同時開發(fā)也不用考慮適配中的高度問題。

六、未來規(guī)劃

現(xiàn)在這個版本的模版并沒有滿足全部用戶的需求，比如很多團隊其實有他們自己特色的模版，或者很多執(zhí)行人有自己的書寫方式且相關(guān)主管覺得也不錯值得推廣的，未來可能會開放更多的模版以及個人特色模版的審核之路。

七、如何驗證

灰度上線一個月后，執(zhí)行者的單詞填寫時間從7分鐘縮短到了4分鐘。

八、總結(jié)

設(shè)計師要關(guān)注到每一個微小的點，當(dāng)每一個微小的點都做好的時候產(chǎn)品會越來越好，自己的成長會越來越快。