一、设计体系的三层一环结构

下面是我提出一个VGLT-MO三层一环结构，帮助大家理解设计体系。

• 愿景与原则（Vision & Principle），它们作为设计决策的参考，指导前行。
• 指南（Guidelines），包含样式指南（Style Guideline）、模式指南（Patterns Guideline)、内容指南（Content Guideline）等更多通过文字和图像进行传达的内容。
• 库与工具（Libraries & Tools），包含组件库（Components Libraries）、工具包（Toolkits）、协同工具（Collaborative Tools）等可以直接进行使用的内容。

包围着这三层内容的一环是管理结构（Management Structure）与组织流程（Organization Process)，它促进整个设计体系成为一个活的生态系统。

我曾参与过国内某知名企业的设计体系建设过程，遇到了很多困难，但也收获了更多的认知，了解到不能怎么做和应该如何做，进一步促成了本篇文章；因此我试着搭建出设计体系的通用结构，并且文章后面阐述其中的价值和如何去构建设计体系。

二、设计体系的原则

系统规则影响系统行为，稳定的设计体系结构促进产生稳定的设计体系，关于设计体系的原则我将其归结为以下4点原则：

1）形式上，通用却灵活

设计体系是独立存在于现有业务外的，用可预测的规则进行构建和管理，指导方向一致性，而非每个人独自开脑洞。

但是规则并不是限制，当指导不足以传达更佳的用户体验时就通过体系机制的设计，即时迭代设计体系。

设计师可以更快地完成原型和迭代工作，因而更加灵活地去思考满足需求的解决方案。

2）关系上，整合但互通

整合设计与开发，链接设计与实现的代码，有效地将体验的设计与落地的开发相结合；但又通过独立化的模块设计以及模块间关系的设计，搭配良好的机制和协同工具帮助使用者更流畅地使用。

3）组织上，开放共享且跨域同步

通过组织流程的设计让基于模块化设计思维的组件、设计模式、内容策略等等能被尽可能多的人重复利用，提高知识复用率；并让关于用户的知识在组织中的设计师、工程师、产品经理、市场营销人员等人中保持同步和流通。

4）成果上，协同而一致

通过良好的开发体验，用设计开发的规范化指导，让大范围的开发与设计都能良好地匹配用户心智模型和多设备多平台需求，带来优质且统一的产品价值传达和用户体验实现。

除了创建更高的可用性（Usability）之外，也能建立更高的可访问性（Accessibility），让体验在如障碍群体、各类配置低下的设备、有法律与文化的国际差异等在产品多次迭代中也能更易达成一致（这些往往是较少被考虑到的内容）。

三、不同设计体系的差异

不同组织和产品的设计体系都会不一样。

设计体系有不同规模（Kholmatova，2017），简单来说可以分为平台级设计体系（如Apple的人机交互指南HIG, Microsoft的流畅设计体系FDS）和公司级设计体系（如Atlassian的Atlassian设计体系ADS；Salesforce的闪电设计体系LDS，Adobe的Spectrum），如蚂蚁金服的Ant Design等）。

设计体系的开放程度不一，而且有些设计体系并不对外开放（如Airbnb的设计语言系统DLS），而微软的流畅设计体系则是全程开放。

我们可以从实践规则（严格/松散）、构造方式（模块化/整合化）和管理机制（集中式/分布式）（Kholmatova，2017）。

任何组织都能在其中找到合适的定位，有些设计体系极为严格，而有些反而得益于其松散性与灵活性；如Airbnb的设计体系整体上更为严格，拥有详实的设计规范文档、设计与开发有精准的同步流程、拥有严格的新模式入库流程，详实全面的设计文档等；通过内网进行使用，并开发一系列的插件工具促进设计与开发流程。

而TED只有两名 UX 设计师和四名前端工程师专职负责设计体系相关工作，因此就更稍显松散；不同的程度都是和自身组织的团队文化和产品特征有关的，他们更加关注有效地实现产品设计目标。

“我们鼓励以正确的方式进行设计，而非一味强调一致性原则；页面的性能表现对于我们来说更为重要，如果它无法有效地承载内容，我们会将其修改到能够承载为止；一致性与模式化的信条对于我们来说无法成为驱动设计决策的关键要素。”——Michael McWatters，TED UX 架构师

是标准化还是松散化，更多依靠组织文化下的选择。它们各有利弊。一个紧凑严格，利于精准，但有时较为死板，会限制设计师进行创造发挥；一个灵活适应，利于拓展和快速变更，但难以控制，它们都需要找到解决自身缺陷的方法。

关于模块化还是整合化，我们可以根据各自适应的产品特征进行抉择。

例如模块化方式适用于：

• 需要扩展与进化空间；
• 需要适应不同类型的用户需求；
• 需要大量的可复用部件参与构建；
• 需要多个团队同步并行地参与构建。

典型的例子包括电商产品、新闻类产品、在线教育平台、金融平台、政府信息平台等等。

而整合化方式则适用于：

• 面向一个特定目标进行设计的；
• 无需具备扩展性与适应性；
• 需要在体系范围之外进行风格探索的；
• 部件复用率较低的；
• 一次性的。

典型的例子包括创意展示类页面、一次性的运营活动页面、作品集等等。

当然有许多不同的特质让每个设计体系各不相同，关键的是，我们如何找到适合的定位；而关于管理方式上的划分，我将在第4章-如何构建设计体系中进行更多详细的论述。

四、关于设计体系的认知误区

知道设计体系是什么，更需要了解设计体系不是什么。

关于设计体系有一些误区，例如：

设计体系是设计规范（Design Guidelines）吗？

许多人都会将设计规范与设计体系相提并论。但实际上，他们并不是一个层级的东西，或者更准确的说是设计体系包含了设计规范。

设计体系是模式库（Pattern Library）或组件库（Component Library）吗？

模式库的建立在设计体系内，而模式库是记录和共享设计模式的工具，只是设计体系的工具化和显现化的部分；像Bootstrap这样的工具包不被认为是设计体系，因为它们缺少一些定义设计系统的重要元素:模式库、风格指南和设计语言。

设计体系是否会扼杀组织内的创造力？

不好的设计体系当然会，但好的设计体系往往会通过机制和流程，促进实际的创造力，因为来自终端的良好的解决方案可以更快被整个组织所采用，而不必担心那些即将沦为沉没成本的过往设计与技术资产的限制。

设计体系是一劳永逸的吗？

设计体系是动态的，永远是随着组织需求和用户需求而变化的，一切说自己已经完成了设计体系的建设的人都是将静态的设计规范曲解成了设计体系。

文章来源：人人都是产品经理  作者：龙哩个龙

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

编辑导语：设计在产品中日常可见，但设计体系从何而来？很多时候，我们可以基于一套架构严谨、规则统一的体系框架，对产品表现层面的设计工作可以逐渐实现模块化运作；本文作者分享了关于设计体系的整体详细介绍，我们一起来了解一下。

——WHY 为什么？

设计体系从何而来，为何出现？设计体系如何发展到现在的样子？

——WHAT 是什么？

设计体系是什么？不是什么？关于设计体系有哪些误区？与设计规范、组件库、模式库的区别是什么？有哪些现存的设计体系？

——HOW 如何做？

如何搭建自己公司的设计体系？

——FUTURE 设计体系的未来如何？

这篇文章有大量我的个人理解，因此难免出错或是不准确的地方。

国内设计和前端界对Design System主要存在两种叫法，设计系统和设计体系。

看看百度词条对两个词汇的解释：

系统，来源于古代希腊文（systεmα），英文为system，日文音译，后引为中文，即形容若干部分相互联系、相互作用，形成的具有某些功能的整体。
体系，英文为structure，泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体，是不同系统组成的系统。

要了解Design System，首先就得了解到它一定不是一堆UI组件，不只是设计师的事；如果称Design System称为“设计系统”，则是把它当成“产品”存在了，过于静态，失去了人之间的联系，但恰恰是人之间的联系才能促成优秀设计体系的生成。

因此尽管原英文单词不同，但依据实际表达的意思，本文偏向于认同“设计体系”的名称，相信你读完之后也会认同这样的叫法。

一、设计体系的涌现：适应组织的需要

目前来说，设计体系尚未出现清晰的定义，我们可以看一些设计体系的专家的定义：

“由明确的标准指导的可重用组件的集合，这些组件可以组装在一起以构建任意数量的应用程序。”——Will Fanguy（2017，inVision设计体系专家）

“一组相互关联的模式和实例的共享，通过将一致地组织它们以服务产品目标。模式（Pattern）是我们用来创建界面的重复元素：如用户流、交互、按钮、文本字段、图标、颜色、排版、微复制等；实例(Practices)是我们在团队工作中如何选择创建、获取、共享和使用这些模式。”—— Alla Kholmatova（2017，著有设计体系：数字化产品设计的系统化方法）

“由个人、团队或社区记录和发布的视觉风格、组件和其他的库，以作为代码和设计工具，以便采用产品可以更加高效和有凝聚力。”——Nathan Curtis（2017，设计体系咨询专家，帮助多个企业搭建设计体系）

在本文综合的理解下，我试着为设计体系下了更加清晰的定义：

设计体系（Design System，也可以叫设计系统）是可重用组件的集合，由清晰的标准引导，通过机制化的组织流程和具象的指南与工具加以整合，以帮助开发者（设计、工程等）高效且一致地创建大量的应用，并且动态地确保用户体验的一致性。

如果你之前不太了解设计体系，可能现在有点懵，没关系，相信读完我这篇文章，你一定就能了解。

二、小故事：一个按钮的旅程

试想一下，现在你现在是UX设计师A1，我们现在因为某项用户需求或业务需求需要处理。

1. 那么最开始我们需要考虑是这个需求用按钮还是用其他解决方案解决。最后我们决定了使用按钮的方式。
2. 然后再考虑一些视觉因素，例如框线、背景块、描述、颜色、阴影、字体等元素，每个因素都需要考虑一遍……
3. 再考虑页面中的位置关系，在页面靠左还是靠右？与四面保持多大间距？……
4. 再加上互动因素，悬停的时候、点击的时候、选中的时候、不可用的时候，再加上后续结果是跳出弹窗？打开新页面？还是仅仅是页面的小变化？……
5. 嗯，不错好像设计做完了，评审一下，大家似乎都同意了。然后交给视觉设计师C1处理视觉。差不多之后，再交到前端工程师小B1手上，啪啦啪啦敲一堆代码，好像实现了。
6. 验收的时候又发现和最初设计并不一样。前端怪你某个标注没做清楚，然后就又拉着前端改改改……
7. 如果又要做个按钮，设计师A2与工程师B1之间又如何进行设计连接？工程师B2如何快速修改工程师B1的代码？他们与组织中其他的设计师AN和工程师们BN又如何连接？……
8. 又到某次软件需要版本升级，需要对按钮进行统一的改色和调整，不过之前的几个前端到换到其他部门了，新的前端工程师B3发现软件中的按钮，尽管都是按钮，但代码都不相同，他花了非常多的时间找到了各个按钮的代码并逐一进行了更改……
9. 而这些仅仅是一个按钮，如果再加入表单、选项卡、标签栏、搜索栏、树形控件等等组件……停停停，已经脑溢血了。

尽管A1设计师和B1工程师的自己的习惯可能类似，但由于参与人数的增多和任务量的增多，每个人都有自己的见解与习惯；考虑这一个按钮中的每一种元素，回忆一下数学中的排列组合问题，最后将发现同一个问题的解决方案的组合情况将会产生成百上千甚至万种可能，而这里很多都是重复工作。

怎么办？我们需要定义明确清晰的规则，让不同的人都能为统一问题达成相对一致的解决方案处理，即达成设计工程化。

设计体系便是一种解决办法。但尽管是叫“设计体系”而不是叫“开发体系”，但这并不意味着这只是设计的事情；因此接下来，我将谈谈设计体系是如何诞生的。

三、源起何处？——应对组织的挑战

上面的故事已经从侧面体现出，当业务与用户的需求迫使组织面对一系列的问题，迫使企业需要探索合适的解决方法。

总的来说，设计体系的出现便是用来应对组织在敏捷、协作和债务处理等方面的需求。

——敏捷响应需求：在多设备、多平台的现在，组织不可能选择每隔几年再更新一个全新的数字产品，因为这意味着在交互上用户需要重新学习，在战略上这种方式的不确定性因素过大，如果失败就意味资源的大量浪费。

就特性而言，数字产品不同于实体产品，往往需要尽快上市，最小成本检验，尽快迭代，以获取更强的竞争力，而且以往写的代码也不会被磨损，需要定期进行维护；因此这些便对组织满足用户体验的速度做出了要求，因此更多的组织逐渐采用如等以敏捷（Agile）和精益（Lean）思维为基础的敏捷开发（Scrum）、设计冲刺（Design Sprint）等方法。

——复杂的协作鸿沟：对用户来说，只需要点击升级便可获得最新的体验，但这意味着这种体验的即时在线化将体验迭代的简单交给了用户，而复杂就留给了组织；UX设计师、前端工程师、产品经理、内容策略师们、可访问性专家等等组成的组织结构和工作流程都需要得到适应性的改变，才能提供快速迭代的流程去完成版本管理、设计管理、债务管理等工作？

Alex Schleifer（Airbnb设计副总监）也提到这样的情况：虽然工具的提升帮助编码的速率和设计的效率都在提升，但最终使设计生效的是多方面的协作的结果，然而原有方式越来越多暴露出在跨学科沟通上的问题，这些依然阻碍着产品创新以实现更佳用户体验的效率。

——债务大量累积： 这里的债务不是指经济上的债务，在设计上，由于设计人员的个体差别和缺乏系统性机制促进设计经验沟通，设计往往在长期的开发过程中提供了许多定制化的解决方案；在UI上可以体现为不同样式的按钮或颜色等、UX上可以体现为同一软件上的交互逻辑混乱等，这造成了设计债务（Design Dept）。

而技术债务（Technical Dept）亦是如此，为同一个问题，不同的工程师使用不同的代码或是令牌标记，加大了代码设计与维护、拓展的难度；同时，我认为其中还存在一个债务，我将其称之为产品债务（Product Dept），不同类别的产品经理等负责产品定义等职能的人员为同一产品或业务功能提供了不同，但效果相似的产品解决办法。

而且无论你是互联网公司，亦或是传统产品公司，越是庞大的体系，人员就越细分，在整体设计上的知识就越分裂，就越有可能出现同一问题多个定制化解决方案的情况，这会让出现在工程、产品、设计上的债务就越庞大。

这些设计、技术、产品债务让管理、维护都异常艰难；而且只要审视一下我们日常工作的周遭，就会发现债务其实无处不在；那些杂乱的视觉形象应用、那些不统一的工业产品材料与色彩、那些无准则的交互行为、那些不一致的反馈声音、同一数字产品不同的功能模块定义等等……

时至今日，设备和用户的多样性都在激增，以往的标准、工作流程和基础设施都难以支撑；我们用设计和开发应对的问题越来越多，变化也越来越多，但我们一直在定制化和通用化之间无序游离。

可以在一些软件中看到同样的一个功能按钮出现十几种形式，而它们要解决的问题却几乎一样；也可以看到那些拙劣的设计规范中，万物归为一种单调样式，降低了开发成本，却带来用户认知的困难。它们都难以维护，极大地阻碍了组织创造体验、达成商业可持续和创新的效率。

四、组织的应对？996还是一劳永逸？

面对着这些问题，公司只能存在几种选择（Suarez等人，inVison）：

• A-不改变速度雇佣更多的人（通过内部雇佣或业务外包）；
• B-提升员工设计与开发的速度（个人能力的极致压制，996、007）；
• C-改变工作的方式，创建通配式的解决方案，提高设计与代码复用率以提升效率（如模块化）。

大部分组织为了满足快速发展的需要，往往更多采用A和B的方式（例如各种各样的业务扩充，产生了大量对工程和设计人员的需求，如阿里、网易、字节、美团等）。

但提升人员，仍然不能解决定制化方案的拓展问题，仍然存在大量不可复用的方案，造成效率的浪费；好比毒素累积，治标不治本，当达到足够的毒素累积之后，创新将寸步难行。

如果不首先创新构建方式，就无法创新产品，这是非常简单的真理。——Alex Schleifer（Airbnb设计副总监）

虽然组织内也一直在提升效率，但管理只能提升局部效率，工具才能带来系统的变革。

设计体系的提出并不只是为了解决用户体验的问题，而是适应组织内的开发需求。而通配式解决方案的方法则更具系统性、远期性。这便是设计体系的源头，模块化（Modularity）是一个关键词。

五、设计体系的发展历程

早在福特的时代，“流水线”思维就将生产流程模块化进而提升生产效率和生产一致性，形成大批量的工业化时代，形成了强势的美国汽车工业；二战之后，20世纪60年代，丰田作为日本汽车制造商的一分子运用精益生产的小批量生产方法，注重发掘工人的创造力，即时解决问题，响应需求，降低远期浪费。 (E Ries, 2012)

回到软件开发上来。20世纪60年代，越来越多组织发现软件发展的速度已经跟不上硬件的升级，软件开发越来越容易缓慢、难维护且容易出错。在开发上，预算超支、超时运行，在使用效果上效率和质量都很低下；在运维上，不符合要求、难以维护管理代码，容易造成软件无法交付。

硬件与软件之间的差距以及解决这个问题而造成的困境，软件危机（Software Crisis）便出现了。

没人能对这些问题视而不见，开发者与设计师的先驱们开始探索解决方案。

1968年，第一届北约软件工程（NATO）会议上，道格拉斯·麦克罗伊（Douglas McIlroy）提出了基于组件（Component-based）的开发方法，通过复用代码来提高编程潜力的方法，减少编程的工作量，同时能帮助编程工作更高效、更易于扩展且灵活，提升软件开发速度；因此这被认为是有可能是解决“软件危机”的方法之一，这种方法可以算是早期的设计体系的基础雏形。（软件危机&INvision）——维基百科，关于软件危机的描述

而在设计界，也有先驱提出了类似方法。1977年，Alexander等人通过其书A Pattern Language，提出了模式语言（Pattern Language），期望用系统化的方法解决设计建筑、城镇和建设方式的问题，帮助形成一种实现为250多种不同类型建筑的持续性方式（Koivisto，2019）；这种语言通过共享共同的模式，用共同设计的方式将更多人纳入设计过程。

如果每个模式都是解决共同的问题，那么当面向同样的问题时，用模式等方式快速应用以前的解决方法将可能是高效的工具；这里的模式（Pattern）便是用户界面设计中的循环解决方式，模式库是特定用户界面上重复设计元素的集合。

在网页开发时代，网页设计师用基础的网页架构就能搭载数以万计的页面。

21世纪初，YUI和jQuery UI等库的引入，为开发人员提供了一套小部件和模式的工具包，以创建更一致的网站用户界面（Forst, 2016）（例如Bootstrap是Twitter开发的基于网页解决方案的前端工具包，供设计师和开发人员使用）。

但这些方法也会些有优有劣，例如Mary Collin就曾对使用Bootstrap开发的网页进行综合对比，结果发现Bootstrap容易导致成果缺乏独特性，看起来外观非常一致；但在另一方面，在移动端响应性和拓展性方面效果很不错，因为足够稳定。

Mary Collin的一些网页对比

在现代，互联网兴起，尤其是移动互联网的兴起，降低了信息分发与复制的边际成本和提供了庞大的用户量；即时在线的网络为数字产品的测试和快速迭代提供了可能，良好的用户体验能为企业创造的价值将远超传统时代，体验的重要性迫使数字产品不得不用更快速的升级换代过程满足用户需求。——（俞军，2020）

但规范或库本身是静态的，依然具备过多的不确定性，并且缺乏对开发全链路的支持，尤其是未来的每一次的设计如何决策。

因此进一步，一些通用设计资产(Design Assets)被逐渐固定下来，并辅以使用的规则描述，设计模式（Design Patterns）逐步形成，为协作而生，通过为重复的共同问题快速生成解决方案，并尽可能在整个组织内保持一致以提升效率。因为类似的原因和目的，也同时产生了例如样式指南、设计语言、内容指南、甚至是品牌识别系统等等类似产物。

在软件开发问题上，设计规范和设计模式成为内部设计师们依靠复制粘贴进行传播的文档，亦或是前端工程们网上开源共享的模式库（Pattern libraries）或组件库。

与设计模式不同，模块化设计（Modular Design）引入了敏捷设计方法的思想；建立在以前的基础上，让解决方案的更快、更短的迭代，前端框架是提供特定解决方案和特定外观和感觉的工具”（Frost，2013）。

框架本质上是模块化的，它们专注于单个项目或设计问题（Frost，2013）；对于多个设计问题，框架、模式库或模块化设计本身不足以系统地使用，这样的背景下，便迎来了设计体系的涌现。

六、大量涌现的设计体系

2013年，Brad Forst提出了原子设计（Atomic Design）理论为设计体系的出现奠定了一波理论热度，提供了更加形象化的描述说明；这让更多人意识到这些问题的存在，并且提供了易于理解且广泛传播的理论基础和解决方案。

Brad Forst，原子设计（Atomic Design）理论

原子设计理论将交互元素似化学因子一般逐步拆分。

• 在最底层级是原子（Atoms，例如按钮、图标的最小组件等）;
• 原子构成分子（Molecules，分子由两个或多个携带自身属性的原子组装而成，并形成更实质性和功能性的组件，例如由表单标签、输入和按钮组成的搜索表单）;
• 分子组成为有机体（Organisms，分子和原子组成的更大组装体，是界面的一部分，如导航栏或标题）;
• 再组成为模板（Templates，将原子、分子和有机体等相对抽象的属性放入情境中，接近最终解决效果，但更关注底层页面结构）;
• 最后这些模板在设计师和工程师的协作下，变成实际的页面（Pages）。

这是一种逐步拆分式的模块化方法。

他建议用模式库（Pattern Library，也被称为用户界面库、组件库、资产库等）集合构成用户界面的可重用组件，并通过指南（Guideline）指导如何创建，以进一步综合了风格指南、流程指南、设计语言等等设计指南；包括他之内的几位设计体系先驱都提出要进一步整合领域内语言，开始更多地使用设计体系（Design System）这样的语言来代表类似的事物。

理论如此，实践永远不会落下。互联网的广泛普及带来用户需求量爆炸，对公司来说，越来越多的业务量压力和一致的体验需求的迫使下，越来越多的企业推出了自家的设计体系。

2014年伊始，Google推出了质感设计体系（Material Design System），类似的时间前后Atlassian搭建了Atlassian设计体系和Airbnb也在内部搭建设计体系（即后来的设计语言体系，DLS，Design Language System）；在此之后，一系列公司跟进开始研究和开放自己的设计体系。

例如Apple的人机界面指南（HIG），Microsoft的流畅设计体系（Fluent Design System）、IBM的碳设计体系（Carbon Design System），Salesforce的Lightning设计体系、Shopify的Polaris设计体系,甚至一些英国、美国、澳大利亚等公共部门也推出了自己的设计体系，如英国政府的GOV.UK设计体系。

而在国内，搭建的比较完善的有知名的蚂蚁金服Ant Design设计体系，还有Element，以及View UI等中台设计体系，以及许多存在于部门内部、仍然只是设计规范、或者设计体系不完全体的内容。

——插个题外话，微软的流畅设计体系（Fluent Design System）是我这篇文章最开始的起点，从简单论述微软如何统一用户体验聚焦到流畅设计体系。

当然关于Fluent Design System的更多内容，我会在本系列文章之后，单独出篇文章描述我的发现【稿子都差不多了，写着写着就写成了设计体系系列文章哈哈】。

我们现在知道设计体系是为了什么了，但在现在的阶段，问题不是能搭建什么，而是如何能更好地搭建。

“体验工程的建设已经远远不止于一套设计规范或一套组件库，他需要一套完整的系统来支撑，解决内部协作的一致性问题，解决设计系统更新的周期性问题，解决一群设计师与工程师如何规模化的生产各种业务 UI 的问题，从而最终解决用户体验一致性的问题“——Alibaba Fusion Design

文章来源：人人都是产品经理  作者：龙哩个龙

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

借着疫情期间在家休假的时间，将平时用到的一些零零散散的图标绘制方法与思路进行了一次全面的汇总与沉淀。从实习期间画一组图标的无从下手，每一个图标看起来都像是散装的一样，到后来慢慢学习与练习，到现在变得了解了图标的绘制流程，过程也是比较麻烦，因为很少有全面的图标讲解文章，都是看一篇懂一点，然后在揉到练习当中。所以本篇文章尽量将图标进行细致一些的流程说明，有不足之处还望指教。

图标的可用性

图标可用性，顾名思义就是图标绘制出来是否能被用户所看懂并快速识别，是否可以为业务赋能。为此我总结出了四条图标绘制的评判标准。

1. 凸显性

用户是否能在某页面上迅速找到该图标，凸显性的目的是可以快速查找，帮助用户做选择。图标在识别的速度上远远大于文字，所以在一些页面中的重要功能使用图标的目的是为了吸引用户的注意力，让重要功能得到凸显，提高重要功能的点击率。

2. 可识别性

图标的目的是要让用户猜出他看到的图标所表达的意义，有什么作用，以及点击后会出现什么样的场景，发生什么样的事情。所以一个图标的好与坏最重要的因素就体现在这里：图标的可识别性与可预知性。

影响图标可识别性的三点因素

• 视觉复杂性：图标的细节与组合图形的元素
• 熟悉性：图标中图形所表达语义的熟悉程度
• 具体性：图标或者图标中的图形与现实生活中物体的相似程度

3. 美观度

图标是否美观，对用户是否有足够的吸引力。在《设计通用法则》一书中有一条设计法则是：美即适用效应。不管任何事物，美丽的外表都会给人带来好感，让人觉得这种事物在任何方面都非常美好。作为设计师，把一件事物美观化是一件终生的必修课，用户对图标或者界面的第一印象就是始于颜值。

4. 业务属性

图标是否符合业务属性，是否可以唤起用户的使用情绪，提高点击率，起到为业务赋能的作用。在界面中，我们设计的图标最终目的不只是让用户觉得它美观，而是要为我们的产品赋能，什么是为产品赋能呢？通俗来说就是使图标能够提升点击率从而给公司创造收益。

图标如何为产品赋能呢？

• 符合产品与业务属性：比如儿童类产品，图标就要圆滑，多彩，看起来萌一点的感觉；如果是金融类的产品就应该使用微圆角，直角，中性色，金色来代表金融的庄严感与高级感。
• 唤起用户的使用情绪：比如在大众点评 app 中，有关与食品的图标都使用橙色的拟物，因为暖色可以给人们带来食欲感，微拟物配合暖色系就可以唤起用户对食品的情绪感。
• 引导用户点击，提升点击率：想要让用户点击一个内容，那必须要有足够的吸引力吸引用户去点击，一般来说美观度越高、趣味元素越多的图标可以占据大部分的吸引力，一个图标在页面中所占的比例也会影响对用户的吸引力，合理的文案搭配也会吸引用户去点击，比如优惠信息，新功能提示等。

图标的类型

1. 线性图标

线性图标，顾名思义，即图标是由直线、曲线、点在内等元素组合而成的图标样式。线性图标具有辨识度高，清晰唯美，简约易看等优点，线性图标不会对页面造成太多的视觉干扰。缺点是：线性图标的创作空间较少，太复杂的线性图标看起来会让人感觉到累。

2. 面性图标

面性图标，即使用对图形内容进行色彩填充的图标样式。面性图标是现实生活中物体的缩影，优点非常多，比如表意能力强，细节丰富，色彩丰富，情绪感强，视觉突出，创作空间大等。面性图标可以让用户迅速定位图标位置，快速预知点击后的状态。但是面性图标在页面中不可过多出现，否则会造成页面臃肿，难分主次，用户视觉疲劳。

3. 混合型图标

在设计图标类型的时候，不一定局限于单纯的线性与面性，也可以两者结合，让图标即有线性描边的轮廓，还有色彩填充的区域，混合型图标可以让页面变得更加有活力，同时还可以吸引用户的注意力，美观与创意性强。但是混合型图标在商业产品中要谨慎使用，因为使用不当会让页面变得杂乱不堪，用户无法识别图标表达的语义。

图标的色彩

1. 色彩情绪

色彩情绪即颜色心理，指不同波长色彩的光信息作用于人的视觉器官，通过视觉神经传入大脑后，经过思维，与以往的记忆及经验产生联想，从而形成一系列的色彩心理反应。在任何场景下合理使用色彩心理可以调起用户情绪，还可以让用户产生联想进而快速识别。

在设计图标的时候，合理的运用色彩情绪，会使图标更具有科学性，可以让用户在使用的过程中更加自然、舒服，同时也会增加用户的识别速度唤起用户的使用情绪。

色彩情绪表

2. 配色方法

在配色时，我们采用更具备科学性、更符合人类感官的 HSB 系统进行配置。在根据主色配置渐变色时，我们经常是在主色的基础上加白或者加黑。但是只加入大量的白或者黑就会改变原本色彩的明度与饱和度，从而使画面显得雾蒙蒙的，不够清晰通透。正确的做法是在给主色变亮减暗的同时，改变主色的饱和度。在 hsb 色相条中，最亮的三个颜色分别是，蓝紫色，青绿色与黄色，如果需要加亮主色就在混白的同时将蓝色向青色改变色相，如果需要减暗则是相反，这样在调制渐变色变化的过程中不会出现太脏的颜色。

3. 配色方案

常见的色彩搭配

中性色（黑白）+主色、主色+点缀色、主色+透明度、单渐变、双渐变错层、撞色叠加穿透等效果。一般常用的就是中性色+主色、主色+点缀色。

点缀色配色

• 互补色：互补色就是在色环上距离 180° 的色彩，形成具有视觉冲击力的色彩。
• 近似色：近似色是在色环上距离 45° 左右的色彩，形成的配色效果风格和谐统一。
• 对比色：对比色是在色环上 120° 左右的色彩，可以产生较为强烈鲜明的视觉效果。

图标绘制技巧

1. 像素对齐

我们在绘制图标的时候，应该将图标的每个像素尽量对齐于像素点，这样导出图标时像素的边缘不会出现锯齿，不会出现过于模糊的情况。通常在绘制时我们应该去除绘制软件中 x 与 y 轴，宽（w）与高（h）的小数点，这样就可以避免无法对齐像素的情况。

2. 图标参考线

在绘制两个或者以上的图标时，为了避免多个图标出现大小不一的情况，我们应该使用由谷歌材料设计语言提供的图标参考线进行绘制，使用图标盒子可以让一整套图标在视觉效果上更加统一和谐，不会出现一大一小一长一短的情况。

使用方法

先绘制一个 152*152px 的正方形，一个 176*176px 的正圆形，一个宽 176*128px 的水平矩形和一个 128*176px 的垂直矩形，圆角为 4px，然后将这个四个形状进行水平居中对齐，之后得出一个图标的参考线。

在宽度相等的情况下，正方形的面积要大于正圆的面积，所以在绘制圆形图标时应该将圆形的上下左右四个顶点顶齐与图标盒子正方形区域的四条边；在绘制方形图标时应该将方形的四个角点顶齐与圆形参考线的外围边；在绘制横向矩形与纵向矩形图标时，应该将图标的左右边或者是上下边控制在正方形的参考线之内，这样矩形图标绘制出来会更加的圆润，相对于其他的形状图标更加匹配。

3. 可访问性

我们绘制的图标必须要保证清晰度，可辨别性。不管是在强光下还是正常光下都需要良好的可读性。这就需要图标不论是自身元素之间的对比度还是和页面底板背景之间的对比度都需要很好的可读性。我们检测图标的可读性通常要将图标的背景色底板在黑色和白色之间进行切换对比，不论是黑色还是白色的背景都可以看清图标的全部细节，还需要确保图标中的每一种颜色都是可见的。第二就是将图标拿到强光下进行观察，在强光下是否可以看清图标的主题结构，图标是否有足够的辨识度。

在绘制图标时，我们可以参考 WCAG 2.1：图形和用户界面组件的对比度至少为 3 : 1 的标准进行相应配色，以达到良好的可视状态。

可访问性测试：https://webaim.org/resources/contrastchecker/

4. 统一性

在绘制多个类型相同的图标时，我们需要注意这一套图标合集需要在视觉上保持统一性。在一整套产品中，会有很多种图标，但是图标的功能不一样，所表达的内容也不同。这时，图标一致性的意义就体现出来了，根据格式塔原理中的相似性原则：人们会将如元素彼此相似的东西感知为一组。这也意味着如果具有相同功能、含义和层次结构级别的元素，则应在视觉上保持统一匹配。我们倾向于将彼此相似的元素视为同一个分组，相似性可以帮助我们组织和分类页面里的元素对象，并将它们与特定的含义或功能相关联。有不同的方法可以使元素被认为是相似的，这些方法包括颜色、大小、形状、纹理、尺寸和方向的相似性。

图标内容的统一会让用户明白相似的图标所代表的的功能也相同，而且在视觉上也更加和谐美观。因此我们在绘标后还需检查线条的粗细比重，边角的大小，配色方案，细节层次和设计元素在整个合集中是否是不变且一致的。

5. 图标呼吸感

呼吸感的意思就是适当留白。在设计中，适当的留白可以突出主体内容，让内容具备易看性。不管是图标还是界面，元素与元素之间都应该存在一定的间距。在图标的绘制过程中，我们应该注意图标元素之间的间距不宜过近，元素也不宜过多。图标是一个物体的简略缩影，目的是为了表达内容，让用户快速理解，但是在有限的空间中，太过复杂的细节会影响图标的识别速度。因此在图标的绘制过程中应该删除所有无法传达图标意义的元素，避免使图标变得太过复杂难以识别。

6. 合理运用布尔运算

布尔运算在设计行业中被得到广泛的运用，比如工业设计，影视后期，logo 设计等，布尔运算具有一致性与规范性的优点。我们在设计面性图标的时候可以合理使用布尔运算进行绘制，这样绘制的图标具有吸引力和说服力。

7. 页面层次感

在页面中，有需要吸引用户点击的图标，也有起到辅助作用的指示图标，还有引导用户操作的图标，这些图标在页面中占据着不同的地位.在所有图标中，有色图标强于无色图标，多色图标强于单色图标，面性图标强于线性图标，带背景图标强于无背景图标，在设计图标的时候应该根据业务需要进行视觉强弱不同的设计。

8. 业务属性

如文上所说，图标采用与业务相符合的色彩搭配会让用户在使用的过程中更加自然、舒服，同时也会增加用户的识别速度，唤起用户的使用情绪。一个图标的绘制是否具备商业价值也恰恰体现在这里。

如下图所示，左图是斗鱼直播 APP 的截图，右图是京东金融的图标截图。这两款产品的业务以及所对应的用户群体完全不一样，斗鱼是一款直播的产品，直播面向的用户群体是青少年，所以整体的产品调性是：萌、活泼、多彩、绚丽、时尚等，斗鱼直播的图标绘制需要面向年轻人，色彩的高饱和与有趣的元素来抓住用户的眼球。但是京东金融是一款理财的产品，面向的用户则是中老年，大多数都是有一些存款的人，这些人不需要斗鱼那样花里胡哨的元素，他们只在乎这个产品是否安全，利息是否高，所以京东金融这个产品的整体风格就需要偏向于：安全、高端、大气，这样才能给用户从视觉上营造信任感。我们设计图标时通常使用产品的调性作为主风格，但是像美团淘宝这些业务众多的产品中，我们就需要根据产品下的细分业务进行风格定位，然后设计中相应融入产品的品牌元素，使用合理的色彩情绪等让图标变得更符合业务的风格。

最终测试

当我们的图标绘制完成后需要测试这一组图标的重心是否统一，常用的方法是使用标准的正圆形和正方形来和所有绘制的图标进行对比，保证所有的图标重心相近，视觉统一。也可以采用不同角度的观察法，可以从上下左右四个角度去观察图标，看看图标在不同的角度下重心是否统一。

一组图标的绘制流程

1. 情绪板

情绪板是在执行一项设计操作之前非常重要的一个步骤，情绪板并不是像设计平台展示作品集里那样放几张图片，几个关键词，而是一套对接下来设计的一个风格走向定位。根据不同的用户人群，不同颜色的色彩情绪，不同产品的业务，将用户调研的结果，产品的背景进行总结与思考，定位接下来的设计风格。

2. 绘制流程

选取照片

观察生活，对想画的图标进行照片实物造型的提取。图标是对生活中事物的精简概括。利用现实照片作为设计参考可以让绘制出的图标更真实，辨识度更高，还可以做到差异化设计。

造型勾勒

使用矢量软件的基本图形与钢笔工具描着照片进行轮廓的绘制。

简化优化

简化草稿轮廓的结构，只保留一个物体的主要特点元素，删除多余元素。优化图标细节，需要时将图标线性转面性。

业务属性

根据业务需要，调整图标风格，添加质感。

3. 制定规范

无规矩不成方圆，规矩的出现可以让一切杂乱的东西变得合理，统一起来。在设计上也是如此，规范具有统一输出，指引细节、便于查看的好处，规范就是一组图标中的规矩，所有图标的绘制都按照规矩来，最终的成品就会显得井然有序。

在制定规范时，我们通常先绘制出一个符合业务风格的图标，然后根据这一个图标定制后续的图标规范，最基本的规范便是描边宽度，断点位置、圆角大小，主色辅色，渐变角度，点缀元素，光影角度等，在一组中的图标需要在这些图形属性中进行统一，这样的图标虽然形状不一样但是在视觉上看起来是属于同一合集的。

制定规范一般分为三个过程：

• 拆分细节：将图标中的细节元素进行分解，在规范中制定细节元素的使用法则。
• 风格定位：根据产品调性，业务属性在规范中制定相应的色彩心理、质感风格。
• 功能划分：功能相近的包括色彩、质感应该采取相近性。

文章来源：优设网    作者：箫灬西人生

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

来源 | BranD的好奇心（ID: BranDmag）

2021年最受欢迎的字体

shillington网站评选出20款字体

众所周知，字体对于塑造品牌、塑造企业形象有着举足轻重的作用，其设计以本身的文化性、时尚感以及表形表意的双重作用都具有同等重要性。由此可见，很多企业以及品牌都采用字体作为自己的独特标志。

▲Garnett字体

前段时间，shillington网站出了一份关于2021年最受欢迎的20款字体设计的测评报告， 可以看到很多字体的复兴，榜单上这些字体设计不仅仅局限于新颖和时尚，还包括了一些较复古的，视觉上更为成熟的字体，这份榜单都会给设计师们带来哪些惊喜呢？那就让我们一起拭目以待吧！

01Futura Now

Futura Now是Monotype工作室设计的一款字体，它不仅包含了102种可变样式，还是经典无衬线字体Futura的权威版本。近90年来，该字体广受欢迎，使用范围也很广，从儿童读物到时尚杂志，都有它的踪影。

Monotype的创意总监Steve Matteson还说过：“尽管是以现代字体而闻名，但Futura Now却出奇的温暖。”它更像是一个中间地带，处于粗矿与温暖的边界，不卑不亢，一切刚刚好。

02FS Renaissance

FS Renaissance也是Monotype工作室发布的一款独特显示字体，它由字体艺术家和设计师Craig Back以及创意总监Pedro Arilla合作而诞生，这种单一样式的字体探索了艺术与设计的关系。在艺术家和设计师的共同努力下，每个字母都被制作成独立的艺术品。

文艺复兴时期代表着艺术，科学，学习和哲学的蓬勃发展，FS Renaissance字体受该时期的启发，特别强调了将字体作为艺术品或雕塑的想法，并在兼具外部优雅感的印刷基础上，使其的设计在功能和艺术之间取得了完美的平衡。

03Neue Haas Grotesk

在1957-1961年期间，它经过Max Miedinger设计、Eduard Hoffmann艺术指导完成了对经典字体Helvetica的现代诠释。但是Christian Schwartz设计师认为Helvetica的数字化涉及了太多的妥协，因此，经他设计出来的全新数字版本Neue Haas更忠于原版字体。

该字体作为一款很实用的无衬线字体，具备着一定的结构严谨以及简洁美观的优点，其线条更是干净利落，毫无多余的点缀，这在视觉上，它的效果很佳。还有，它现在可以从谷歌字体库中免费使用了。

04Circular

Circular是由Laurenz Brunner设计并通过Lineto发行的无衬线字体，它作为一款无衬线字体，虽然字型具有几何形状的特征，但它能比大部分的同风格作品更具吸引力和特色都得益于一些古怪的元素。

05Whyte

这是一款由Dinamo设计设计的无衬线字体，它可以在平滑与尖锐的视觉中取得平衡与过渡的良好效果。最令人兴奋的是，它这款可变字体得到了InDesign的支持，我们相信2021年它将会流行起来且成为大众追捧的字体之一。

06GT America

由NoëlLeu和SebMcLauchlan设计的GT America本质上是延续了19世纪美国哥特式和20世纪欧洲新哥特式字体的风格。它提供84种样式，在字型宽度和字重上融合了两种传统设计元素并将此特点发挥到淋漓尽致。

07Noe Display

Noe Display是一款显示字体，它轻而易举地彰显出其大胆的笔触方式，以常规黑色粗体为主，字母之间可以通过楔形的衬线转折。不仅如此，该字体还为整体视觉赋予了富有戏剧性和冲击力的体验。

08Basis Grotesque

Basis Grotesque最初是按常规字体的粗细来进行绘制的，主要途径仅是用于重塑摄影杂志《Hotshoe》。在这之后，由Colophon开发并发布了该字体，并在三年后用于商业用途。该字体在字重之间的比例，及其字体骨架上均有着微妙的平衡。

///

09Eksell Display

Eksell Display是来自传奇瑞典设计师Olle Eksell（1918–2007）于1962年创作的一款独特的衬线字体。最初的字母形状是在Olle位于斯德哥尔摩的工作室中工作室中绘制的，在此版本中，这些字母已经通过很仔细的数字化处理，并发展成四种不同的风格。

10Lars

无衬线字体Lars是一款通用字体。该系列以圆形符号为主，可以区分字母大小写，涵盖了多种语言，并且可读性强。

11Simula

Simula作为一款衬线字体，还是艺术家、设计师Justin Sloane的设计的首款字体，它在一些小细节上的设计处理得很好。该字体是对手写字体的重新诠释，将传统的手写字风格演绎得淋漓尽致。

12Parnaso

当今，紧实，瘦弱和人文主义的衬线真的很流行，这款字体就是一个很好的例子。

它的创作灵感来自19世纪复兴的古罗马风格，这是对Didot和Bodon现代风格的最好反击，其具有高对比度和鲜明的细节，常常成为编辑或广告作品中首选。该字体还提供了八种不同字重和宽度的样式，可以组合在一起或独立使用。

13IvyMode

IvyMode是由设计师Jan Maack专门为杂志定制开发的一款无衬线字体，它一共拥有10种字体形式，具有高对比度和突出的笔划结尾，自然而然，成为奢侈品牌们的首要选择。

14Orpheus

Orpheus字体的设计灵感受到Walter Tiemann在1928年设计的两种衬线字体的启发，该字体在包装和娱乐设计中很受欢迎。受手写体的影响，它的斜体设计将古典罗马美学风格与装饰艺术的魅力结合在一起，打造出别具一格的视觉效果。

15Garnett

Garnett是由Connor Davenport设计并通过Sharp Type发行的带有现代风格的字体。它的设计灵感来自于19世纪英国古怪的怪诞风格以及受到美国哥特式风格的影响，该字体系列有六种字重，还带有与字重相匹配的斜体。

16FS Meridian

这是一款充满几何形状的字体，灵感来自时间的精确但不完美的性质(Meridian有‘子午线’含义，该字体因此得名)。该字体还具有宽阔的单线外观，富有人性化的元素和可不断进行延伸的形式风格。

17Moderat

Moderat是一款几何无衬线字体，其特征是笔画间的对比和棱角分明的细节。该字体适用于正文和屏幕显示场景，一共拥有42种样式，还相对应地匹配斜体。

18Miller Banner

Miller Banner是一款经典的字体，它广受人们欢迎，该字体是由Richard Lipton改编自Matthew Carter的热门美剧《米勒》的宣传字体。它有锋利的线条感和非常戏剧性的笔画对比，非常适合在文章标题中使用。

19Monument Grotesk

Monument Grotesk是一款独特而自信的字体，它看起来未经修饰和造型奇特且十分具有粗狂感。该字体有7种不同的字重可供选择，包括斜体，mono和semi-mono cut以及带有相应斜体的粗体和黑体。

20Bely

Bely是由Roxane Gataud设计的富有冒险精神的衬线字体，其特点主要体现在尖锐的三角形衬线上，它含有两种粗细匹配的斜体以及显示字体，我们可以在粗细笔画之间看到很明显的对比。在Altrincham项目中可以看到它的运用效果。

字体本身作为一种文化传递的载体，其的魅力就在于让大众可以感知到它所传达的设计理念。看完以上的字体，有哪款字体令你印象特别深刻的呢？欢迎小伙伴们到评论区留言喔~

图片 | 来源于网络

*本篇部分文字资料整理于shillington网站，

仅供学习与分享，版权归原作者所有。

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

2021年世界地球日鼓励自然过程、新兴的绿色技术和能够恢复世界生态系统的创新思维

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

前言

2020年可以说是一个风险年，但更是一个机会年，全球各类资产都出现了大行情机会，市场的投资热情再次被点燃。借着这股东风，在2020年年尾，我们开始了对公司金融产品的优化改造工作，希望通过改造提升产品的用户体验，配合来年的运营活动，提升产品的用户数和活跃度。改造工作主要为优化开户流程、提升社区氛围、完善交易功能三个部分。后续我将通过系列文章对这次优化设计过程中的思考进行分享。

表单作为平台与用户联系最为紧密的一环，良好的表单设计可以带给用户流畅自然的用户体验，保证用户情绪的正向增长，而混乱无序的表单则会引起用户的负面情绪，影响甚至阻碍用户操作的完成，降低用户对品牌好感度和信赖度。对于我们这样的金融产品而言，产品内存在着如开户表单、出金申请表单、调整杠杆申请表单等形形色色的表单，如何将这些表单整理归纳形成一套完整的表单设计体系，带给用户统一、高效且优质的填写体验，是我们这次表单优化的主要的任务。

系列文章中关于表单设计部分我将分为上下两期来向大家分享，体系化表单设计（上期）主要介绍在项目中总结出的表单设计中的方法论，下期则是介绍方法论在我们项目中实际的应用，希望这次的分享能为你今后的表单设计提供思路与参考。

1 认识表单

1.1 表单的历史

表单在我们工作、生活中的使用由来已久，在还没有互联网的年代，表单就已经是人们收集和存储数据、信息的重要手段，并一直沿用至今。如体检时填写的体检表、入职时填写的入职登记表、银行开户时填写的开户表都是使用的这种印刷的纸质表单。它们身上有很多设计可以作为重要的参考，帮助我们优化 UI 中的表单元素。

表单是 UI 界面中最为常见的元素，它通常是用来搜集和呈现一些数据、信息和特定的字段。表单的应用极为广泛，比如登录应用时填写账号密码、网上购物时完善订单信息、OA系统中提交休假审批、修改个人中心信息时……都是在和表单发生互动。

1.1 表单的构成

表单的目的、内容、大小等虽然各有不同，但是表单的基本构成元素是相对固定的，在设计过程中，设计师需要合理组织这些元素，帮助用户在填写表单时，轻松愉快的完成，表单主要组成部分如下图。

1.标签：告诉用户此处相应的输入元素是什么;

2.输入区：可交互的输入区域，根据字段类型使用相应的交互组件;

3.占位符：对当前项进行额外的信息描述;

4.前置图标（可选）：描述文本所需的输入类型和特征;

5.后置图标（可选）：对输入内容进行控制，如：下拉的展开与收起、清空；

6.帮助（可选）：提供表单内容的注释或辅助类容，如：说明、注意事项；

7.反馈（可选）：告知用户当前操作可能或已出现的问题，如：提交成功、错误提示、网络问题；

8.键盘（可选）：在文本编辑时需要使用键盘，如：设备系统键盘、应用内置键盘；

9.操作按钮：操作按钮是在表单的结尾，如：提交、下一步、清空所有信息。

2 如何打造令人愉悦表单体验

在如今这个互联网时代，我们几乎每天都会接触到形形色色的表单，作为用户与产品链接的枢纽，表单设计的好坏会直接的影响产品的实际数据表现。好的表单结构清晰，交互合理，用户能够高效愉悦的完成表单填写，为用户节省了时间，同时也提高了自身产品的转化。而差的表单往往信息逻辑混乱，填写效率低，且容易让人产生挫败感而中途放弃，在无形中浪费掉了很多潜在商业机会。是什么造成了不同表单之间出现如此大的体验差异，我们又该如何做才能设计出令用户愉悦的表单呢？在实际项目过程中，总结出一套适用于移动端表单设计的路径图-通过做好五个步骤，设计出令人愉悦的表单。

2.1 表单框架选择

合理的表单框架选择是打造用户友好型表单的基础，在进行表单设计时，我们首先需要依照表单的使用场景和复杂程度，选用最为恰当的表单框架。确定好表单框架，也就决定了后续设计中表单信息如何组织以及呈现。我们将表单框架划分为“录入方式”、“标签布局”和“按钮逻辑”三个部分，在表单设计时通过对这三个部分的选用来确定最终的表单框架形态。

2.2.1 录入方式

按照表单录入方式的不同我们大体上可以将表单录入方式分为“单步录入”、“分步录入”和“分级录入”三种，在进行表单设计时需要根据实际情况选择与使用场景匹配的录入方式。

1 单步录入

单步录入是表单中最为常见的录入方式，在一个页面内呈现所有的录入项，结构简单，快速录入、快速提交，适用于录入项较少的表单。

2 分步录入

相对于PC端而言，移动端手机屏幕尺寸较小，一份在PC端1-2屏就能完全展示的表单在移动端往往需要7-8屏。将一个需要7-8屏才能展示完整的表单放在一个页面内让用户填写，用户容易产生抵触情绪会造成表单完成率的降低。

为了提高用户填写效率，减少用户的抵触情绪，我们可以将一个冗长的表单拆分成多个步骤，分步录入。通过拆分成一个个步骤，让表单信息呈现更为清理有条理，并且能引导用户逐步填写完成表单录入。

当表单处于以下4种场景时选择建议选用分步录入模式:

1.表单录入项过多，在一个页面内已经不能合理清晰的组织传递信息。

2.表单内容的录入方式存在较大差异，不适宜在一个页面内进行展示。

3.表单录入项在业务上存在先后顺序，只有先完成上一步字段录入，才能够进入下一步。

4.在业务上很重要的表单，为了让用户能够沉浸、快速的完成表单填写时。

分布录入模式下步4种步骤导航选择：

1.文字导航：当表单为2步录入表单时，我们展示步骤条带给用户的引导意义并不大，通常这种情况下我们会选择省略掉步骤条，只展示当前步骤名称，给予用户提示。

2.步骤条导航：当表单录入步骤为3-4步时，我们可以在页面顶部放置步骤条显示所有步骤内容标题，用户通过步骤条能够对表单有一个清晰的预期。

3.双层步骤导航：当表单录入步骤大于4步时，受限于移动端屏幕尺寸，横向上不够容纳步骤数太多的步骤条，这时我们可以其中某些关联的步骤归纳为一个大步骤，形成双层步骤导航。

4.进度条导航：当表单录入步骤大于4步，又担心双层导航给用户传递出表单极端复杂的印象，劝退用户。这时我们可以使用进度条导航，用百分比进度条来展现表单填写进度。

3 分级录入

分级录入大家可能相对较为陌生，分级录入在B端产品中会有相对多见，一般运用于有明显上下级关系的表单，如项目管理工具中新建任务表单，在新建任务的同时还能新建下属子任务。又如客户关系管理软件中，新建订单的同时新建下属的订单明细。我们可以将使用分级录入模式的表单视为两张表单，子表单添加的数据会回显到主表单上。

2.1.2 标签布局

标签用于提示用户需要输入的是什么信息。合理的标签布局结构，能够提高用户的阅读效率，还能降低信息填写时的错误率。常见的标签布局形式有：左右结构、上下结构和浮动结构。不同的标签布局都有各自的优点和缺点，我们需要根据项目实际情况来选择最合适的标签形式。

1 左右结构

左右结构是目前最为常见的标签布局形式，左右结构中标签和输入区域在一行内排布，其中标签位于左侧且居左对齐，输入项位于右侧有居左和居右对齐两种对齐方式。

优点：节省纵向页面空间，在移动端有限的页面空间内能展示更多的录入项。

缺点：标签的长度无法确定，视觉上显得参差不齐，表单的信息浏览和填写效率一般，标签横向展示空间有限，对于多语言适配场景不太友好。

2 上下结构

上下结构也是我们能够经常在表单中见到的标签布局形式，上下结构中标签位于上方且居左对齐，输入区域位于下方也为居左对齐。

优点：用户的视觉浏览路径相对于左右结构来说较短，拥有较强的信息浏览和填写效率，标签横向展示空间充足，对于多语言适配场景友好。

缺点：占据纵向空间多，一屏内能展示的录入项较少。

3 浮动结构

Material Design中文本录入的标签形式就是选用的浮动结构，在浮动结构中标签和提示文字合二为一，正常状态下，标签位于输入区域内部原本提示文案的位置，当用户输入时，内部的标签就会上移为文本输入让出空间，完成填写后标签和输入文案上下排列展示。

优点：结构简单，视觉干扰少，信息浏览和填写效率高。

缺点：填写项过多时，表单信息传递不够清晰。

4 内部结构

内部结构相对于前面3种结构较为少见，比较长出现在登录场景，在浮动结构中标签和提示文字合二为一，正常状态下，标签位于输入区域内部原本提示文案的位置，当用户输入时，内部的标签就会消失，完成填写后只展示输入文案。

优点：结构简单，视觉干扰少，聚焦于操作。

缺点：只适用于如登录等录入项极少的场景，一旦录入项变多，由于录入后不展示标签，将导致用户后续很难判断输入的信息是否准确。

2.1.3 按钮逻辑

按钮作为表单的重要组成部分之一，合理的按钮逻辑能够为用户顺畅完成表单填写提供帮助，表单的按钮逻辑主要由按钮的位置和按钮的点亮逻辑两部分组成。

1 按钮位置

按钮在页面中的位置情况主要有以下3种：

1.顶部按钮：以文字的形式固定在顶部导航栏的右侧，顶部按钮尺寸较小，因为它所占空间有限，因此在操作上相对来说不便于点击。所以这类顶部按钮更适用于「编辑页面」，需要用户谨慎操作。

2.表单底部：按钮跟随表单放置于表单的最下方，根据表单内容纵向空间的大小而上下移动。因为表单内容较多时，容易下沉过多而导致按钮不可见，所以将按钮放置于表单底部更适用于当表单录入项较少不足半屏的场景。

3.设备底部：操作按钮常驻在设备底部展示，适用于表单录入项过多的情况，在表单设计时可以尽量将必填项放置在表单前面，用户填完必填项后就可以点击操作按钮提交或者进入下一步，而不用滑动到表单底部再进行操作。

2 按钮点亮逻辑

1.当表单录入项较少时，且有明确预期按钮何时可用，可以先置灰主按钮，完成必填项填写后再点亮主按钮。

2.当表单录入项较多时，且用户不清楚为什么按钮不可以用，此时按钮可以常亮，并在用户点击时给予反馈，告知错误原因。

2.2 表单信息梳理

在确定好表单框架以后，对于表单内容信息的进行有效的组织也尤为重要，特别是对于一些结构复杂、录入项多的表单，如果不对信息进行组织，很容易显得繁杂混乱，容易让用户在一开始就产生抵触的情绪，甚至选择放弃。那么如何合理有层次的组织信息呢？

2.2.1 简化表单，聚焦核心

我们在设计表单时潜意识里都想要从用户那里获取到更多的信息，表单中因此出现很多必要性较低的录入项，表单也因此变得冗长，让人第一眼就生出「好多信息需要填，好麻烦」的沉重感，在填写表单之前就萌生退意。我们在进行表单设计时需要保持克制，聚焦于表单的核心任务，让表单尽量短而美。那么我们要如何为表单减负，可以尝试以下方法。

1 减少表单中的多余字段

表单中每多一个录入项需要填写，都有可能会失去一部分用户好感度甚至流失一部分用户。在设计时我们需要判断某个字段信息对于用户来说是否有必要在表单中进行填写，尽可能的删减掉额外的无用字段。例如注册表单，如让用户使用邮箱注册，那么用户的姓名字段是否是注册的必选项？如果不是必选项是否可以在之后的信息完善中进行填写。

2 合并表单中的同类字段

在表单中时有一些信息他们本身紧密相关，我们完全可以视情况将其合并为一个录入项，来减少不必要的录入操作，达到简化表单，提升录入效率的目的。合并录入项要结合实际的使用场景以真实的提升表单体验为目的，而不是一味的追求表单的最简化。

3 隐藏表单中的低频字段

根据用户使用数据，适当将使用频次不高、或者提供给专业用户的高级表单项隐藏起来。例如一份表单中有一个填写项，90%的用户都不需要填写，那么默认收起。保持表单的简洁，让绝大多数用户快速完成，避免大量的表单给用户的焦虑，而又满足了小众用户的需求。

2.2.2 先易后难，循序渐进

根据沉没成本的定义：人们在做决策时，受到了自己过去所投入的时间、金钱、精力等因素的干扰，对于先前付出了投资的事情有更强的忠诚度和继续投资的意愿。进行流程设计时也可以遵循这个原理，将容易完成的表单放在前面，这样做有3个好处：

1.简单的表单更容易激起用户的填写欲望，用户会迫不及待地去完成。相反，用户一开始就看到过于复杂的表单，很容易被吓到，从而放弃整个任务。

2.用户通过完成简单的表单，可以增加自信心，即使后面的表单变复杂了，用户也更有耐心去完成。

3.当用户将前面简单的表单完成后，放弃整个表单的机会成本就变高了，即使后面碰到较难的任务，用户放弃的几率也会降低。

2.2.3 信息分组，一目了然

当我们我们设计的表单字段内容较多时，需要合理的对字段信息进行分组，这样整体看起来更加有组织性。接近性（格式塔原理）原则告诉我们： 相互靠近的物体被认为比相互距离较远的物体更有关联性，这样能使设计界面层次有序，视觉清晰，减少视觉噪音。分组时需要注意：

1.内容属性相近或有关联性的放在一组。

2.根据信息的重要性及难易程度排列分组，将选填的表单内容靠后

2.3 录入操作提效

在表单录入设计阶段，我们需要明确认识到一点，用户在面对一份表单时往往没有我们想象中的那么有耐心，复杂繁琐的录入操作可能会直接劝退用户。我们需要做的就是化繁为简，思考如何给用户减负，让用户简单高效的完成表单录入。表单录入操作提效有一些切实可行的方法，下面请我将一一向分享。

2.3.1 设置默认值

对于用户而言，填写信息永远都不是一件有趣的事情，在对用户足够了解的前提下，我们可以选择为表单中的部分录入项提前设置合理的默认值，节省用户的操作时间。默认值的设置不是一个随性发挥的过程，而是基于用户行为和数据的理性判断，并且也不是每个字段都适合设定默认值。关于如何设置合理的默认值，什么字段适合设定默认值，下面几点可供大家参考：

1 自动填入已有信息

在一些业务场景，会使用到用户之前在其它表单中已经录入的信息，此时在填写新表单时，可以默认带入之前的数据。

2 自动填入关联数据

如果用户正在填写的内容有相关的关联数据，可以默认带入。如我们在填写订单时可以默认带入该订单关联的商品基础信息。

3 系统自动获取数据

基于移动端设备的能力，我们可以在用户开放权限的情况下获取一定的用户信息（位置信息、电话区号、运动数据等），在特定情况下默认填写，如滴滴通过GPS定位自动帮用户填入上车位置。

4 经验预判填入信息

像电话区号、证件类型、国籍等用户录入结果相对固定的字段，可以根据情况提设置合理的默认值。

2.3.2 减少手动输入

相较于PC端而言，移动端设备屏幕尺寸较小，虚拟按键的输入效率远不及实体键盘，在移动端手动输入的成本较高。因此，为了打造便捷优雅的操作体验，移动端表单需要尽量减少用户的手动输入。以下方法可以减少手动输入。

1 联想输入

联想输入是给予用户输入字段的自动补全功能，用户少量输入后进行选择。录入方式由原来的输入变成半输入后选择，减少用户的输入成本，提高用户操作效率。

2 替代输入

对于表单填写过程中可以固化选择的信息，应让用户进行选择操作以代替手动输入，尽可能地让用户减少输入成本。

3 历史记录

一份用户可能会多次填写的表单，我们可以提供用户的历史输入项供其选择，如滴滴的打车页面会将我的常用目的地放置在目的地输入框的旁边供我快速录入。

4 新型组件

一些新型的交互组件的使用能够简化信息录入的操作，例如滑块组件等。

2.2.3 减少页面跳转

在填写表单时如果填写项需要频繁的页面跳转会使得整体的填写效率变低，增加用户的操作成本。在进行表单设计时应尽量规避这种频繁的页面跳转，选用更流畅灵活的交互方式。

1 选项露出

在网页端表单设计中，用户在表单填写中需要对选项进行选择时，常用的交互形式是在选择器的下拉列表中进行选项的二次点击。而在移动端设计中，触发选择器后的二次点击会增加用户的填写成本。所以在设计时，当选项少于8时，在表单中直接显示所有可选项，当选项超出过多时则在列表浮层中进行选择。

2 减少跳转

在表单填写中我们期望用户保持专注，尽量避免产生引导用户离开当前页面的填写交互，这种交互跳转很容易打断用户固有的行为轨迹。因此运用浮层、弹窗等交互来完成辅助信息的采集是我们较为推崇的交互形式。

2.3.4  智能录入

1 OCR识别文件内容

对于一些标准证件类信息的录入，可以通过OCR识别文件内容。当用户上传图片后，运用图像识别技术提取关键信息并自动填入结果。值得注意的是，如果图片不清晰或存在水印，将大大降低识别准确度。此时应提供修正渠道，让用户可以逐一校对并修改文本内容。

2 号码认证

短信验证码升级方案。直连三大运营商，一步校验手机号与当前SIM卡号一致性。优化注册/登录/支付等场景验证流程，有效提升拉新转化率和用户留存率。不做数据加工与号码精准营销，保护用户隐私。

2.3.5  联动键盘

为了避免让用户频繁的跳入跳出相同类型的输入项，首先整合表单的信息字段，将同类型的字段进行合并，同时结合输入控件，设计联动式组件，让用户在表单输入时更加高效。

2.4 设计细节把控

设计不是简单的元素拼凑，深入下去，有很多细节需要推敲，细节应该是含蓄的，包含在整体之内。好的细节设计不容易被用户的眼睛直接发现，但是会让用户与产品的交互过程变得通顺、舒适，概括来说就是润物细无声。对应到表单设计上，我们需要通过表单设计中的细节把控，让表单录入这件事变得简单、高效。

1 必填与选填

当表单中同时出现必填项和选填项时我们需要对其做出区分，避免用户不知道哪些字段必须填写、哪些字段可以选择性填写。沿用通用符号习惯，在表单中我们往往使用 * 号来标记必填项。但是当表单中的必填项多于选填项时，大量的 * 号会增加用户的认知负担，面对这种情况，我们可以使用暗提示来标记选填项帮助用户识别。

2 号码组合规律

如电话号码、银行卡号这类有数字组合规律的号码字段，我们可以沿用它们在线下的数字组合规律，通过空格对号码字段进行划分，帮助用户校验和阅读。

3 密码保护

出于保护用户账号安全考量，我们在进行密码输入时通常使用隐暗文字的方式来保护用户账户安全，但是暗文字的显示方式会让用户无法确认密码信息。因此我们可以在输入时，让输入字段短暂显示，保持1秒然后再转变为暗文字，这样既可以让用户明确内容，也保证了用户的账户安全。

4 符合心理预期

我们在进行表单设计时，输入区域的长度要符合心理预期，需要预判填写内容长度来确定输入区域的长度。这样不仅在体验上一致，而且在视觉体验上更加愉悦。

5 对指令有明确的称谓

用户应该对他们的操作所带来的结果非常自信，使用“提交”、“注册”、“立即支付”、“创造账户”等确定性文案来描述用户将采取的操作。

6 错误信息就近反馈

报错信息应当一目了然，从用色、图标到文本都应当起到高亮的效果，而且报错信息应当靠近输入框，而非表单的底部或者顶部或者按键旁边。

7 防止输入框的遮挡

在设计主要由文本输入框构成的表单页面时，要考虑键盘出现可能会遮挡输入框的情况，我们需要把控件放在scrollView上，当键盘会遮挡输入框时,则表单滚动。

8 指导性错误反馈

对于异常情况不能只是冷冰冰的告知失败，这样容易给用户带来挫败感，且缺少下一步操作指引。错误反馈不应该只着眼于结果，错误反馈的阐述角度应该是引起用户关注、让其快速了解出错情况，并指导如何处理。

2.5 整体体验提升

经过前面几个步骤，表单整体形态已经确定，最后一步我们需要从整体体验的角度对表单进行完善和调整。包含表单的容错性考量、表单流程闭环的打造、视情况而定的趣味性设计。

2.5.1 表单容错性考量

即便你的产品90％的时间都运行良好，但是如果在用户需要帮助时置之不理，他们是不会忘记这一点的。——《Getting Real》

容错性概念源于计算机领域，容错性是指计算机系统在发生故障的情况下，依然能够保证系统正常运行。计算机这种保证系统正常运行的能力也被称为容错能力。延伸到互联网产品设计领域，容错性的范畴更为宽泛，包括降低用户操作的出错率、及时提供纠错帮助、提供解决方案等内容。

容错设计与用户体验息息相关，我们在表单页面设计时也需要进行容错性考量，尽量避免用户错误操作的出现。当用户出现错误操作时，帮助用户识别、诊断，及时反馈问题所在，并提出有效的解决方案，帮助用户快速从错误中恢复。让表单填写流程更顺畅，给用户带来更优的用户体验，关于表单容错性设计可以从以下几个方面来进行。

1 引导与提示

引导和提示要突出表现，从而引起用户关注，确保用户在操作前能注意到引导或提示信息。引导与提示用语要简单且易于理解，当重要或操作不可逆时，要询问用户让其知道这样操作的后果。

2 限制操作

如何从设计上避免用户出错，限制是一种非常必要的方式，可以通过限制用户的某些交互操作或者增加某些操作的难度来对用户操作进行限制避免用户出错。

3 反馈与帮助

当用户出现填写错误时，及时的反馈错误并提供纠错帮助，出错信息应当用清晰准确且用户易于理解，能够对用户解决当前问题提供建设性帮助。

4 错误恢复

允许用户犯错，操作者能归够撤销以前的指令，帮助用户在犯错以后能够快速回到正确状态。

2.5.2 表单填写流程闭环

表单的终点并不是提交，一个好的表单设计需要兼顾考虑用户填写前的引导、填写时的及时校验与帮助、还有填写后的整体流程体验，为用户提供完整的、形成闭环的表单填写体验。

举个例子，当我们设计的表单需要用户准备如身份证、银行卡这类的证件时，需在表单填写前告知用户，避免用户填写途中才发现证件未准备，导致用户填写流程中断。再如，用户在填写完证券开户表单后，其实还需要通过审批后用户才能进行入金交易等操作，这时我们需要一个结果页来告知用户表单提交的结果状态和下一步的操作指引。

2.5.3 最后，再增加一点愉悦度吧

表单设计并不一定需要是严肃且正式的，在表单设计时可以尝试引入一些趣味性的元素，研究表明，更大的文字输入框、适度的留白空间、优雅的动画效果、趣味性界面设计会让人心情愉悦更有填写的欲望。

例如bilibili的登录页面，在用户输入账号时上方的卡通形象是睁眼的，当切换到输入密码或者验证码时卡通人物会有一个捂住双眼的动作十分有趣，这样的趣味性设计能够在一定程度上缓解用户在填写表单时的焦虑情绪，并增加对于bilibili保护账号安全的信赖感。

总结

以上就是我对于移动端表单设计的一些归纳和总结，过往的项目中自己设计大量的表单页面，走了不少弯路犯了不少错误，但也通过项目不断的反思总结，收获不少的关于表单设计的经验。在这里将项目中关于表单的一些思考和经验分享出来，总结出自己的一套关于表单设计的方法论，也是希望能够对正在进行表单设计或者即将进行表单设计的你提供一点点参考与帮助。

文章来源：站酷  作者：Yone杨

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

this指向的问题也是JavaScript中的难点之一了，也是面试常问的问题，很多时候对this指向的问题就很懵逼，明明应该是指向他，为什么又指向他了…所以我就学习了一下这方面的知识，整理了一下，希望能够帮助大家

为什么要用this?

首先看一段代码

function identify(){
    return this.name.toUpperCase()
}
function speak(){
    var greeting = '你好,我是'+identify.call(this)
    console.log(greeting)
}

var me ={
    name:'kyle'
}

var you ={
    name:"reader"
}
identify.call(me) 
identify.call(you) 

speak.call(me) //?  你好,我是KYLE
speak.call(you) //? 你好,我是READER 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

上面的这段代码中可以从不同的上下文对象 me 和 you 中重复的使用identify函数和speak函数
如果你不使用this的话 你就要显式的将上下文对象作为参数传递进去，比如这样:

function identify(context){
    return context.name.toUpperCase()
}
function speak(context){
    var greeting = '你好,我是'+identify(context)
    console.log(greeting)
}

var me ={
    name:'kyle'
}

var you ={
    name:"reader"
}
identify(me)
identify(you) 

speak(me) 
speak(you) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

就像这样,这样看起来就不想上面那样简洁了,你要把一个对象传来传去的

认识this

刚见到this的时候 觉得this指向是这个函数自身，或者是函数的作用域，后来发现其实不是这样的的，不过也不能说错了,因为有些情况确实是这样的,比如这样:

function foo(num){
    console.log('foo'+ num)
    this.count ++ 
}
foo.count = 0

var i;
for(i = 0;i<10;i++){
    if(i>5){
        foo.call(foo,i)
    }
}
console.log(foo.count) //4 这样的话 this指向了foo本身  foo上面的count属性++ 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

无法指向函数作用域

var a = 3
function foo() {
    var a = 2;
    bar.call(foo);
}
function bar() {
    console.log( this.a );
}
foo(); // undefined 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

我们要记住非常重要的一点:this是在运行的时候进行绑定的，而不是在定义的时候绑定，this的绑定跟函数声明的位置没有关系，主要是取决于函数的调用方式,想要找到this指向谁，我们就要看懂函数是怎么调用的。

绑定规则

1.默认绑定

当一个独立函数正常调用的时候，不带任何修饰的调用

// 非严格模式下
var a = 3
function foo(){
    console.log(this.a) //a
}
foo() 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

这种情况下 this.a被解析成了了 全局变量a，this指向是全局对象

// 严格模式下
var a = 3
function foo(){
    "use strict" 
    console.log(this.a) //TypeError
}
foo() 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

严格模式下 this不会指向全局对象 this绑定的是undefined

2.隐式绑定

调用位置上是否有上下文对象

function foo(){
    console.log(this.a)
}
var obj = {
    a:2,
    foo:foo
}
obj.foo() //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

调用位置会使用obj上下文对象来引用函数，foo被调用的时候 他的落脚点指向是obj对象，隐式绑定的规则就会把this指向这个上下文对象。所以this.a就跟 obj.a是一样的

function foo(){
    console.log(this.a)
}
var obj = {
    a:2,
    foo:foo
}
var obj2 = {
    a:3,
    obj:obj
}
obj2.obj.foo() //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

当多层调用的时候 只有最后一层才会影响函数的调用位置 比如上面这个 this绑定的还是 obj 而不是obj2

注意

隐式绑定会出现隐式丢失的问题，会失去绑定对象,最后应用默认绑定

var a = 3;
function foo(){
    console.log(this.a);
}
var obj = {
    a:2,
    foo:foo
}
var bar = obj.foo
bar() //3 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

bar 是 obj.foo的一个引用 他引用的是foo函数本身，此时bar就是一个不带任何修饰的函数调用 应用默认绑定

var a = 3;
function foo(){
    console.log(this.a);
}
var obj = {
    a:2,
    foo:foo
}
setTimeout( obj.foo, 100 ) //3
setTimeout(function(fn){
    fn()
},100,obj.foo) //3 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

参数传递也是一种隐式赋值，回调函数丢失this是非常常见的…

3.显式绑定

隐式绑定的时候我们必须在一个对象内部包含一个指向函数的属性，然后通过属性间接引用函数，把这个this间接隐式的绑定到这个对象上
如果我们不想在对象内部包含函数的引用 ，而想在某个对象上强制调用函数
我们可以把这个函数绑定到对象的原型上，也算是不用再对象内部包含函数了吧…
更好的办法是我们可以使用函数的 call() apply() bind() 这种方法

function foo(){
    console.log(this.a)
}

var obj = {
    a:2
}
foo.call(obj) //2
foo.apply(obj) //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

如果你第一个参数传入的是一个原始类型 比如字符串 布尔 数字作为绑定对象 这些原始类型会被转换为 对象的形式 new String() new Number()…

硬绑定

Function.prototype.bind()
function foo(){
    console.log(this.a)
}

var obj = {
    a:2
}
var obj2 = {
    a:3
}
var bar = foo.bind(obj)  //会返回一个硬编码的新函数 他会把参数设置为this的上下文
bar.call(obj2) //2  返回的新函数 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

有些api 方法 会提供一个可选参数 context 其作用跟bind一样 确保你的回调函数使用指定的this 比如 array.forEach(fn,context)…

4.new绑定

使用new 来调用函数的时候会执行以下操作
1.创建一个全新的对象
2.这个新对象会被执行原型的链接
3.新对象会绑定到函数调用的this
4.如果没有返回其他的对象，那么函数会自动返回这个对象

function Foo(a){
    this.a = a
}
var bar = new Foo(2)
console.log(bar.a) //2 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

使用new 来调用Foo函数 会构造一个新对象并把它绑定到Foo调用中的this上 然后返回了

优先级

函数不带任何修饰的时候单独调用才会触发默认绑定 所以说默认绑定是优先级最低的了

那剩下三个规则哪个的优先级最高？

显示绑定跟隐式绑定比较

function foo(){
    console.log(this.a)
}
var obj1 = {
    a:1,
    foo:foo
}

var obj2 = {
    a:2,
    foo:foo
}
obj1.foo() //1
obj2.foo() //2

obj1.foo.call(obj2) //2
obj2.foo.call(obj1) //1 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

可以看到 显示绑定的优先级还是更高一点

new 绑定跟隐式绑定比较

function foo(arg){
    this.a = arg
}

var obj1 ={
    foo:foo
}
var obj2 ={}

obj1.foo(2)
console.log(obj1.a) //2

var bar = new obj1.foo(4)
console.log(obj1.a) //2
console.log(bar.a) //4 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

可以看到 new绑定的优先级比隐式绑定要高

new 绑定跟显示绑定比较

new跟call apply无法一起使用 无法通过new foo.call(obj)，试一下硬绑定

在这里插入代码片 


    

        1
    

function foo(arg){
    this.a = arg
}
var obj1 ={}
var bar = foo.bind(obj1)
bar(3)
console.log(obj1.a) //3

var baz = new bar(4)
console.log(baz.a) //4
console.log(obj1.a) //3 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

new 调用bar修改了硬绑定时候的 函数的this new的优先级高一点

所以我们可以根据下面的优先级规则进行判断了

1.函数是否在new中调用 是的话this绑定新创建的对象 var bar = new Foo()
2.函数是否通过call apply 显示绑定或者是 bind硬绑定 如果是的话this指向指定的对象 foo.call(obj)
3.函数是否在某个上下文中调用 隐式绑定，如果是 this绑定那个上下文对象 注意绑定丢失的问题
4.如果都不是 就是默认绑定非严格模式下绑定的是全局对象 严格模式下绑定的是undefined

绑定例外

1.将null和undefined作为call apply参数 作为this绑定对象的时候 这些值会被忽略 应用的是默认绑定

var a =3
function foo(){
    console.log(this.a) //3
}
foo.call(null) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

2.箭头函数

function foo(){
    return ()=>{
        console.log(this.a)
    }
}
var obj1 = {
    a:3
}
var obj2 = {
    a:4
}
var bar = foo.call(obj1)
bar.call(obj2) //3  this绑定的是obj1 而不是obj2!!! 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

在看一个

function foo(){
    setTimeout(()=>{
        console.log(this.a) //2
    },100)
}
var obj = {
    a:2
}
foo.call(obj) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

箭头函数不使用this绑定的四种规则，而是根据外层作用域来决定this的，外层作用域的this绑定的是什么 他的this就是什么

转自：csdn 论坛 作者：Selfimpr欧

蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务

7种Vue.js模式

1.处理加载状态

在大型应用程序中，我们可能需要将应用程序划分为更小的块，只有在需要时才从服务器加载组件。为了使这一点更容易，Vue允许你将你的组件定义为一个工厂函数，它异步解析你的组件定义。Vue只有在需要渲染组件时才会触发工厂函数，并将缓存结果，以便将来重新渲染。2.3版本的新功能是，异步组件工厂也可以返回一个如下格式的对象。

const AsyncComponent = () => ({
  // 要加载的组件（应为Promise）
  component: import('./MyComponent.vue'),
  // 异步组件正在加载时要使用的组件
  loading: LoadingComponent,
  // 加载失败时使用的组件
  error: ErrorComponent,
  // 显示加载组件之前的延迟。默认值：200ms。
  delay: 200,
  // 如果提供并超过了超时，则会显示error组件。默认值:无穷。
  timeout: 3000
}) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

通过这种方法，你有额外的加载和错误状态、组件获取的延迟和超时等选项。

2.廉价的“v-once”静态组件

在Vue中渲染纯HTML元素的速度非常快，但有时你可能有一个包含大量静态内容的组件。在这种情况下，你可以通过在根元素中添加 v-once 指令来确保它只被评估一次，然后进行缓存，就像这样。

Vue.component('terms-of-service', {
  template: `
    <div v-once>
      <h1>Terms of Service</h1>
      ... a lot of static content ...
    </div>
  `
}) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

3.递归组件

组件可以在自己的模板中递归调用自己，但是，它们只能通过 name 选项来调用。

如果你不小心，递归组件也可能导致无限循环：

name: 'stack-overflow',
template: '<div><stack-overflow></stack-overflow></div>' 


    

        1
    

    

        2
    

像上面这样的组件会导致“超过最大堆栈大小”的错误，所以要确保递归调用是有条件的即(使用 v-if 最终将为 false）

4.内联模板

当特殊属性 inline-template 存在于一个子组件上时，该组件将使用它的内部内容作为它的模板，而不是将其视为分布式内容，这允许更灵活的模板编写。

<my-component inline-template>
  <div>
    <p>These are compiled as the component's own template.</p>
    <p>Not parent's transclusion content.</p>
  </div>
</my-component> 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

5.动态指令参数

指令参数可以是动态的。例如，在 v-mydirective:[argument]=“value" 中， argument 可以根据组件实例中的数据属性更新！这使得我们的自定义指令可以灵活地在整个应用程序中使用。

这是一条指令，其中可以根据组件实例更新动态参数：

<div id="dynamicexample">
  <h3>Scroll down inside this section ↓</h3>
  <p v-pin:[direction]="200">I am pinned onto the page at 200px to the left.</p>
</div>
Vue.directive('pin', {
  bind: function (el, binding, vnode) {
    el.style.position = 'fixed'
    var s = (binding.arg == 'left' ? 'left' : 'top')
    el.style[s] = binding.value + 'px'
  }
})

new Vue({
  el: '#dynamicexample',
  data: function () {
    return {
      direction: 'left'
    }
  }
}) 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

    

        17
    

    

        18
    

    

        19
    

    

        20
    

6.事件和键修饰符

对于 .passive、.capture 和 .once 事件修饰符，Vue提供了可与 on 一起使用的前缀：

例如：

on: {
  '!click': this.doThisInCapturingMode,
  '~keyup': this.doThisOnce,
  '~!mouseover': this.doThisOnceInCapturingMode
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

对于所有其他的事件和键修饰符，不需要专有的前缀，因为你可以在处理程序中使用事件方法。

7.依赖注入(Provide/Inject)

有几种方法可以让两个组件在 Vue 中进行通信，它们各有优缺点。在2.2版本中引入的一种新方法是使用Provide/Inject的依赖注入。

这对选项一起使用，允许一个祖先组件作为其所有子孙的依赖注入器，无论组件层次结构有多深，只要它们在同一个父链上。如果你熟悉React，这与React的上下文功（context）能非常相似。

// parent component providing 'foo'
var Provider = {
  provide: {
    foo: 'bar'
  },
  // ...
}

// child component injecting 'foo'
var Child = {
  inject: ['foo'],
  created () {
    console.log(this.foo) // => "bar"
  }
  // ...
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

    

        10
    

    

        11
    

    

        12
    

    

        13
    

    

        14
    

    

        15
    

    

        16
    

36个Vue开发技巧

1.require.context()

1.场景:如页面需要导入多个组件,原始写法:

importtitleComfrom'@/components/home/titleCom'
importbannerComfrom'@/components/home/bannerCom'
importcellComfrom'@/components/home/cellCom'
components:{titleCom,bannerCom,cellCom} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

2.这样就写了大量重复的代码,利用require.context可以写成

constpath=require('path')
constfiles=require.context('@/components/home',false,/\.vue$/)
constmodules={}
files.keys().forEach(key=>{
constname=path.basename(key,'.vue')
modules[name]=files(key).default||files(key)
})
components:modules 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

这样不管页面引入多少组件,都可以使用这个方法

3.API方法

实际上是webpack的方法,vue工程一般基于webpack,所以可以使用require.context(directory,useSubdirectories,regExp)
接收三个参数:directory：说明需要检索的目录useSubdirectories：是否检索子目录regExp:匹配文件的正则表达式,一般是文件名

2.watch

2.1常用用法

1.场景:表格初始进来需要调查询接口getList(),然后input改变会重新查询

created(){
    this.getList()
},
watch:{
     inpVal(){
        this.getList()
      }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

2.2立即执行

2.可以直接利用watch的immediate和handler属性简写

watch:{
     inpVal:{
        handler:'getList',
             immediate:true
        }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

2.3深度监听

3.watch的deep属性,深度监听,也就是监听复杂数据类型

watch:{
     inpValObj:{
        handler(newVal,oldVal{
            console.log(newVal)
            console.log(oldVal)
     },
     deep:true
   }
} 


    

        1
    

    

        2
    

    

        3
    

    

        4
    

    

        5
    

    

        6
    

    

        7
    

    

        8
    

    

        9
    

此时发现oldVal和newVal值一样;因为它们索引同一个对象/数组,Vue不会保留修改之前值的副本;所以深度监听虽然可以监听到对象的变化,但是无法监听到具体对象里面那个属性的变化

7种vue模式还能和大家说完，但36个vue开发技巧太多啦，文章篇幅也不够，小编写了两个例子，没写出来的开发技巧小伙伴们请点击这里领取Vue开发必须知道的36个技巧PDF文档。

转自：csdn 论坛 作者：李不要熬夜