好货商城/首页/搜索/

这个名字的意思是，从首页进入的搜索页面，这里的input指的是已经输入的内容。这样命名的好处是可以清晰的说明当前界面的来源，上一个操作是什么，父界面是什么，也就是通过命名传达了交互逻辑。

应避免使用重复的名称和“抄袭他人”；

2. 图层和组命名

图层：分散的个别图层只需根据各自的属性命名，如矩形、线条、图像等。当图层有明确含义时，也可以使用当前的语义来命名，如一个矩形可以命名为bg（背景），一条线条可以命名为（分割线），一张图片可以命名为image（某某图片）；

至于中英文的使用，就看个人喜好和习惯了。英文当然是最标准，但中文可能更容易阅读。没有什么是绝对的，只是选择最合适的名字。比如这个词，虽然是英文的，但所有设计师都对它有清晰的认识，用它一定会有助于提高协作效率。

层的情况有很多种：

文本

图像

线

形状（主要为矩形和圆形）

片

成分（）

对于切图和组件，有独立的命名规则，这里就不多说了。其他的，可以使用默认的命名方式，即不做任何修改，或者在原有名称上加数字即可。例如，线条1，线条2；矩形1，矩形2；当它们有明确语义时，可以适当命名，例如作为背景的矩形可以命名为bg，作为分割线的线条可以命名为（分割线）；

总结一下，从效率的角度来说，你不需要太过担心单个图层的命名，一方面数量太多，另一方面因为图层会嵌套成组，共用一个组名，所以组名才是工作时需要识别的。

群组：我们主要的命名工作其实是群组命名。大部分图层都应该分组，以方便操作，同时减少筛选信息的成本。由多个图层组成的群组是我们需要重点命名的最小设计元素。

群组命名遵循嵌套原则，即一级群组/二级群组/三级群组。一般以功能模块为主要命名原则，如小说首页的编辑推荐模块，自然命名为编辑推荐。如果是可复用的模块，可以命名为卡片(:组件名称)/编辑推荐。

本质上它也是一个组，也是我们设计 UI 时最常用的一类组。使用组件可以帮助我们减少组的总层级，将组保持在两到三层。因此，当点击最小层级元素时，只需要点击两次就可以选中，提升效率和用户体验。

由于大多数主屏幕设计较长且承载的内容较多，建议使用数字前缀来表示其上下顺序。

界面中的所有设计元素都可以且应该按照一定的逻辑进行分组。避免单层布局，导致画板的一级展开条杂乱。另外不要组复制，这样会显得不专业。即使是复制的组件，也可以加上数字后缀，体现一定的逻辑。

3. 控件的命名

控件或者组件是我们现今设计中最常用的设计元素名称，尤其在UI设计领域也逐渐流行起来，掌握基本的原子设计理论，运用组件化的设计元素，可以提高设计效率，规范设计流程，降低后期维护成本。

在了解控件的命名之前，我们需要知道在现在的设计环境中，控件已经不再局限于各个系统厂商的定义范围，比如iOS端的bar和bar。我们在日常工作中总会产生一些不在系统组件库范围内的设计元素组，比如我们熟知的金刚区域入口，还有承载各类运营活动的淘宝等电商产品首页的卡片区域设计。我们一般可以把它概括为一个内容容器，但必须有一个更加细致的名字去定义和区分它，这就产生了许多新的控件。而这些新控件的命名其实可以由设计师自由决定。

因此简单的结论是，对于平台级的官方控件，我们应该使用标准的命名方式，本文会尽量一一列举，你也可以去官方文档查看。对于非原生的控件，根据项目协作的需求，或者提高工作效率的愿望，适当命名。比如首页上一些基于内容的复用模块，我会以 card 作为前缀来命名，因为这种设计灵感来源于卡片式的设计潮流。

另外我们还需要知道组件之间是可以嵌套的，比如一个卡片组件里面可以包含多个图标组件，组件里面又可以包含组件。

往往我们将相关组件聚合成一个大组件，将大组件移到布局中sketch icon边框范围，这样对于界面管理和查看全局效果更加高效便捷。

整体命名约定为：属性/模块/状态（属性）例如 bar/ bar/black

这样命名主要还是考虑到代码中绘制的效率，可以使用“/”符号来区分不同模块、同一组件的不同状态并进行二级嵌套，方便实际工作中的筛选和调用。

下面列出常用的组件，参考iOS组件库和Ant组件库：

1. 后缀栏

1.1 状态栏+导航栏

在iOS的系统控件中，状态栏和导航栏是分开的，但是在日常设计中，一般会将状态栏和导航栏合并为一个栏。

1.2 搜索栏

bar 有时与导航栏结合在一起，有时单独排列在导航栏下方。在 Ant 中，bar 被归类为输入信息控件（数据输入）

1.3 标签栏/菜单栏

标签栏是标签导航中的核心控件，与其相对应的是抽屉导航中的抽屉控件。抽屉导航最早应用于系统，但如今移动端设计的边界趋于收敛，一切都以效率和易用性为首要原则，平台差异化则是次要的。谷歌2019 IO大会上公布的最新系统采用与iOS相同的主页栏侧边栏就证实了这一点。标签栏又称为菜单栏、底部菜单栏等，其主要作用是将信息分类作为一级导航，方便用户在不同模块间切换。

此外，还有一种特殊类型的标签栏，即tabs（iOS组件库中称之为scope bar），其作用是作为二级导航类别。

1.4 工具栏

工具栏是操作功能的集合，主要承载各种操作。

2. UI 视图

2.1 模态框类（modal）

一般情况下，modal 需要打断当前任务才能开始另一个任务或内容，一般通过遮罩、弹出对话框或浮层、活动视图等方式打断当前页面，所以 modal 是必选的，一般用于比较重要的功能或者警告等比较重要的事情。但也有一些新兴的用途，比如通过 modal 视图查看用户评论或者进行交互，而不需要打断当前的阅读进度。关闭 modal 视图后，可以继续当前任务或者继续阅读进度。

警告框/提示框

弹出框/浮动层

标准的弹窗一般都是图标+文字的形式，但是一些简单的弹窗则是纯文字或者图标的形式，并且每个选项一般都带有功能语义。

模态视图

它用于当你倾向于完成一个独立的任务时，这个任务比较重要，需要打断上一关的体验。注意，它不是简单的函数入口集合，而是在模态视图卡片上完成的任务。

模态框

这种控件从底层调用出来，承载着多种功能语义，应用范围很广，使用场景也多种多样。操作列表自不必说，来自 iOS 组件库，常用于确认操作，比如删除；活动视图，多用于分享场景；内容模态性是后来兴起的一种设计方式，其目的就是在不打断当前体验的情况下，满足用户多样化的交互需求。

2.2 非模态类

非模态视图与模态视图的区别在于，它会在几秒后自动消失，而无需强迫用户执行某些操作来折叠它。

轻量级提示层

多用于状态信息指示，倾向于表示成功操作，如成功分享、保存等，优点是反馈轻量，可以传达结果，又不会太过打扰。

可操作提示层（）

基本形式为文字+功能按钮，是对状态的说明以及对应可执行的操作。例如腾讯撤回某条消息后，提供了撤回该消息的状态，以及重新编辑该消息的操作。

2.3 卡牌

卡片视图是目前所有产品首页设计中都会用到的一种内容容器，一般包含文字、背景、图片、图标等元素，作为二级页面的入口，主要呈现内容、图文混排等，当然也有一些特殊的卡片视图，比如可以左右滑动的隐藏视图（滑动视图）

3. 表单控件

表单控件主要是指与信息输入（Data entry）和信息显示（Data）相关的控件，主要的形式有：列表（list）

3.1 输入类（入口列表）

输入列表

输入列表通常为单行列表，包括标题、输入区域、提示字数限制值等辅助信息，删除或隐藏输入内容等功能按钮。注意列表有多种状态，命名时需要区分，例如“用户名-列表/”、“用户名-列表/输入”，输入列表常用的状态有正常状态、已输入状态、不可用状态、验证状态。

文本输入框（）

包含辅助提示文字、内容输入区域（色块或边框）、限值等；

检查员类控件

包括时间或地址检查器（）、滑块检查器（）、步进器（）图像检查器；

3.2 显示列表

展示列表同样是单行列表，包括图标/图片、标题、子文案、箭头引导等。有时候展示列表只是展示信息，比如展示规则的展开列表设计，但更多时候，展示列表指向的是二级界面，比如设置中心的关于我们列表，指向的是产品介绍的二级界面，微信消息界面列表，指向的是聊天界面。

扩展列表与常规列表

可操作清单

由于其本质仍是显示选项，因此被归类为显示列表

金刚区域/网格列表 (Grid)

网格列表本质上是一个门户的集合，和首页区域一样sketch icon边框范围，所以归为一类，目前在首页和个人中心应用比较多，当然还有很多其他的用途，这里就不一一介绍了。

4. 其他控制

包括一些不方便划分的小控件，如复选框、开关、红点、加载控件、轮播点等；

5.图标和图片命名方法

最常用的抠图其实就是图标，但是抠图不仅限于图标，还包括一些图片内容，一般是png格式。另外一些标准图标可以导出为svg格式上传到，方便提高开发效率，而且质量比png高很多。好了跑题了，这里说一下命名。以我们的工作为例，图标命名和抠图命名要分开考虑。

图标命名

图标命名主要考虑文件中的命名方式，为了便于按照一定的方式管理图标，我们通常需要使用“/”来对图标进行分类。标准版格式遵循icon//-state的逻辑，极简版为icon/-state。这样，我们就可以逐级在控件库中找到目标图标。

综上所述，标准化的图标命名是为了提高效率，规范工作环境中图标素材的管理。

4.剪切图片命名

镜像命名的对象是开发者，而不是设计师，所以镜像的命名应该考虑开发者的习惯或规则。

以下是一些一般原则：

1.避免使用大小写字母，有些开发语言不能识别大小写字母。

2. 不允许有空格；

3、切图时请使用分隔符“_”，不要使用“/”，“/”符号为分级用，仅适用于软件中图标的管理，请勿在切好的图片上命名；

4. 不允许使用数字（我在撰写本文之前经常会添加数字来表示逻辑关系）；

补充一点题外话，我们的设计稿经常会用到三种粗细的文字，但是H5界面上只有两种字体，一种是细一种是粗，没有中等粗细，大家一定要记住，有机会多跟开发者沟通。

OK，按理说应该整理一份管制清单，供大家参考，但是后来我突然想到张小龙学长讲的最后一条原则，我上面说的都是错的。不要被条条框框所限制。

拥有扎实的整理技能 vs 有强烈的整理文件意愿，我认为后者更重要。当你想做某件事时，你有无数种方法去实践。但更多的时候，我们知道我们可以做到，但却没有去做。

工作场景变化频繁，除非强烈需要维护组件库，否则没那么多时间和精力去规范每一个小细节的命名，再加上有些人不习惯在高效绘图时被命名工作打断，那我干嘛要写这么多废话？

首先，你需要能够在真正需要的时候整理文件和资料。其次，在项目协作时，你需要考虑其他人的经历，要有同理心。比如，当同事向我要源文件时，我不会立刻扔给他，而是先打开并整理图层。当他接手时，他会体会到你的严谨和对他人的尊重。

最后，如果你没有看这篇文章，不了解聚合控件的专业术语，是不是就不能做好命名呢？不会的，那是因为你知道自己能做好命名，但是你没有去做。可能是懒惰，也可能是坏习惯。当你意识到这一点，就是很大的进步了。

感谢阅读~

如有侵权请联系删除！