行业研究 | 几万人都在用的研发效能产品设计改版心得，数字化研发协同平台体验升级
共 3896字，需浏览 8分钟
·
2021-08-28 01:30
欢迎来到专业设计师学习交流社区
三分设｜连接知识，帮助全球 1 亿设计师成长
转自：Alibaba Cloud TxD
编辑：张梦如
共 3637 字，预计阅读 10 分钟
一. 业务背景&问题定位
Aone（Alibaba One Engineering System），数字化研发协同平台，是阿里解决研发过程中跨角色、跨组织、跨地区的协作问题，通过数据驱动、度量分析，解决阿里庞大组织研发效能问题的平台。AONE 目前涉及到的协同角色多种，包含项目经理、产品经理、前后端开发、设计和测试等。
本次改版的主要设计目标是解决 AONE 的三个核心痛点问题，提升用户体验：
01 体验一致性欠缺，用户难以建立统一心智；
02 用户视角单一，协同流程有断点；
03 产研协作和资产沉淀之间有断层，研发产出无法有效的沉淀和跟踪管理。
二. 设计思考和策略
针对以上痛点，设计策略拆分为对应的三个层级：
01 基础操作层-保证产品体验的一致性；
02 实践效率层-完善多角色视角的场景化诉求，提升多工种协同的工作效率；
03 价值增益层-解决 AONE 三方协同断点的问题，完善产研一体化闭环。
01 基础操作层-保证产品体验的一致性
一致性是体验设计中最重要的原则之一，特别是对于 AONE 这样涉及多角色多功能模块的复杂产品。对于用户而言，体验一致性的提高可以降低用户的操作时长及错误率，降低学习成本，提升用户的满意度；对于产品设计及开发者而言，保持体验一致性可以提升开发和维护效能，产品模块的可集成性、稳定性和可延续性更高。
为保证产品体验的一致性，设计从三个方向入手：
1）视觉感知一致性：保证页面呈现的视觉元素特征及文字图形的一致性，包括图标、文本、颜色、字体、间距、尺寸、组件等基本样式和组件元素，并由视觉同学沉淀为组件和规范，便于后续统一管理和复用。
2）行为感知一致性：保证用户在产品中交互、流程操作的一致体验，通过统一产品框架、布局、核心操作区域、流程顺序、组件联动和页面切换等。
3）认知一致性：通过考量用户习惯、产品调性、品牌建设等建立用户可感知的整体产品形态，以及产品与用户认知的一致性。
02 实践效率层-完善不同用户角色的场景化诉求，提升多工种协同的工作效率
作为协同类产品， AONE 涉及到的用户可以分为：
按工种划分的一线角色 （如产品、研发、测试等）。一线角色人员大多聚焦在单一事项的处理，如产品经理更关注需求的推进，研发更关注未完成的缺陷，测试更关注测试计划的执行结果。
按权利层级划分的管理角色。对管理者来说，团队事项的整体进度、风险预判以及人员兵力分布则是他们关注的重点。
不同角色的用户对产品的诉求不同，沿着从用户场景出发的思路，我们的设计目标和对应的设计策略也有所差异：
针对一线用户角色，快速处理工作事项、提升操作效率是首要目标。基于这个目标，设计策略主要分为四步：
1）根据用户工作场景补充缺失的功能模块，满足多角色用户千人千面的诉求。
以工作台首页为例，我们新增了管理视角下的团队事项卡片、 PM 视角下的项目进度卡片、产品视角下的甘特图工作事项卡片、研发视角下的应用变更卡片等。在用户进入工作台首页时，根据其岗位信息对当前功能卡片进行组合，推荐给用户最满足他使用场景的工作台，精准匹配角色诉求。
2）简化操作链路和协同链路，补齐流程断点，提升用户操作的流畅性
我们将用户的操作链路又细分为单一角色用户的操作路径和多角色之间协同的路径，从点到面的对用户的操作流程进行梳理和简化，逐个解决过程中造成操作效率低下的断点问题，提升产品的易用性和流畅性：
单角色操作链路：以产品经理为例，旧版本中，产品经理分享需求的路径是：撰写需求->保存需求-> 最大化详情页->复制详情页链接->钉钉分享链接。最大化详情页和复制详情页链接是造成操作步骤繁复的断点所在，产生原因在于抽屉式的详情页结构不支持用户直接复制链接，为了能将具体的需求分享出去，产品不得不每次都重复的做最大化复制链接的操作。为了解决这一断点问题，我们在详情页新增了一个分享需求的按钮，将分享的操作步骤从三步简化为一步。
多角色协同链路: 以需求为例，同一个需求可能会在产品经理、设计、研发和测试之间来回流转，过程中产生的问题和动作也都会记录在需求详情页面的评论模块内。老版本中，评论与操作记录被分拆为两个 tab ，用户需要不断的切换以查看两边对应的内容。针对这一场景，新版的设计将评论内容与操作时间轴合并为需求动态 （也支持用户只看其中之一），更整体的将需求的变化过程呈现给用户，助力用户快速定位问题。
3）增强产品自定义的能力，满足个体使用差异；
对比旧版 AONE ，新版的设计支持用户自定义工作台布局、工作台卡片、工作项列表视图以及看板卡片展示信息等，用户可以自定义设置更符合个人操作习惯和业务诉求的专属 “定制化” AONE 。
4）以自动化能力替代高重复性操作，降本提效
自动化规则是一种能将产品内重复性较高的行为通过设置触发对象、触发条件和执行动作来完成自动化流转的功能。用户可以通过自动化规则设定符合自己业务场景的全自动流程，减少重复性的操作。但由于操作复杂，老版 AONE 中使用该功能的人不多。在新设计中，我们和产品一起对自动化规则的使用场景进行了模版化提取，并用自然语言描述的方式将多操作步骤融合简化，降低用户对专业名词的理解，使用户快速上手，提升操作效率。
针对管理角色，建立对团队和工作事项的掌控感是首要设计目标。在新版设计中，设计按从粗到细的维度分别在工作台、项目、迭代等核心页面模块补充了针对团队兵力分布、整体工作事项进展、项目进展和迭代进展的统计模块。从整体到局部的增强管理者的掌控感，助力他们清晰精准的进行问题定位、兵力排布以及下一步的方案制定和评估。
03 价值增益层 - 解决三方协同断点的问题，完善产研一体化闭环
随着阿里集团内产品研发团队分工的不断深化，各研发角色都开发了自己的研发工作平台，比如沉淀设计稿的 D-One ，前端工程师的 DEF ，无线工程师的摩天轮，数据工程师的 Dataworks ，甚至产品经理设计 PRD 也基本使用语雀文档，也就是说，产品研发过程中的很多工作并不在 Aone 上完成。这样的现状使研发协作过程与研发产出形成了断层，研发产出的过程资产无法被有效的统一沉淀和跟踪管理。
我们希望 AONE 是这样一个平台：贯穿研发协作的起点和终点，从需求出发，记录协作中各角色的行为和产出，所有的过程资产都可以在一个平台追溯，真正实现业务场景和人效资源的数字化管理。本着这样的设计目标，设计与产品一起调研共创，通过需求的“研发任务”将各研发平台与需求集成，所有需求的参与者都可以通过研发资产进行产出的交付和过程的跟踪管理。
以设计资产为例，设计师在完成设计稿后，将设计稿上传至 D-One ，再通过 AONE 需求的研发资产将 D-One 设计稿链接与原始的需求进行绑定，所有参与当前需求的角色都会收到通知，上游产品经理可以清晰感知当前需求进展的阶段，下游研发可以开始根据设计稿开始开发的准备，而项目经理或管理者则可以通过完整的产出和工时记录明确当前需求状态是否健康，人员投入是否充足等，快速作出风险的预判和应对准备。
三. 总结展望
01 反馈和总结
在新版 AONE 上线半年后，我们做了一轮调研统计，从回收的用户反馈来看，新版所有指标都高于 6 分及格线，界面布局和视觉体验两项更是高于 7 分，其中有大约 60% 的用户都给到了 8 分以上的高分，整体改版效果较为显著。值得一提的是，通过研发资产关联，半年来已经有超过万份研发过程资产沉淀在了 AONE 上。
在整个的改版升级过程中，我们分别对踩过的坑和可复用的经验做了总结，希望能给有相同诉求的设计同学带来一定的帮助。
踩过的坑：
1 简化功能的初心却影响了用户原本的操作心智，产品改版一定要平衡用户原本的使用习惯；
2 避免陷入单一的需求中，需要带入更全局的视角来完善产品的体系化建设，站在业务和用户的角度多维度思考；
3 除了通用能力的建设，要更多考虑结合技术的手段提升产品的核心竞争力。
可复用的经验：
1 系统性的解决基础一致性问题，完善体系化建设，提升工作效能；
2 多角色协同的产品按用户角色细分场景和目标，分别对应不同的设计策略；
3 完善的产品数据分析能力可在后续帮助设计师快速定位问题。
