认识达内从这里开始

任何一个网站或者app软件的设计工作都必须配备相应的软件来完成项目任务的。今天，我们就一起来了解一下，Atlassian设计体系都具有哪些优势和特点。

1.以小为始

一个版本的Atlassian设计体系只包含20个静态HTML文件，由我桌下的那台MacPro充当服务器。没有模板，没有版本控制，我亲自动手为每一个组件编写HTML，并将线上产品的CSS直接导入过来作为样式表。虽然这一版本更新起来非常困难，而且不具备扩展性，但它也足够向当时的团队展示设计体系的基本价值了;我因而得到支持，并得以将更多时间与精力投入其中，逐渐摸索到了正确的道路。

反之，如果从一开始就考虑到各种扩展性问题，那么我们很可能需要花费数倍的时间来完成起步阶段的跨越。如果你刚刚开始构建设计体系，建议你不要沉迷于无缝、完美的流程和机制，取而代之的是简单快速地起步，验证价值与方法，并保持迭代。

2.重在质效提升，而非控制设计

如果你认为构建设计体系的目的在于防止其他人“犯错”，防止他们破坏掉只有你“有权”定义的规则，那么你们的体系构建工作很可能是在不正确的观念之下进行的。

设计体系的目标是提升团队的设计质效，帮助每一名设计师更加合理地进行设计决策。

你的工作并非将规则强加给他人并监督他们执行。反之，要将设计体系视为在公司内部实现“设计民主化”的工具。只有这样，人们才会有意愿参与其中并进行贡献。

务必记得，设计体系是一种强化工具，而非用于控制设计的监管手段。

3.避免同步进行重设计工作

不要将设计体系的构建工作看作是产品重设计的契机。一边进行着体系化定义，一边对产品进行重设计，这会极大地拖慢工作进度。更合理的做法，是先对产品当前的状况进行记录与清查，包括合理与不合理的模式在内;完成标准化定义之后，再回过头来进行优化工作。

在Atlassian，我们曾经多次试图在设计模式文档的基础工作完成之前对产品进行重设计。诚然，设计模式的定义与文档化工作需要花费大量的时间，但以此为基础进行新一轮的设计迭代，整体进程会更加轻松和高效。

4.跨职能寻求支持

设计体系的创建工作并非学校里的课业练习。如果终无人使用，或是无法有效提升设计质效，那么我们的工作就是浪费时间。

只有让其他人了解你的工作并参与贡献，你才能得到越来越多的认同与支持。这一点对于设计体系工作非常重要。

2013年时，我们团队当中的设计师与工程师占比大约在1:15到1:20之间。直至如今，回想起这个数字，我仍然会感到惊悚;不过当时，我确实有试过将这种失衡的局面转化为工作中的优势，使工程师们更加认同设计体系相关工作。我会在新人入职当周做一些宣讲，每周有15人左右的样子;为了让他们从一天起就能对设计体系的目标与价值有所了解，我会给他们讲一些往事，譬如我们的产品当中曾一度存在着44种下拉菜单，而如今已经标准化为一种，它的具体使用方式应该如何如何。

经过那一年的宣讲，加上Atlassian的规模几乎每年都会翻番，我总共帮助了将近500名新人了解了设计体系的重要性及使用方式。同时，这项工作还在潜移默化当中扩大了设计职能在整个企业文化当中的影响力。

5.超越“设计规范”

设计体系不同于设计规范。创建一份包含了所有组件的Sketch文件或许相对容易一些，譬如所有的主操作按钮都有着相同的配色，或是统一使用8像素栅格等等。但应该在何时使用主操作按钮而非次级按钮?按钮中的文本应该采用哪种类型?主、次按钮同时出现时应该怎样布局?

设计体系必须针对这类规则性的问题提供解决方案，而不仅是记录规格规范。很多团队都忽视了这一点，致使设计体系的价值有所缺失。

正如前面提到过的，在2013年初，Atlassian设计团队的规模(约13人)相比于开发团队(约300人)来说还相对较小。明确提供设计模式使用规范的好处在于，工程师可以在设计师人力不足时独立完成大量的页面构建工作。这意味着在很多时候，设计师无需打开Sketch制作高保真设计方案，大家可以通过白板和脑暴直接确定功能流程，或是将更多时间用于上游高层面问题的处理。

6.少数人负责管理，多数人参与贡献

我们在Atlassian采用了集中式的设计体系管理机制，一方面允许每一名设计师参与贡献，一方面通过每三个月的轮岗制度从不同的产品团队当中抽调设计师与工程师加入我们的平台设计团队。在三个月的时间里，他们会对设计体系的维护工作进行大量的贡献;三个月后，他们回到各自的团队当中，成为设计体系的簇拥者与布道者。

节选：公众号：Beforweb

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!