设计规范如何做到保持生长性与可复用性(如何保证设计精度)

各行各业都有着自己的规范,那么我们在做设计规范的时候,常常会面临着一些问题。本文大致总结了两个问题:规划缺乏生长性和可复用性。那么该如何解决这两个问题呢?作者对此进行总结,希望对你有所帮助。

最近一段时间笔者正好在梳理设计规范,在做设计规范的时候,经常面临如下几个问题:

(1)由于业务发展,规范不断在更迭,今天做的设计组件却并不适合1个月之后客户的需求。

简而言之,规范缺乏对未来的规划,缺少生长性。

(2)规范主要集中在业务组件上的思考,但是缺乏对业务流程的梳理,导致流程上复用率低。

(3)缺乏对整体信息架构的梳理,缺少全局上对产品的思考。这个优势在于避免重复造车轮,有利于合并同类项,让产品更轻量,更易用。

简而言之,规划缺乏生长性和可复用性。

一、应该如何预留生长性

大部分做中后台系统的同学,大抵都会站在“巨人的肩膀”上重新规划、设计组件。“巨人的肩膀”例如ANT DESIGN,大而全,在列表和表单组件引用时非常丝滑,但是却缺少精细化和对业务诉求的承载。

因此,大部分的同学都会结合业务诉求,形成一套对公司业务有强支撑和专业化的组件,做到小而精。问题是,设计同学在设计规范时,心里的那杆秤始终摆不平。定的太严谨,未来业务变化后,组件又需要重新开发,不可预期的提高了开发成本,定的太松弛,前端引用时会bug频出。

其实导致“秤不平”,最重要是缺少了生长性的砝码。那么什么是生长性,生长性的边界又在哪里,该怎样预留生长性呢?

1. 什么是生长性

生长性指的是产品方向变更时,设计组件仍能支撑业务诉求。比如原有组件设计时只考虑静态交互,而业务变化后需要新增可拖拽功能,方便用户快速处理信息。如果在设计组件时,就预留了生长性和空间,后期改动就只需要往上加,而不需要大改动。

再比如规范建立初期,业务是以国内为主,但由于疫情之后,国内僧多粥少,企业考虑未来出海,走差异化竞争。此时,国际化最直观的变化在文字和行高规范,多门语言,多种文字在相同场景下会出现承载空间不够或过于富余等问题。不同对部分结果页指示也会有文化禁忌,此时就需要尽量避免引起语意冲突的部分。如果规范预留了足够的生长性,业务迅速调整时,设计和开发也能无缝跟上,节约时间,抢占市场。

2. 生长性的边界在哪里

规范总体来说,是设计和开发共同的指引。生长性的边界在于“是否能做到清晰的指引”:开发在引用时,能否应对各种报错、能否处理极端场景,能否应对产品经理临时的小需求等等。这些都是判断生长性区间范围的衡量标准。

3. 如何在组件中预留生长性?

(1)通盘考虑报错

在设计报错提示组件时,需要整合多个业务场景下,除了需要通盘考虑样式之外,也需要和前端同学讨论是否会影响性能的变化。

大部分的报错可以分为:表单报错、列表报错、全局报错、业务场景新组件报错。报错提示如若不能同时适应这四种场景,就需要将组件做样式微调,分成四种报错样式,整合到规范中。

(2)定义极端场景

比如由于很多场景下,业务诉求很可能会在原有组件中加内容、加层级,而增加的工作量往往产品会直接交付前端同学实现,因此如果定义好了极端场景,设计同学就不必每个需求下都需要做微调,前端同学对极端场景做判断,即可轻松实现效果。(涉及到工作流程的问题)

(3)提前预留承载空间

首先,就需要厘清现有业务控件承载,比如页面区域工具栏,工具栏本身区域有限,而业务方在不停加工具,在设计初期就需要规划好,页面承载空间不够时,应如何处理,这样利于后期的延展。

(4)多端视觉和交互规范,确保品牌延展性

比如中台产品支持PC端、Pad端,就需要考虑同样组件在Pad下可点击区域大小、Pad交互习惯等。

比如,医疗SaaS产品,大部分私人医院都会要求产品支持Pad端。私人医院相对公立医院,更重视医疗体验,以及微营销。患者在候诊或者做康复医疗时,需要做健康宣导或者活动营销等。

因此在设计组件时,如果我们通盘考虑了该组件在PC端和移动端、Pad端的可承载性,便可以让品牌得到了最大化延展。

(5)无障碍设计

规范建立初期,服务的是大多数身心健康人士。随着业务拓展,企业品牌建立,对于残障人士的无障碍设计、老年人关爱模式,是否需要考虑其中。需要同时结合公司品牌,为产品预留生长性。而无障碍设计的规范,国内外很多知名企业已经根据残障人士的特点,有一套该如何搭建的引导,设计同学只需要顺延,结合业务,搭建自有的无障碍规范即可。

二、应该如何最大化规范的可复用性

流程上复用率低、产品过重缺乏全局思考根本原因在于,过度重视原子组件搭建,而忽略了整体架构和流程的梳理。

(1)引入共性流程规范

往往我们在工作中搭建规范时,会过度重视原子组件搭建,而忽略了流程梳理。规范上忽略了流程梳理,设计稿中也会难免遗漏一些场景,导致实际上线时用户体验不佳或者流程不丝滑。

举个例子:

例如在金融中,涉及到贷款流程,小微贷,企业贷,消费贷等,由于属性的不同,各个贷款流程在细微上有差异,也有共性。在梳理设计规范时,就可以提炼共性的贷款流程,封装组件。在前端开发时就可以节省不少人力。

再比如医疗SaaS中,会诊流程和日程流程:

日程:发起日程-邀约日程-再次邀约(未及时加入提醒)-记录日程。会诊:发起会诊-邀约会诊-再次邀约(未及时同意提醒)-线上会诊(线下记录会诊内容)-上传会诊记录-跟进会诊后患者状况。

本质上,会诊也是日程的一个分类,但由于会诊涉及到多个角色的协同,分为普通会诊和多学科会诊,比普通日程更加复杂,是属于长期的工作流,因为会诊除了会诊之外,同时需要关注会诊后患者的,以便下次会诊复盘。

将日程和会诊的共性流程进行封装,将为开发带来诸多便利。

(2)梳理信息架构

Z轴分布包含平面内部的分布和空间上的排序。平面的分布可以梳理各个一级页面、二级页面的框架层,便于设计组内同学在设计新页面时参照规范快速出稿。而Z轴上的空间分布,包含浮层、弹窗、提示等的出现次序和排列。提前规划好排列顺序,有利于组件冲突时,有可供参考的规范引导。

(3)文案规范

文案往往体现产品气质。梳理文案规范,有利于从产品上提升企业气质和形象。可以将文案分为引导类文案、描述类文案、报错类文案等。而文案规范梳理应该放在成熟期的产品使用。业务在蓬勃发展期间,还是应探索业务组件为主,文案规范可以往后延展。

以上是笔者结合项目经验的一点心得,希望能帮助到大家。

本文由 @灰研走B 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

(0)
上一篇 2023年08月02日
下一篇 2023年08月02日

相关推荐