浅谈B端设计系统(二)如何以原子理论构建设计系统

原子设计理论最大的价值,就是为组件库的构建提供思路和方法,如果你不满足于市场上现有的设计系统,我们可以自己创建。因此我们首先要为产品设计出一个独特的视觉语言作为起点。这个视觉语言一定要有力度、易于扩展,必须能在所有地方奏效!
接下来就以 Sketch Library 来实现工程化建设设计资产!

工欲善其事,必先利其器   


原子设计理论最大的价值,就是为组件库的构建提供思路和方法,如果你不满足于市场上现有的设计系统,我们可以自己创建。因此我们首先要为产品设计出一个独特的视觉语言作为起点。这个视觉语言一定要有力度、易于扩展,必须能在所有地方奏效!
接下来就以 Sketch Library 来实现工程化建设设计资产!

一、色板的搭建:如何确定科学有效的色彩体系


颜色是一个设计系统的重要基石,它能快速地建立起品牌识别度,使一个产品能够区别于同类功能的其他产品。此外,建立一个好的色彩体系能够清晰的展现页面层次,帮助用户形成使用习惯,建立起一致的品牌形象。因此,理性的色盘设计对设计系统来说至关重要。

虽然常用的主色与辅助色能覆盖大部分产品的UI设计,但是随着产品体量的增加,业务场景的多元,我们就需要构建完整的色彩系统来支撑其发展。我们常用色板搭建的方法有:人工调整法、公式计算、智能工具生成。

640

色板确定后将颜色添加 Main、Text、Status 等一级分类,例如:Color/Status;再添加二级分类,例如:Color/Status/Success 等,命名需使用「 / 」 符号区分层级结构。定义好颜色和命名后,将每个颜色转换成 Symbol,便可统一调用。

640-(1)

这里笔者还想推荐一个插件,轻松完成设计明暗主题,感兴趣的朋友可以试试;

https://github.com/receptiryaki/darkside

640-(2)

二、字体库-如何定义字体(font)


在B端设计当中,字体往往是出现频率最高的一个“原子”。需要注重以下几点;
字体:在B端产品中,字体优先级排序为(基于数字/英文&mac系统优先原则):Helvetica Naue(英文/数字)、Helvetica(英文/数字)、Arial(英文/数字)、PingFang SC、Hiragino Sans GB. Microsoft YaHei Ul、微软雅黑、sans-serif;

字重:由于设计稿和开发代码的字重对应没有准确的标准,因此我们测试了各种字号在 mac 和 win 上的显示效果后,设计师使用了苹方字体 Regular (常规体)以及 Medium (中黑体)两种字重来设计页面,它们分别对应代码中的 400 和 500;

640-(3)

字色:遵循了无障碍设计原则,保证了文字的可读性;文本和背景的对比足够,为视力障碍者提供足够的对比度。为保证视障用户的使用,保证足够的对比度,遵守 WCAG 2.0 的标准,我们对调色板灰色的对比度进行了可用性测试,以指导体验设计中灰色调色板的使用。

640-(4)

字号:同时基于电脑显示器屏幕大小、用户使用习惯、最佳阅读距离等要素,设计规范需要对字号进行了规定。目前业界也是我们产品中常用的字号标准有两种:

第一种情况:14px(正文)、14px(标题)、16px(特殊情况,极少使用)
第二种情况:12px(正文)、14px(标题)、16px(特殊情况,极少使用)
行高:字号和行高一强绑定关系,按照12+8原则进行行高设置;

文本长度:每行承载50-100字符之间,包括空格。即单行文字长度不能超过100字符。不超过50字符的单行文字不受任何限制。这是建立在多位字体排印学专家的研究和企业自身实际情况相结合的基础上的尺度。EmilRuder在他的书籍《Typographie》就提出最佳阅读行长是每行50到60个字符之间,合适的行长可以提高文本可读性,而可读性高的文本可以减轻读者阅读负担并提升阅读效率。

基于以上的标准,我们需要将组件中涉及不同字号的文字样式罗列出来,例如:Title 1、Body、Body2 等,按照「字号/字重/颜色/对齐方式」等层级结构,将文字赋予 Text Style,整理定义出出所有的字体变量。

640-(5)

三、图标库-如何定义图标(icon)


第一步:定义图标风格

设计规范的图标不是想怎么定义就怎么定义的,首先要明确图标的使用范围,例如哪些产品、有啥行业特性,产品的目标用户是哪些人,了解清楚这些后,才可着手确定设计风格。

第二步:制定绘制规则

制定图标设计规则,才能保证设计师协作中设计出来的图标是具有一致性的。图标设计规则包括:画板尺寸、出血位、内容绘制区域、图标线条粗细、图标圆点大小、图标圆角、斜角度、基础图形参考区等;

第三步:筛选并进行图标分类

梳理产品中所需的图标并进行分类,绘制时候可以先把只需要将通用性强的图标梳理出来即可,保证产品大范畴上的一致性,无需面面俱到,其余的可以放到业务中去逐渐补全,这样不仅做到了企业级设计规范的克制,又给了业务发挥的空间。

第四步:按照规则进行绘制

设计师按照图标绘制规则绘制即可。但规则不是死的,当基础型无法满足需要的时候,以它们为准向外散发,在遵循设计规范的基础上,做视觉上的平衡和微调。并且所有图标最后都要合并路径,保证图形规整和干净,便于正确输出和使用。

在sketch中图标放置在 16*16px 大小画板内,从定义好的颜色系统中选择合适的颜色数,这样替换图标颜色时直接选定义好的颜色就可以了。在属性面板中固定尺寸(size)大小,并把调整尺寸(Resizing) 设为上下左右同时吸附,以确保图标在使用时可以等比缩放。

640-(6)

(公共原子库不光包括以上这些,还包括阴影,圆角,边框等等,我们这边就不一一赘述了)

四、如何建设基础组件库


组件库在整个系统中扮演的是行为层面的对接,是团队内部设计师和开发间的横向协作,是保证产品输出一致的规范基础;

第一步:理解和走查阶段

要去理解原子化设计理论 Atomic Design、结构细分,理解产品业务,多和产品同学交流沟通,比如某个业务组件(规则配置组件),你需要理解该功能模块需要处理什么问题,达到什么目的

第二步:组件拆解和罗列

我们需要走查产品,将产品所需的高复用、高频次的组件进行罗列出来,把页面穷举罗列出来,利用思维导图罗列出可组件化的内容并做好分类。组件的大分类大致可以为:基础组件、业务组件、数据可视化组件等类别;

第三步:设计并组合阶段

分类确定后,确定组件设计优先级后,我们就可以开始设计了,利用设计软件将原子层的内容定义成可独立变化和替换的公共变量,通过多嵌套组合式的细分方式(当然我们也支持设计和封装步骤分开做),最终组件库要求至少是精美的,至少是通过更改公共变量就可以一键更新换肤的、组件本身是满足自适应适配的,最好是设计规范+组件库的形式;

640-(7)

640-(8)

640-(9)

通过 Symbol 的依次不断嵌套,最终实现组件库的封装。考验耐心的时候到了!封装基础组件的时候要注意布局的设置;

这里笔者再推荐几个封装组件的时候提升效率的小工具!!!

组件自查表:https://www.checklist.design/

SymbolSwapper:https://github.com/sonburn/symbol-swapper

rename it:https://github.com/rodi01/RenameIt/releases/

640-(10)

我们将组件构建完成后,自己使用组件库的话肯定知道怎么处理!

使用快捷键「cmd+, 」或在文件中添加组件库,打开 Preferences 面板,选择「Libraries」(组件库)标签,点击「Add Library」(添加组件库)按钮添加刚才的 Sketch 文件,完成后就可以从其他的 Sketch 文件中,对此库里的元素进行调用了。

接下来就要考虑一个问题如何使产品相关的各个角色如何高效协作使用设计资产

1.设计师与设计师之间如何完成实时协同共享设计资产?


痛点:
  1. UI kit每个设计师手动下载到各自的设备上使用。想要让每位设计师通过手动方式实现版本一致且同时更新到最新版本几乎是不可能的。大家用不同版本的 uikit 画图当然会经常遇到输出不一致的问题。
  2. 设计规范文档更新通知和触达不及时,让需要 followed 的设计师们很难快速掌握最新的。
解决方案:

坚果云:https://www.jianguoyun.com

sketch:https://oursketch.com/tool/sketch

640-(11)

好处:

  1. 实时更新最新组件和界面;
  2. 多人共享一份规范,确保对外输出视觉稿的一致性;
  3. 组件实时更新,避免信息不对称,减轻重复劳动;
  4. 将各端规范收拢并清晰地划分权限,便于长期维护;
  5. 团队成员在使用这份规范的过程中可以随时提议增加/删除/修改规范,有助于我们检验组件库的可用性和覆盖范围,不断完善组件库。

640-(12)

如何推广给产品经理:构建元件库+巧用插件?


痛点:
  1. 设计师拥有大量的sketch格式的设计稿,定制化项目中经常会要求产品经理输出高保真交互原型图,那产品经理和项目经理如何将Sketch 设计稿转换为 Axure 格式的矢量可编辑的rp文件
  2. 产品团队同学仍使用windows电脑,无法打开sketch文件,也就无法用插件进行格式转换
  3. 产品团队习惯使用axure,短时间内不太可能更换原型工具为sketch,且需要学习成本
解决方案:
  1. 设计稿转化插件: https://oursketch.com/plugin/axure-rp
  2. 直接由相关同学负责构建axure元件库,方便产品同学使用

640-(13)

如何和前端协作:设计组件与开发代码联动?


  1. 和前端同学密切沟通,确定好公共样式库class命名规范;
  2. 根据任务和使用场景把公共原子层的颜色、阴影等,使用规则清晰的定义,避免口口相传造成的使用混乱;
  3. 生成变量表(design token),进行颜色变量的说明,信息的同步上传至wiki方便成员查阅;
  4. 通过命名正确且封装嵌套成的组件库,上传摹客、蓝湖可以前端同学直接在文本样式中看到设计读取的颜色变量名,而不是根据颜色编码数值,再去查看对应相应的变量名。直接看到的为key而不是value?;非常nice!

640-(14)

好的,各位铁子们,今天的分享就到这了,下一次我们在聊就聊聊【设计系统落地中遇到问题和对应的解决方案】,感兴趣的朋友可以关注下!

WechatIMG1725

本文来自投稿,不代表goodux 好体验立场,如若转载,请注明出处:https://goodux.cn/archives/1057

(2)
IM UEDIM UED作者
上一篇 2022年2月25日 上午10:24
下一篇 2022年4月27日

相关推荐

发表回复

登录后才能评论