导语
流程图是大家非常熟悉的工具,可以用于编排计划或梳理逻辑。那么在 B 端产品中,流程图功能常见于业务的自动化运行配置,通过快速复用,大幅提高任务效率。而我在近期的项目需求中,遇到了很多关于流程画布设计的真实场景。因此进行一次复盘,旨在深入浅出地总结一些体验设计经验方法,希望能为日后类似的需求设计带来一些可借鉴的提效思路。
流程画布可帮助运营人员制定复杂的任务流程,从而按既定的顺序、在合适时机触发合适的动作,完成自动化执行,并且可以跟踪执行效果。
简而言之,画布需要解决的是:先做什么再做什么;不同情况下做什么;事情做得好不好。
来源:GrowingIO
来源:神策数据
来源:visual paradigm
而标准运维平台的流程画布,是通过编排作业插件来完成运维任务,面向一些底层系统的技术运维人员,提供高效率、高复用的自动化执行服务。
图0-1 标准运维流程画布界面
标准运维流程画布的用户主要分为两类角色:「规划者」与「执行者」。
规划者熟悉运维插件业务,主要负责规划任务流程,因此绘制流程图的操作体验对其尤为重要。
执行者负责控制流程实际运行和异常跟踪,并不关心内部构建细节,因此,后期的任务状态和信息检索才是他们最关注的。
那么,在流程画布的整体设计优化中,我们也需结合不同角色的诉求,打造更贴近用户习惯的体验。
基础画布由绘图区域、画布工具、图形库组成,根据产品实际业务还会衍生一些特有的功能板块。
绘图区域:在有限的画布区域内,承载各类型任务节点、开始/结束节点、分支判断节点、步骤间连线等图形,展示流程图最终配置效果
画布工具:包括缩放工具、复位、小地图等基本功能
图形库:图形是组成流程图的最小元件
绘制流程图最起码需要有平移、缩放、拖动等鼠标操作,复杂场景下可能配合进阶操作来提高绘制流畅度。
画布平移:通过抓取画布平移,调整页面可见范围内显示的节点内容;或通过缩略图快速定位,调整视野
画布缩放:缩小可宏观掌握流程结构,放大可聚焦操作目标
拖放节点:模拟真实世界中放置卡片或积木的认知,将流程组件自由拖动至画布内进行组装
连线:使用带方向的线条连接不同节点,形成顺序
以上这些都是绘制流程图的基本概念,本文就不多赘述了。接下来,我将结合标准运维等 B 端流程画布实际案例,总结如何通过优化设计提高流程画布编排效率的思路和方法。
流程画布在业务体系中主要体现以下三个目的:
1.构建业务流程——编排任务顺序,明确先做什么、再做什么
2.梳理分支关系——不同情况下,执行什么不同步骤
3.快速定位问题——查看真实执行反馈,跟进异常
当规划者通过绘制流程图来构建业务执行计划时,最根本的诉求是能按照「预期目标」快速、有序地完成编排。
然而我们画过流程图就知道,即便有「预期目标」也并不代表我们在一开始就有精准的每一步顺序,可以一气呵成。也就是说,我们会在过程中不断修正步骤、改变布局。那么,如果流程编排的操作太生硬、不直观,就会导致构建效率低,体验不顺畅。
比如,当发现节点位置需要调整却只能先删除节点再重新添加配置,无疑增加了修改成本;
图1-1 调整流程节点的操作现状
当局部增删节点后布局可能发生重叠、挤压,若只能通过一个个节点的挪动来调整位置,也会非常费力。
图1-2 移动节点排布的操作现状
要解决这类问题,靠的是我们对细节交互反馈的把握。针对以上症结,我们的优化方案从三个角度入手:
当用户拖拽一个游离节点到已有连线上时,表示用户需要在此插入节点。通过节点两端的加号图标预示添加功能和连线位置,松手即可在指定位置快捷插入新节点。
图1-3 插入节点交互方案
当用户想要改变某个节点的位置时,只需一键解绑,然后拖拽插入新的目标位置即可,不会因删除而丢失原本的节点配置信息。
图1-4 解绑节点交互方案
批量操作是常见的提效手段,同样也适用于流程编排的交互场景。当用户在绘制期间因反复修正节点位置而导致布局变得不规整时,为了便于阅读通常需要重新排列。我们优化原有的「框选功能」基础上增加了键盘 shift 辅助操作,参照资源管理器等场景的「按住 shift 多选」习惯,提高用户快速圈定移动范围,从而批量完成重排。
图1-5 通过拖动绘制矩形,框选节点
在批量框选移动的基础上,我们进一步为「懒人」用户提供自动排版功能,依靠前端技术层面的复杂计算,帮助用户直接将节点对齐,并保证最起码的间距,满足流程的易读性。
图1-6 自动排版功能
基础的流程图绘制,分支条件通常只是「if-then-else」结构,分出「是」与「否」两个支路,我们可以分别配置支路下的流程。然而在复杂业务场景下,分支很可能不止两条,比如标准运维中使用的是「switch」结构,允许配置多个条件支路。
为此,我们要重新思考规划者对于「分支」的认知:同一组分支条件之间必然有内在逻辑联系,并非独立存在的。这种情况下,若还要求规划者逐一添加连线、分次设置条件,无疑是非常啰嗦的。
图2-1 分支独立配置的操作现状
通过理解分支条件的关系,我们从更宏观的角度进行优化设计:
当需要配置分支,配置的就是该组所有分支条件。这样一来,用户能从更宏观的角度,同时把握全部分支结构,避免了在画布中因各分支向不同方向发散而造成的查找障碍。
图2-2 网关配置交互
根据条件之间的逻辑联系,我们知道通常同一组分支会围绕相同属性作不同值的判断分流。因此,我们将属性条件并列出来进行针对性配置,能让分支逻辑更明确。
图2-3 条件语句设置交互
这样一来,还能进一步完善条件冲突校验,在判断出现重叠时,提示更清晰直观。
图2-4 分支冲突校验
对于执行者而言,看流程图时最主要的任务就是查看执行效果,定位问题。而二维布局的流程图画布,在查阅节点时就存在一定的难度:一来节点顺序大多不是按同一方向规整排布的,二来分支的层级结构也不能保证对齐性。
面对这些因「图」的特性带来的固有难题,我们引入了「树」结构。这也是我在流程画布设计中遇到的较为棘手的难点。
那么,在解决问题之前,需要真正理清楚:什么是图,什么是树。
在计算机数据结构里,「图」和「树」都是用来表示非线性数据的,它们共同的特点是:都由节点和边组成。
但它们之间仍然有较大区别——
「图」的节点可以有多条入度和多条出度,但「树」的节点只能有一条入度 (注:在流程图场景中,我们讨论的「图」自然都是有方向性的,即属于「有向图」;入度表示输入节点的边,出度表示从节点输出的边)
「图」的路径可以循环 (有回路),是表示一种「网络」;但「树」的路径不可能循环,表示的是一种「层级」
「树」是一种有向无环图;也就是说「树」一定是「图」,但「图」不一定是「树」
正是由于「树」具备的明显层次性,我们可以运用「树」来提高节点检索的效率。
然而,如上文所述,「树」一定不完全等同于「图」,因此我们必须明确一个前提:流程图是无法完全转换为树结构的,画布中增加树结构仅仅用于辅助检索,其中须有一定的取舍。
回到案例中,我们通过图树结合来解决流程画布在不同场景下的信息查阅问题。
由于流程图的特性中必须包含「开始」「结束」节点,故而至少可以提取出首个节点作为树结构的「根节点」,很直观地拎起来形成基础的树型。
再由于标准运维的业务规则中,不支持从两个插件同时流向另一个插件,即大部分情况下每个插件只能有一个输入,所以大大降低了转换成树的难度。
由此可知,基础的单线流程图完全可以无缝转换为树结构。
图3-1 线性图转换为树结构
接下来解决分支的转换关系。流程图的分支最后必定会聚合到一处,从而形成「环」,在树结构中是不存在的。我的处理思路是引入一种特殊的缩进,结合连线形成视觉上的「首尾包含」关系,来表示「环」。虽然确实打破了传统「树」结构的定义,但保持了纵向布局和层级结构,能够达到快速检索的目的。
图3-2 分支图转换为树结构
既然是「图」,就总归逃不开循环的可能。在标准运维中还是有少数极端案例出现分支回退或分支嵌套汇聚的情况。假如在树结构中硬是要把循环执行的节点实实在在画下去,那就一定会出现重复的节点,无疑造成了信息干扰。
图3-3 循环图不应重复在树结构中绘制
我联想到程序设计中的「指针」概念以及(不太提倡的)「goto」语法,在树结构中将指向「过去」的节点看成是一种指针,而非实体节点。
简而言之,这类「节点」在树结构中是不能单独存在的,选中它的时候立即定位至它所指向的被循环执行的节点。
图3-4 运用指针实现循环图转换为树结构
如此一来,树结构中也不会因为增加额外的节点,造成与流程图不一致、信息过度干扰等问题。
通过上述三重处理,我们把流程图顺利转换为树结构,仅仅丢失了极少部分「回环」关系的直观性,而大大提高了对节点顺序和节点状态的快速检索定位能力,顺便实现了快速切换节点查看详情的功能。
以上就是我在流程画布相关设计案例中的一些心得复盘。对于设计师而言,面对一个看似成熟的功能,还是需要保持一种换位审视的态度,从细节上提供更多可能性。