设计体系和设计规范是一个东东么?

最近看了一本实用性很强的书,恰好也正在做这个。因为时间刚刚好,因为书刚刚好,因为抠脚大叔也刚刚好(深情状),咳咳,大叔在甚为兴奋的状态下很快的读了一遍,后来因为要做分享,所以又多读了两遍,每一次读都有不同的理解和感悟。但总结一句就是:规范也好,系统也罢,我们要记住做这件事的最终目的是为了提高团队效率,服务于最终产品,形式方法都可以因地制宜。后面附了这本书的中文翻译链接,希望大家也能有所收获。(因为是总结感悟,所以不做过多剧透)

Smashing Magazine上可以购买:

https://www.smashingmagazine.com/printed-books/design-systems/

总结的话写前头:

1、此书所探讨的是如何以体系化的方式推动设计流程,以及如何围绕特定的产品目标及团队特质来构建设计体系。

2、设计系统由多种模式、组织架构、团队文化、产品类型、设计流程等构成,其中设计模式就是我们所要探寻的重点内容。

3、设计模式不是设计规范,传统的设计规范就是字体、颜色、icon等更偏重于风格的定义。而设计模式指的是任何可复用的界面组成要素。在抠脚大叔理解看来,模式不是抽象的,而是你具体的业务和产品,例如:登录注册在每个产品里都有,但你的产品可能因为某种原因,一定要在注册的时候提交头像,那么你就可以基于你的产品来构建一个注册模式。

之前走过的路

我相信很多人跟抠脚大叔一样,给公司做过设计规范。翻阅之前的历史,从1.0.0到今年的4.0.0,总共迭代了4个版本,但其实大的改动也就是两个版本。第一版建立的时候,抠脚大叔是辅助,主要是公司一个设计师弄的,她用ps建立了公司最初的一版设计规范。当时只有两三个人,稍稍看看,记下几个关键色值就行了,规范问题也很明显:

1、基础规范仅适用于阅读,无法直接取用。

2、控件、组件、部件混在一起放在规范里,部件经常根据业务变化,导致规范变动频繁。

3、整个规范,不利于协作、维护、迭代,但因为当时人就两三个,这个问题暴露的也不明显。

所以抠脚大叔在2.0.0版本的时候,根据使用情况优化了几点:1、将文档和Sketch源文件分开,文档供查看,Sketch源文件供直接使用;2、将基础控件和业务控件分开,所谓的基础控件就是系统控件,如弹框、toast这类,业务控件,就是基于业务场景所沉淀下的控件;3、增加修订记录。现在看看,问题也是有的:

1、修改麻烦,改动一处需要更新两个文件;

2、协同工作效率差,更新需要通知其他人,不然会造成信息不对等;

3、业务控件越来越多,差不多的场景样式各式各样。 

这些是不是我们很熟悉的设计规范?字体、颜色、icon、控件等规范出来,基本上就是一个设计团队所拥有的所有标准了。我们所定义的基础控件,无非是将iOS和Material Design的控件做一个筛选,后来Ant Design出来后,我们因为有些页面是Web实现,结果变成,我们基础控件就是在三个平台之间寻求一个平衡,稍加定义让其更加符合我们的产品需求。

这本书的启示:

我们在设计什么?

其实在2.0.0版本做的业务控件,就是有意识在设计的时候把一些做过的页面收纳总结起来了,这样不用在同一个问题上,反复想解决方案。模式库存在的意义也是这样的,我们产品有四五十个功能,六个设计师同时在不同功能上做设计。谁能保证设计一个信息展示页面,大家能设计的一模一样?但是,虽然信息展示页面面对的业务可能不同,难道就不能设计成一样的么?书里说到,同样的信息架构,同样的功能,我们都可以将之归为同一个设计模式,尽管在不同业务场景可能有不同的外观需求和行为方式,但那只是模式的变体,而非不同模式。

收集的一些列表页面

我粗略的收集了一些列表页面,当然,列表只是它们的表现形式。而它们有的目的就是类似于小区公告栏一样信息展示。按照书中所写,我将页面按功能分类,分解它们的信息架构,给这个模式取了一个好记的名字“橱窗列表”,如下:

橱窗列表

为什么叫橱窗列表?起名在书中说了,要好记,跟功能挂钩,比起列表1、列表2而言,橱窗列表显然让人更容易记住。

所以回到最初的问题:我们在设计什么?

抠脚大叔认为,我们要理解真正的需求,设计不只只在解决问题,他还要看到真正的问题。就像现在大厂动不动就喜欢搞一套大而全的功能控件库,其实在某种程度上确实减少了我们做不必要的重复工作,我们要将更多的重心放在理解用户和需求上。

我们是什么样的团队?

什么样的团队,什么样的组织结构其实也影响着我们的设计体系。具体体现在设计体系的三个方面:实践规则(严格、松散);构造方式(模块化、整合化);管理机制(集中式、分布式)。(翻译取自译者C7210,文后附链接。)随后书中举出了Airbnb、TED和Future Learn的例子,

 维度划分

这个抠脚大叔很有感悟,一开始建立规范的时候,就有团队成员担心规范过于细致会影响设计师的发挥。但是在书中的这一章写的很清楚,规范也好,模式也罢,最终目的都是为产品服务,包括团队的风格建设,我们可以根据自身需求量身定做属于自己团队的设计体系。

最后的话:

其实还有很多小点我没有写下来,原因怕文章太长太啰嗦,其他的就靠大家自己去看看了。我只把我认为最重要的写了出来,谢谢阅读。

翻译版链接:

https://mp.weixin.qq.com/s?__biz=MjM5MDc0MDIyMA==&mid=2650619728&idx=1&sn=292caed44c7f985ca52ab0c18f357c7f&chksm=be49a4c3893e2dd57d13f23a8d0cdecb28ab3e2c67b37b894628e4e7670cdb263b0e98187cbc&mpshare=1&scene=23&srcid=1219sCj6pDPxJkDz68x1pt9o%23rd

你可能感兴趣的:(设计体系和设计规范是一个东东么?)