为什么要遵守设计规范标准(为什么要制定设计规范)
为什么要遵守设计规范标准(为什么要制定设计规范)身为懒人,在如何偷懒的道路上深有研究,那么对于设计师而言偷懒偷得名正言顺的规范怎么能放过呢。如何通过制定规范达到省时省力的目的,这里就详细说一说。制定规范的初衷也是为了解决一下问题:设计规范一般分为:视觉规范和交互规范。交互规范会更注重整体的层级关系、逻辑、流程方面的定义,对于已确认会用到的常用组件也会有概念定义,由于业务的不确定性,所以交互规范更多的是起到框起某个范围的作用,设计师可以在该范围中进行设计;而视觉规范则会事无巨细的制定字体、颜色、边距等等非常具体的规范,这是一个明确且不可变更的规范,除非有新的组件出现,已有的内容则基本都要按照规范去实现。交互规范大体上包含:结构、布局、公用组件、业务组件、反馈、公用流程(编辑等)、业务流程(下单等),再从上述几个大类中去细分,就构成了一个规范。视觉规范在交互规范的基础上增加:颜色、字体、间距的规范即可。
现在已经不是一个人做设计的时代了,多人协作中,为了达到设计的统一性,交互规范正在起着越来越重要的作用。而且软件中还可以做成组件,大家共同维护,省时省力。
这篇文章分为三个部分:
- 一般规范包含什么内容
- 如何通过规范省时省力
- 如何评估规范的合理性
为什么要写这些内容。首先第一部分让大家大概了解设计规范有什么内容,日后制定规范可以直接套用;了解第一部分就会发现,现在很多设计规范的内容都大差不差,每次一个新项目都有一个新规范,规范以及是一个累赘的负担,没有起到最初的作用:省时省力,当前我们团队也没有完全解决,这里我就先假定某些解决方案仅供参考;第三部分则是花费了大量精力制定的规范如何评估它的合理性,依据有哪些,只有这样,设计的合理性才可站稳脚跟。
话不多说,开始正题。
一、规范包含什么内容设计规范一般分为:视觉规范和交互规范。交互规范会更注重整体的层级关系、逻辑、流程方面的定义,对于已确认会用到的常用组件也会有概念定义,由于业务的不确定性,所以交互规范更多的是起到框起某个范围的作用,设计师可以在该范围中进行设计;而视觉规范则会事无巨细的制定字体、颜色、边距等等非常具体的规范,这是一个明确且不可变更的规范,除非有新的组件出现,已有的内容则基本都要按照规范去实现。
交互规范大体上包含:结构、布局、公用组件、业务组件、反馈、公用流程(编辑等)、业务流程(下单等),再从上述几个大类中去细分,就构成了一个规范。
视觉规范在交互规范的基础上增加:颜色、字体、间距的规范即可。
制定规范的初衷也是为了解决一下问题:
二、如何通过规范省时省力
- 团队内部协作
- 可追溯的更新版本
- 组件化设计,可复用性强
- 通过组件化设计,提升可复用性,来提升开发效率
- 如果是多个业务线并行,统一的规范能够起到统一的作用
身为懒人,在如何偷懒的道路上深有研究,那么对于设计师而言偷懒偷得名正言顺的规范怎么能放过呢。如何通过制定规范达到省时省力的目的,这里就详细说一说。
制定规范分为以下几个阶段:
- 项目前期:结构层级,以及某些常用的公用流程和组件方便初始的交互设计搭建
- 项目中期:对出现的新组件的定义,某个元件是否能被定义为组件取决于该元件出现的频率、普适性以及可扩展性
- 项目后期:收尾工作,查看新组件和之前的是否有冲突、重合,是否有某些地方可以成为新的组件,并进行迭代更新
如果设计师处于多个项目中,就会出现要维护多套规范的情况。
这里来说说以下的情况:
- 整个公司围绕一个产品为主,那么规范只存在一套;
- 公司N个产品并行,类似但不是同一个产品,这些产品还要有定制性,统一的规范不可行,那么有多少个产品就会有多少套规范;
- 公司多个产品但是这些产品是互补的,那么可以有一定的共同性,那么就会存在一个统一的规范,然后各个产品根据具体业务需求看是否要制定支线规范;
第一种情况很简单,大家共同维护好一套规范,按部就班的迭代就好;第三种情况也简单,由于产品互补,那么整体的交互方式一致即可,相同、类似的操作可以采用统一的规范,至于业务流程部分则可从主规范中演变出来,那么这时候设计目标、原则就起到了指向性作用。而第二种情况则比较复杂,产品不同、产品基调不同,规范不同也是情理中的事,但是如何维护,如何使用就成了问题。
第二种情况很难碰到,但每个公司生存肯定是有一个主线产品,不论外表产品形式如何更改,都无法改变核心业务。那么可以参考第三种情况的方式,针对核心业务整理核心流程并组件化,这样可以适配各种类型的产品,那么剩下的工作就是针对项目做差异化设计了。
上图(Xmind试用模式忽略忽略)是一个完整的交互规范可能有的内容:结构、布局、流程、组件。结构主要是针对整体产品架构、结构层级的定义,这是一个产品的底层逻辑定义,而且设计原则也起到了设计指导的作用,当出现新组件、新流程时,如何制定最终方案还是要依据设计原则进行。
所以省时省力的做法就是:公用组件、流程提炼出来作为统一规范,而结构、布局、业务流程和组件作为差异化的部分,以项目为纬度分别进行维护和迭代。
三、规范制定的合理性现在的规范系统都比较成熟,有经验的人在项目初期就可以列出一个大概的规范出来,但是规范列出来了,如何评定这个规范的合理性呢?
- 这个组件在项目中出现的频率是否很高,如果仅出现过一次是否可以考虑作为特案处理
- 这个组件在项目中其他模块的设计中是否可以复用,复用率如何,如果不可复用那么更换样式是否可以提高组件复用率
- 如果这个组件实在不可复用,那么通过简单的增删是否可以复用;或者说通过多个组件之间的组合达到目的
上面3点就是我在做项目中总结的好的规范通过哪些纬度去评定:频率、普适性和可扩展性
好了,以上就是对于规范的一点碎碎念,这里都是从概念上去说明,后续会整理出合适的例子,那就到这里,谢谢大家的观看。
作者:青绛,搬砖人员素养
本文由 @青绛 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash ,基于 CC0 协议