文中可能会出现较多跟业务相关的词汇,请各位见谅,我尽量精简...重点说设计思路。
背景
什么是流程?
2000质量管理体系标准中对流程的定义是:“流程是一组将输入转化为输出的相互关联或相互作用的活动”。我们日常的工作都可以看做是一个个流程的集合,或小或大~输入可以看做是我们的行为,输出可以看做是拿到的结果,所以,一个流程最基本的组成,可以分为输入、过程、输出3部分。
同样,在研发领域,当一段代码,一份配置需要转化为真实的功能供用户使用,同样需要经过一系列发布的动作才能实现,这个过程,可以看做是一个发布流程,所以发布流程实际概括起来很简单,代码构建、测试、正式发布,然而真正实施起来,却包含了各种各样的环节和操作,我需要做的,就是将这些环境和操作尽量清晰的展示给用户,指导用户快速的解决问题,完成发布(下班回家....)
面临的问题
接手这个需求,在经过对老页面的观察后,发现:
- 老页面信息量太多,产品的发布页面包含了跟环境、代码分支、操作记录、发布操作、发布内容、待发布内容等各方面的信息,用用户的话来说,处处是链接,处处可点击,用户在这里找不到重点,很容易迷失...
- 老页面发布流程不清晰,并不是我们想象的一条线走到底的页面指引...初次使用的用户都必须经过说明才能理解。
- 业务比较复杂,虽然这听起来像一个借口,因为这里包含了整个发布的流程,各种情况都有可能在这里发生并展示,的确有点复杂..(想了解多复杂的可以找我,讲一天都可以的....).
- 竞品少,如果单拿发布来说的话,像Heroku这种商业化工具也有在做,但是这类工具并不像任务管理工具那么普遍,少有竞品可以拿来分析。
- 用户习惯 产品的发布页面是一个矛盾点,大家似乎都不喜欢,但是很多人表示用习惯了.....很多用户的操作行为,在没有更好的优化之前,需要慎之又慎。
设计之始
项目组刚开始的想法是想实现多个相同的发布流程并行,不同的发布之间可依次继承,从而达到一个持续集成,持续发布的构想,这就要求:
- 清晰的展示每个发布流程的内容。
- 每个发布流程之间的继承关系需要明确化。
项目刚开始的时候,我的头脑风暴的比较厉害,各式各样的流程图都想象过....
例如:
脑暴1:
前3个脑暴的设计思路一致:通过一个总流程来说明总体进度,然后每个发布流程各自行进自己的发布进度,通过版本标签标识不同的发布流程,通过箭头来标明版本之间的继承关系。
脑暴1
脑暴2:
脑暴2脑暴3:
脑暴3脑暴4:
一个页面多个流程图看起来会很繁杂,如何解决版本与总体流程的对应关系,我想起了《仙剑4》的那张对战图:
screenshot
3个人轮流打怪,右上角会有对战的进度条,3个人的位置通过坐标的方式显示....这跟我这里的流程场景有相同之处,所以,尝试了第4种方案:
单个版本的内容不再有单个的流程,统一通过坐标的方式显示在主流程图上。
脑暴4
脑暴5:
前3个方案最大的问题就是发布内容没有办法展示全面,所以只是尝试性的试探,第4种方案虽然界面精简了,但是用户却反馈,每个版本需要上下来回找,看起来并不是那么直观..为了能够把发布的内容清晰的放出来,尝试了第5种。
脑暴5
这期间我对发布内容也尝试用新的展示方式去解决,有点类似于轻量化列表这篇文章提到的样式,然而效果并不好。
初稿的形成
新的展示方式的尝试带来的反而是页面线条的增多,用户反馈发布内容更加不够清晰了~
经过第一阶段的尝试,发现第4和第5两个方案接受度明显高于前3个,分别对齐着手优化:
脑暴4-优化
对于第4种方案,轻量化版本的视觉效果,同时减少内容展示的复杂度:
脑暴4优化
脑暴5-优化
对于第5种方案,直接移除头顶上的大流程,改为各个版本展示各自的进度,没有了大流程的干扰,各自版本的信息也能清晰展示,当然,发布的内容也尽量的减少线条等视觉干扰因素....
脑暴5-优化
两个方案PK的结果,大家偏向于方案5,毕竟不需要像4那样上下来回查找版本所处的位置,再加上一些筛选功能,完全可以只聚焦到一个版本的发布上面。稍加着色后,脑暴5成为第一个展示给开发同学的方案。
草稿1
第一个草稿方案对流程的显示做了区分,可以看出,左边是流程图,右侧是当前节点状态和日志等信息,而流程的操作紧贴在流程的下方,操作后面跟着发布的内容。
这个设计相对于之前的设计,信息有了明显的分区,并且视觉效果看上去也好点。
草稿1
方案变动与当前终稿的形成
需求就像夏日的天气,刚才还是晴空万里,转眼就给你换了个脸~
在形成第一份草稿之后,项目组对发布的方案进行了变动,取消了多个版本同时发布的场景,简化成了只能有一个版本在发布。
其实草稿1的方案依然可以支持这种变动,然而,用户对于这个方案的反馈,也让我意识到了新的问题:流程图与状态的显示距离太远,意味着视觉移动范围很大,然后相关的操作又在流程图下方,就导致了视觉的来回移动,很不舒服。
视觉移动
基于用户对这个问题的反馈,加上新需求的添加,我开始尝试,是不是节点的状态与操作直接靠近节点就好了?最简单粗暴的告诉用户你所处的位置,你的状态,你需要的操作,于是,新的版本又一次出炉:
终稿1这个方案很简单,任何节点的相关信息就放在当前节点,你在的地方,就是你需要关注和操作的地方。这个方案在布局上并不是那么美观,但是在跟用户展示的时候,却收到了正面的反馈.....(用户啊!用户!)
经过视觉处理后,如下所示:
发布1整个设计过程的回顾
先抛开复杂的业务逻辑不谈,我们先来看下,一个流程设计要素是什么?
- 清晰的流程图展示。
- 整个流程图的概况。
- 当前用户的位置,流程节点的状态。
- 流程的走向。
- 流程相关信息的提示。
- 流程节点与操作的关联。
- 视觉上的关联性。
- 流程实体内容的展示。
而整个设计,是基于老版本的新设计,可以理解成破而后立的过程,这就需要:
- 设计师首先通过各种途径的脑暴,打破老版本可能给你带来的影响,尝试去发现新的展示方式,脑暴的过程甚至不需要考虑上面我们提到的要素,有想法了就先画出来,我们需要脑暴给我们带来新的设计灵感。
- 在脑暴之后,开始收敛方案,结合业务考虑每个方案的可实现性和局限性。
- 跟业务方一同筛选出来的方案都找些用户说下感受,用户的感受可能会告诉你一些你没有发现的点,比如,草稿1出来后我一度以为没啥问题了....
- 根据用户的反馈调整设计的方向,有时候并不是新的展现方式就是合适的,传统的方式稍加改造,可能更加适用于现有的场景,比如发布内容的展示,最后还是回归列表的样式。
- 如果是新的设计,设计师有比较大的主导权,但是如果是改版设计,有时候仍需要兼顾新老版的用户习惯问题。
- 业务的设计,不需要找最新颖的,但求最有效的,当然两者结合最好啦~
后记
即便是现在有了第一个终稿,但是看上去仍然存在着一些问题,也在想通过一些方法进行优化,如果大家有建议,请多多指教,谢谢!
网友评论