从执行者和管理者角度，拆解B端文本域的优化方案

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

文本域是B端常见控件之一，主要是用于长文本段落的录入与查阅。

一个适合业务场景的文本域设计，可以提高执行人员的录入效率和管理层的查看效率，从而提高管理与执行双角色用户的工作效率和体验。

接下来从双视觉角度来拆解文本域的优化方案。

业务背景

长文本输入在测试业务之中的价值非常重要，其一是用例的有效性的结论影响到了产品的性能，有影响到了主管判断一个执行者专业度以及程序同学的专业度呈现，涉及到了执行人员以及主管的绩效。对外也能展现研发团队的专业度。

在测试报告详情中，所有角色最关注的点就是测试结论，主要是关注测试用例的结果查找开发过程中的问题，降低后续产品出现问题的概率影响到了执行者的工作效率。

目前存在的问题是：不仅仅是执行者书写录入成本较高/完成度较低/对于字数显示无法掌控，而且管理者也是存在查看成本高的问题影响到了决策成本。

接下来分析双视角进行拆解和分析。

双视角拆解

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

1. 执行者

一个测试工程师每天按照任务规划，开始手动测试流程或者是功能模块的代码是否走的通顺，同时检查是否有相应的bug问题，测试结果是每天大量写的工作项。如果文本域填写效率过低的话会导致任务堆积，工作效率下降就有可能遗漏测试任务。

2. 管理者

而管理者更加关注自动化测试和手动测试的结果，以及测试工程师的任务完成情况，具体的成果要向上进行汇报。由于每个执行人员录入的习惯不一致，且最终的效果呈现不够明显，就导致了查看成本过高的话，就会提高策略判断成本，从而降低管理效率。

理论上文本域不优化没有任何问题，直接拖拽的组件也能满足基本诉求，但是一个好的文本域技能提执行者的工作效率，也能提高管理层用户的决策能力。

如何知道用户的需求呢？

团队开始时候是采用的用户访谈以及邀请伙伴一起使用并且建群收集意见的方式，但是这个方式在执行中有着明显的弊端：

改进后的调研措施：

之前的调研偏向于主管调研，效果并不好，用户需求筛选成本极高。后面团队商讨之后，决定从交付物（报告）入手，产品与设计拿到授权查看了执行人员的任务KPI和300份左右最新的测试报告进行拆分。

针对于主管的调研，更多的是查看各个主管的对于部门老大交付物（报告）进行查看与分析。

如何解决问题

1. 编辑

1）强推模板化——提高录入效率与查看效率

经过了300多份报告分分析之后，将报告内容拆解为：「总」「分」「详」形式，分别解析为：

2）错别字提示——降低修改成本

业务中因为通常要写的很多，难免会出现错别字。为此当用户录入错别字时候，交互上会给他一个下划线进行提示，悬浮状态给与正确词汇的提示，点击可以转换文字。如若是执行人员任务系统判断错误的场景，点击报错文字即可取消错别字提示效果。

3）优化操作——结果以选代录入

以往的结果需要执行者自动录入最后的结果，优化交互之后讲文本替换成为了表单进行下拉选择，简化了用户填写的时长。

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

人不是机器，在工作量达到一定量之后就会烦躁，所以采用了结束状态一些情感化插画来安抚用户的心灵，至少在工作中找到一些乐趣。

2. 查看

1）模版文案数据化且前置——降低理解成本

主管需要在几秒钟内了解到本次测试的详细的情况，而“数字”是最快能表现方式。因此在设计末班上上，将数据总览以及版本和缺陷统计以数字单独呈现，并且前置且加粗文字来凸显文字的重要性，降低用户的理解成本。

2）结果印章化——降低理解成本

原先的设计之中结果只是小小的一项并不明显，后面在做迭代的时候，设计将结果印章话。这里面出现了一点点波折，原先按照业务放置的位置是测试报告的右上方，但是在设计中发现了问题：文本域高度是不固定的，有可能极高有可能极低，这里要考虑到开发的适配问题（很难进行适配）。

然后参考了全局页面决定与基本信息放置到一起，主管浏览的基本信息，看到一个明晃晃的“大印章”就知道了测试结果，同时开发也不用考虑适配中的高度问题。

未来规划

现在这个版本的模版并没有满足全部用户的需求，比如很多团队其实有他们自己特色的模版，或者很多执行人有自己的书写方式且相关主管觉得也不错值得推广的，未来可能会开放更多的模版以及个人特色模版的审核之路。

如何验证

灰度上线一个月后，执行者的单词填写时间从7分钟缩短到了4分钟。

总结

设计师要关注到每一个微小的点，当每一个微小的点都做好的时候产品会越来越好，自己的成长会越来越快。