文中可能会出现较多跟业务相关的词汇，请各位见谅，我尽量精简...重点说设计思路。
背景
什么是流程？
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出来后我一度以为没啥问题了....
- 根据用户的反馈调整设计的方向，有时候并不是新的展现方式就是合适的，传统的方式稍加改造，可能更加适用于现有的场景，比如发布内容的展示，最后还是回归列表的样式。
- 如果是新的设计，设计师有比较大的主导权，但是如果是改版设计，有时候仍需要兼顾新老版的用户习惯问题。
- 业务的设计，不需要找最新颖的，但求最有效的，当然两者结合最好啦~
后记
即便是现在有了第一个终稿，但是看上去仍然存在着一些问题，也在想通过一些方法进行优化，如果大家有建议，请多多指教，谢谢！
网友评论