B端组件规范定义撰写

各大设计团队为了释放设计人力,会根据业务情况封装组件库,后续开发成代码,方便前端同学进行组件调取,也同时节省了开发成本。

写这篇文章是根据自己撰写并升级了原有组件库的经验,让大家大概了解设计组件背后需要做哪些工作,日后制定组件规范可以直接套用。

一、写组件的目的

在工作中做一件事情首先要思考做了之后要达到什么样的效果。写组件的目的就是要让每一个场景下的操作都具有合理性,让产品变得好用、易用、可用。让各个业务在遇到类似的业务需求时,不要产生:

  1. 应该使用哪个组件?
  2. 组件操作应该包含哪些状态反馈给用户?
  3. 不同业务,同一品牌下如何保证交互一致性?
  4. 组件不能满足应该怎么办?
  5. ……

一系列模棱两可的疑问。

二、写组件的前期准备:组件结构层梳理

从层级上排列:产品——应用——页面——模块——组件。组件在页面中属于原子级的元素。

首先对团队业务组件进行盘点、同时对比行业内竞品组件,比如Ant Design、飞冰 Iceworks、Element、SUI、iView、Admui、Zent。

第一步:根据组件的作用进行分类,梳理组件清单,比如:组件分为通用类、导航类、数据输入类、数据展示类、反馈类等。

第二步:梳理完成后划分组件设计优先级,参考维度:

  • 『我们』有+行业内有(p0)、『我们』有+行业没有(p1)、『我们』没有+行业有(p2)。
  • 『我们』有+行业内有(p0):代表了这类组件是解决行业内产品问题高频应用的刚需组件,比如搜索、按钮等。
  • 『我们』有+行业没有(p1):代表这类组件多为业务类型组件,是业务的特殊性产生了这类组件,比如:卡片、折叠面板等。
  • 『我们』没有+行业有(p2):代表了这类组件可能是行业内潜在有某种业务形态,列在『我们』范围内以免以后遇到类似的,无规范可查。

第三步:对组件进行结构层、行为层和表现层元素进行拆解,参考标准为是否常变动。

产品经理,产品经理网站

三、写组件前期准备:行为场景梳理

其实结构层分为组件种类(导航类、按钮类、提示类……)和组件类别(下拉菜单、顶部tab、走马灯……)分析到现在应该得到的是原子级的组件类别,接下来就需要根据场景继续细分组件的形态,从而得到组件形态的分类定义。

产品经理,产品经理网站

组件最难的是如何定义和区分组件行为层的类别,不断在定义标准,目的是保证撰写组件时,状态不会模棱两可,难以取舍。通过写组件经验分享一下我们从应用、差异化、组件构成是通过以下角度确立的标准:

  • 组件应用标准:通过组件使用规律给组件下定义。
  • 组件差异化:通过限定场景突出功能特点,让用户感知到信息操作的差异,赋予业务场景特定交互特色。
  • 组件分区:通过前面梳理的,组件有哪些是常变动、哪些是不常变动的,去定义,基础必备元素构成写死(不可调整),基础元素以外的内容,可以写成活代码(可调整)。

四、写组件设计阶段:体验分析

规范的成立是根据多角度、多业务验证才确定,所以需要时刻思考组件设计的边界。在写组件时可以思考以下6个问题:

产品经理,产品经理网站

产品经理,产品经理网站

五、写组件设计阶段:撰写组件

通常直接浏览的角色是:UE设计师、UI设计师、前端程序员、间接浏览角色:产品经理、售前、后端程序员等。根据角色确定撰写内容包含哪些结构和信息。

产品经理,产品经理网站

从输出文档角度举例,可以从组件的结构层、行为层和表现层依次撰写。

产品经理,产品经理网站

从组件业务角度举例如:下拉菜单。

菜单内容大多是预置、后台调取、后续手动添加,所以根据业务属性会产生多种形态。确定组件类别后,同时应要对每一个组件的类别确定必有的基础组件状态,比如:默认、悬停、点击、禁用四种是每个组件都必有的状态,其他会根据组件属性增加。

基础菜单:满足菜单基本功能,单选、多选。

产品经理,产品经理网站

分组菜单:指菜单内容需要展示分类标题和内容时。

产品经理,产品经理网站

多层级菜单:指根据目标层级选择一个或多个的选项。

产品经理,产品经理网站

以上内容仅此举例,希望能给大家在写组件时带来更多的思路。

 

本文作者@石果果

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部