数据生产后台体验优化.docx

《数据生产后台体验优化.docx》由会员分享，可在线阅读，更多相关《数据生产后台体验优化.docx（22页珍藏版）》请在第一文库网上搜索。

1、数据生产后台体验优化一、项目背景我们给用户提供的是一款专业资料查询阅读的App ,用户最看重的是资料覆盖是否全面，内容是否严谨。这就辛苦了公司的数据生产团队，必须非常及时和高效率地拿到一手原始资料，进行翻译编辑校对等工作后发布给用户阅读。原始资料数据生产为了保证效率和质量，公司自行开发数据生产后台，数据团队成员在此协作数据生产。具体逻辑如下图所示：flfl市核,领取审核任务“ 主编是最高权限角色。负责创建数据生产任务，并且对最终生产的数据质量进行把关后发布给用户。 编辑负责领取数据生产中的编辑任务，完成任务后提交给审核。 审核对编辑生产的数据进行校对，如果不符合可打回编辑修改，符合数据可提交给

2、主编进行终审。随着数据生产后台的迭代，功能越来越多。原来的页面框架已经承载不了，因此我决定重新梳理，系统优化体验。二、找到重点B端系统逻辑很复杂，为了能系统的优化体验，我试图用某对象有若干属性，属性有不同的状态。状态不同操作不同，不同操作有不同的权限这个框架来梳理。状态属性这个框架梳理到接近完成时我放弃了。仅仅是鸟瞰全局就花了很多时间，如果再接着梳理细节，还不知道要花多久才能正式开始设计。属性状态操作am/止uA环节啦任务啦明处理M次ttfl写在rrawtat于是我转换思路，评估不同页面的体验问题严重程度，从难到易逐个击破。评估的方法用某个页面哪个角色执行哪些任务，任务频次、重要程度如何。数据

3、生产系统任务池页工作台页向：施任务IK次：中Ma/ ;中任务：监视任务迪度二VSJft :4创建任务页条目编辑页任务：创H任务任削欹：中fiZB(3Mi(0)任务：终审任朝秋：中9W1K :任务：审槎数摄根据评估结果，显然条目编辑页和工作台页是最应该优化的。三、梳理任务下图就是条目编辑页的老版本界面。根据不同的角色功能略有不同，但总体来说都是用户依次切换条目，并根据每个条目提供的参考资料等对内容进行编辑或审核。任务池工作台人员管理任务名称和ID任芳说明审核结果历史始录1/3 1参考文号来工（条目名称）条目描述条目附件pdf条目用传W，考来源（子任务Q）子任务H述子任务酎件4件子任务附件M子任期

4、附件M任务描述和附件主任务描述主amt忤刖王任鸟的外r交任务附件时近停&同阍：2020-1-20 12:23修选中文名这里是中文名字段名祢务 6位： 中 （第HI的内容*耀的内容编婚的内容内容编辑的内各娟II的内容娼峭的字段名称M Q ： 9 I编播的内容爆地的内容蝗鬼的内容的内容蜡强的内容编辎的内容编精别急着马上找页面上明显的问题，为了彻底消灭体验问题，首先应该梳理不同角色在页面上做的操作。如下图所示，编辑角色选择未编辑的条目查看任务说明后编辑内容和设置参考文献，之后保存草稿表示完成该条，接着继续选择未编辑的条目进行操作，直到所有条目完成后提交子任务。审核和主编角色的审核流程基本一致，区别在

5、于主编能自由打回到前面环节的任一角色。审核和主编在选择待审核条目后，查看内容和任务说明，对于不合格的条目能自行编辑或者填写审核意见，待子任务全部处理完成后提交。合格如果审核和主编在首次审核提交后有不合格的条目，那编辑得再次修改提交，审核和主编也要再次审核。和首次区别在于需要查看或者撰写审核/申诉意见。编辑角色根据审核结果修改法撵申用任务根据以上流程图，将角色和核心任务抽象后，可以简化为5个步骤（选择子任务在前一个页面完成，不算在内），如下图所示。1.选择待处理条目2.有看附属内容3.处理主体内容如果把步骤放在页面上，除了左侧主菜单占用太大面积，整个操作动线依次从上到下从左到右似乎没什么问题，但

6、真是如此吗？三任务名称和ID.任务说明承考文中文名这里是中文名学楼名称琏M岛：:工修台煽辑的内容嫡妈的内容煽辑的内容的内容编辑的内容编簿的内容蜿1将物的内容媲箱的内容握辑的内容内容奥浦的内容曩辑的内容编辑的fiM (B : 卡，AntDesign四、确定问题“考来源（条目名称）条目描述MF.pdf条目附件同,考来源（子任务ID）子任务推述钻务*仲M子任务附件皿子任务帔件41中任务描述和附件主任务描述主任疆附件M主任立用件R主任为IN件8f历史纪发值选修改时旭：2O2O-1-2O 12:23修改字段名称我们之所以用电脑而不是手机来做数据生产管理系统，是因为在电脑上有更大的屏幕来呈现内容，键盘鼠标

7、精准快捷地操作也能提高效率。如果我们仔细分析每个步骤用户的需求，就发现并没有合理地利用电脑大屏幕的优势。对于步骤1选择待处理条目而言，因为用户要处理完所有条目后才能提交，因此最好能一目了然的知道哪些条目需要处理，哪些不需要。可以非常方便地选择待处理的条目，用列表呈现更好。条目条目1:待编辑条目2:审核不通过条目3:审核通过条目4:待编辑条目5:已完成条目7:待编辑对于步骤2查看附属内容绝大多数都是在对条目主体内容进行编辑之前查看,处理过程中偶尔需要打开看一眼。因此不需要一直展现占据空间。应该提供隐藏,这样能给真正需要展示大量信息的步骤3处理主体内容留出更多空间。默认显示附属内容主体内容牌附属内

8、容五、优化方案经过以上分析，最终得到条目编辑页的优化方案。1 .去掉全局导航，提供返回工作台按钮。给用户长时间处理条目的沉浸环境，也给真正需要展示的内容留出更多空间。2 .提供工具栏。不同的角色有不同的操作，后续可能会增加其他操作。弹性的工具栏区域可以满足以后的扩展。3 .条目改为列表。显示每个条目的状态，帮助用户一览全局，快速选择应该操作的条目。4 .附属内容可显示或隐藏。将更多空间留给主体内容。1 .去掉全局导航，提供返回工作台按钮给用户长时间处理条目的沉浸环境，也给真正需要展示的内容留出更?G承息件任务名称9DQewMrri保4本次2 .提供工具栏不同的角色有不同的操作，而且后续可能还有

9、扩展。弹性的工具栏区域可以很好的满足该需求1 SftlK2巳霓7问痔4博需3已先8 HW*字段名律xxxxxxxxx字段心样XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXCCOOOOOOOOOOOOOOOCKKXXCKXMXIOCOOOOOOOOCXXXXXXXXXXXXX .xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxooouoa3 .条目改为列表显示每个条目的状态，帮助用户一栏全局，快速选择应该操作的条目字段名稗,优化后的条目编辑页与Keynote的界面神似，我在设计前并没有想到去参考办公软

10、件。icKixocuicoxotKa*.tJOicnitoxcAJWUWUMUUOJralUWJUWUUUlVMQUUDUUWJUUMKnAUJUlrIV条目编辑页 .MIS9I*thMx. m只能说制作幻灯片的步骤抽象后和条目编辑的步骤几乎一致。另外如今的网页早已不是纯粹展示信息的地方,随着前端技术发展,大多数SaaS其实和本地软件的交互、功能一样复杂。所以网页和本地软件的边界也越来越模糊。I工作台的优化相对来说更简单。根据产品规划，很长时间内我们都不会增加新的大模块。左侧导航优势是利于扩展，但占用的面积过大。改成顶部导航后,留给主任务与子壬务列表的空间更大，利于各种角色监视任务进度，或者选

11、择某个任务去执行。优化前的主导航主任务与子任务的列表六、结果反馈该优化上线之后得到了数据生产团队的夸奖，并且上线之后一年功能迭代没有调整整体框架，说明我指定的框架扩展性不错。在经历这个项目之前，我好久没有做B端产品的设计。为了锻炼我的B端设计技能，我特地没有去网上看相关的设计经验文章，或者找竞品分析。学习别人的思路和方案难免也被别人的框架给固化。要知道不是每次都有竞品可以分析,总会涌现出新的平台和产品类型，有能力应对新平台没有竞品的情况，才是真正厉害的设计师。通过这个项目我掌握了不同角色的任务分析，用户任务的抽象，根据步骤的需求和内容类型决定模块的大小和控件。相信这些技能以后也可以复用在其他新型B端产品的设计。