设计迭代版本那么多?怎么管理?

在交互设计师的日常工作中,一定会经常遇到产品迭代带来的设计版本管理问题。无论是产品从1.0进化到1.1、1.2甚至2.0、3.0,抑或是为了上线某功能而进行了三四次交互评审分别对应的设计方案,这些情况下交互设计师往往都需要同时查看、管理多个设计文件。在交互评审或是技术评审时,每当被团队的其他成员问到做出这般设计决策的原因时,在一堆画板,或sketch文件中来回切换实在不是一种优秀的工作方式。

目前现有的设计工具软件对于迭代或版本管理必能没有一个针对性的解决方案,往往都集中在“文件传递”和团队协作编辑上。CHI2018会议上,UW HCDE与Adobe Research联合发表了一篇专注于设计迭代工具的论文(Charrette: Supporting In-Person Discussions around Iterations in User Interface Design, https://dl.acm.org/citation.cfm?id=3174109)

 

目前设计工具主要提供两种设计迭代的方式。

  • 一种是提供明确的,包含视觉、可浏览的编辑序列的设计历史(记录)。这些工具被设计用于记录编辑操作的历史,而不是管理特定的、编排好的设计迭代集合和备选方案及其配套反馈。
  • 另一种方法是版本控制。类似Git的标准工具的主要目标是帮助用户明确地跟踪正在进行的工作版本或迭代。然而,大多数此类版本控制工具专注于如何合并编辑(通常是来自多个协作者)或回复到以前版本之类的任务。(尽管此类工作的确较为常见)

一个更典型的问题是,设计师试图管理一个结构松散的零碎设计集合(如设计文件中的各个画板),这些画板经过多次迭代发展而成。这些迭代经常包含许多并行演进的替代方案。为了方便他们的设计工作和评审会议,设计师经常需要从设计历史的不同角度来查看和参考给定设计的几个迭代或备选方案。这类型的操作在多数需要用户维护整个版本的可视管理工具中非常繁琐。


上述内容就是对论文原文的摘录+介绍了,原作者针对这个问题,提出了一个叫做“Charrette” 的系统,它用于跨产品、工具地向设计师提供迭代版本管理的解决方案。我搜了一下知乎,目前还没有介绍过相关内容,大家感兴趣可以去Adobe的blog查阅了解一下,“Charrette” 系统的具体信息以及论文中实验内容也不在此赘述,想了解的建议去阅读一下原文。

作为一个有过几段“从0到1到不断迭代”经历的见习交互法师,我对于论文中描述的“Charrette” 系统并不看好,主要原因是其仍然停留在“插件化”的解决方法。无论这个系统的最终形态如何(软件or插件),它解决迭代管理问题的思路依然是基于现有产品的基调,增加“快照”(snapshots)并链接至已保存的诸多迭代版本历史记录中。

在我看来这就还是以典型的工程师思维解决问题:

  1. ——发现了迭代管理不便这个问题
  2. ——思考怎样提升迭代管理效率
  3. ——直接添加迭代版本管理功能
  4. ——无法在现有工具中实现/其他原因
  5. ——将迭代版本管理功能削弱成迭代快照管理
  6. ——done!

那怎样才是解决设计迭代管理问题的合理思路呢?我尝试给出一个:

  1. ——发现了迭代管理不便这个问题
  2. ——分析问题出现原因
  3. ——发现根本原因是“互联网产品迭代设计”的普遍化
  4. ——归纳直接原因是现有设计工具原生不支持迭代设计
  5. ——重构设计工具

其实我也是因为读了这篇论文才意识到这个问题——现有的各类设计工具没有原生支持迭代设计解决方案的。无论是Photoshop或是AI、Sketch,其进行作品创作/设计的核心逻辑里是没有时间概念的,有的只是空间概念(多图层、多页面,“蓝湖”等工具的空间概念在于多协作者)。

这里就需要强调一下“迭代设计”与“传统设计”的差异了。PS一张海报、AI画一个icon、Sketch做一个原型甚至是C4D渲染一个动效,都是传统意义上的做一个作品,工作流程会伴随着作品完成而结束。

而迭代设计是没有工作结束的状态的——同样,迭代设计的产品也不会有设计完成的状态的。一款迭代设计的app,用户体验到的设计不是最终的设计,而只是“上线版本”而已;当前进行的工作也只是当前态而已,会因为产品经理提出新的需求而继续发展迭代。因此,一款迭代产品的设计不应该是时间停滞的,每个时期的历史版本与备选方案都是整套迭代设计的组成部分。因此,迭代设计的工具软件最需要的功能应该是时间轴。

不,应该是时间树。

前面已经提到,迭代设计不是单线程渐进式的工作,在各个历史节点上可能存在着多个迭代的版本,而这些版本也都可以继续延伸出去以影响后续版本的设计。因此不但要在设计工具中引入“时间”概念,而且还不能是单一线性的时间轴,应该是多轴线组成的类似树形图的形式。因此我暂时将其称为“时间树”。

可以假想,存在这么一款设计工具软件,它从一个最基础的prototype开始,不断向后发散,定义出多个迭代版本并且能进而发展为多支“迭代线”,每当需要历史版本进行审查、反馈时可以拖动时间轴浏览这个树形图上的所有版本。这将极大程度上地提升了设计师进行迭代设计的效率与整体性。当然,也会给设计工具的定义带来新的难题,如:需要增加方向的定义以区分“时间”属性和“空间”属性甚至是“操作体验”属性。因此对于“时间树”的设想,还需要进一步的深入与细化。

至少可以肯定的是,目前现有的各类设计工具对于迭代设计的支持都很有限,也许是“时间树”,也许另一种形式的“snapshot”,因为无论如何我们都亟需一种更高效的迭代设计管理方案。

2 thoughts on “设计迭代版本那么多?怎么管理?

发表评论

电子邮件地址不会被公开。 必填项已用*标注