栅格 按钮 组件 新的一年，先祝大家运势涨如脱兔，因为年前和过年这段时间工作没那么忙，就抽空继续整理了一些工作中对B端设计的总结，希望可以带给需要的人一些启发。如有纰漏，欢迎各路大神指正。上一篇说到了设计原则，接下来我们讲讲 B 端常用组件的内容。超全面的B端设计规范指南（一）：设计原则前言B 端设计离不开设计规范这个话题，而做好设计规范是一个庞大复杂工程，很多人对这些处于一知半解状态，在这个系列文章里我通过结合自己平时的项目案例来谈谈自己对 B 端设计规范的一些理解，希望可以带来一些启发。阅读文章 > 谈到 B 端组件，很多人的印象是多且杂，想要全面准确的熟悉这些它们，需要我们对它有个合理的归纳总结。可能每个人会从不同的视角去做这件事情，我一般是按照使用场景去对组件分类整理。下面我们根据这个分类框架来逐个聊聊这些组件。一、基础组件说到基础组件，我想再将其细分成两个大类：一类是通用组件；一类是栅格/导航。怎么去更深刻的理解这两类的区别呢，我们可以打个这样的形象比方：通过这个比方我们不难理解，栅格/导航是先给页面定下了基本框架，而通用组件则是在这个框架基础上搭建页面的所用到基本元素。1. 通用组件常见通用组件一般包含：色彩/字体/间距/圆角/分割线/按钮。需要注意的是，通用组件看起来似乎很简单，但却是决定产品品牌调性、界面细节品质的重要因素，在设计过程中需要引起我们的高度重视。色彩色彩可分为主色，功能色，中性色三类。下面谈谈这三类颜色如何配置，以及如何定义这些颜色梯度。① 主色主色的选取主色作为产品的主要色调，在选取时应当优先选择品牌色，但有一点要注意的是 B 端和 C 端不一样，B 端一般不适合采用暖色系作为主色，如果品牌色为暖色调，则尽量考虑另选取一个冷色系作为主色，原因有两点：一是为了避免和警告、错误色冲突，产生歧义；二是冷色系带有商务、专业、冷静的情感，更符合 B 端产品调性。同时主色选取应避免高亮、荧光色、灰调高的颜色。主色的应用主色在设计中常见的应用包括可交互、选中状态、可视化、插图、图标等场景。② 功能色功能色主要用于页面表征状态，常见有成功色、警告色、报错色等。成功色主要用于操作结果成功提示以及标签配色等。警告色主要用于警告提醒功能以及标签配色等。报错色主要用于系统报错提示、圆点提示、以及标签配色等。③ 中性色中性色在页面设计中应用非常广泛，从线条到文字再到图形等等都可以见到它的影子。Tips：无论我们主色调是什么，中性色在调色时建议可加入适量的蓝色调，可让页面观感更清爽。④ 颜色梯度选取好了颜色后，怎么去更合理的定义每个颜色的梯度呢？（这里主要指对主色以及功能色定义梯度）我的方法是给颜色加一层半透明黑/白遮罩，当我们需要浅色，通过调整白色遮罩透明度得到合适颜色；而当我们需要深色时，则通过调整黑色遮罩透明度得到合适颜色。这样定义颜色梯优点是后续如果需要更改配色，只需一键替换全局色即可，大大提高工作效率。文字文字规范包含字体、字号、字重、行高等。① 字体/字重B 端字体/字重一般按照如下规范即可：② 字号不同于 C 端，B 端在字号选择上应当尽量保持克制。研究表明，Web 端上正文字号为 14 时，可以带来最佳阅读体验。因此在字号选取上应尽量优先选取 14 号字。如果想要区分文字层级，优先级从高到低的手法应该是颜色、字重、字号，也就是说一般尽量不采用字号大小区分文字层级。③ 行高行高可以参照下面的公式或行高参照表快速获得，如果通过公式算出行高非整数或非偶数，可就近取偶整数。间距关于间距取值，在目前主流屏幕分辨率下，只有 4 或 8 被整除率最高，考虑到 4 的颗粒度偏小，因此可优先考虑 8px 的倍数作为间距值，在一些特殊场景可采用 4px 的倍数间距值。分割线分割线宽度一般统一为 1px 即可，同时注意颜色不可过深，以免干扰主体信息。如果需要不同层级分割线，可用颜色深浅来区分。圆角圆角大小一般根据使用场景控制在 2-3 个梯度即可，既不能全部统一一个圆角值，同时也不适合出现过多圆角值。同时圆角值不要过大，建议控制在 2-6px，以符合 B 端产品严谨专业调性。按钮这里从按钮的大小/状态/排放位置几个纬度来讲。① 按钮尺寸按钮高度一般情况下可以设置 3-4 种尺寸按钮，足以满足各种使用场景。至于按钮宽度，我们一般定义一个最小值，当超过最小值时，可设置 padding 值，按钮宽度根据内容自适应。② 按钮状态操作按钮过程中，按钮会呈现不同的交互状态。③ 按钮位置对于主次按钮组合，主次按钮排放位置应该怎么规定呢？可分为两种场景：一是当为从左到右阅读顺序时，主要按钮应当排在次要按钮左侧。二是当为从右到左阅读顺序时，主要按钮应当排在次要按钮右侧。而当一些特殊场景与这个原则冲突时，应权衡优先级做出取舍。2. 栅格/导航熟悉通用组件后，我们要通栅格/导航来确定产品页面框架。栅格栅格可以有效地保证设计的一致性、让页面布局更具规律，并提高团队协作效率。应该如何设计栅格呢？① 栅格区域的划定我们一般习惯将页面从下到上划分为背景层、全局控制层、内容层、临时层，而栅格区应当用在内容层。以下为常见几种页面布局栅格区的划定。② 栅格自适应规则随着页面宽度变化，一般来说是通过栏宽变化实现自适应。③ 栅格栏数的确定根据页面内容丰富程度，栅格栏数一般定 12 或者 24 栏，考虑到 B 端产品功能往往比较复杂，建议采用 24 栏即可。④ 上下布局栅格⑤ 左右布局栅格导航导航可分为全局导航与局部导航。① 全局导航全局导航包含顶部导航、侧边导航、混合导航。这三种导航样式各具特点，应结合产品特性选择合适的导航样式。这里要注意的一点是，当产品可用性和用户体验产生冲突时，应优先保证产品可用性。② 局部导航局部导航包含面包屑、标签页、步骤条、分页器。面包屑面包屑导航的作用是告诉用户当前页面在系统层级结构中的位置以及父子级页面间的关系，并且可以快速回到上几级导航。标签页标签页可以帮助用户在一个页面实现快速切换不同内容，提升单个页面内容扩展性。可分为基本样式、标签样式、卡片样式。步骤条当任务复杂或者存在先后关系时，可将其分解成一系列步骤，这里就会用上步骤条。步骤条是引导用户按照流程完成任务的导航条，作用包含 3 点：一是让用户对操作流程长度和步骤有个预期，二是明确知道自己目前所在步骤，三是可以对用户的任务完成度有明确的度量。步骤条一般分为横向与纵向两种样式。步骤条小 Tips：当步骤条中有操作难度偏大的内容时，为了提高用户操作完成率，我们可以考虑把其放在靠后的步骤中，原因是用户前面已经完成了大部分简单操作，后面碰到高难度操作后，出于损失厌恶心理，不会轻易放弃操作。分页器当有大量内容需要展现时进行分页加载处理，分页器作用是可以让用户清楚的知道自己所要浏览的内容有多少页、当前所在页码、快捷前往目标页码。分页器一般分为迷你、简易、自定义三种样式。妙用分页器小 Tips：当表格中需要对数据全选操作时，为了提高操作效率，可将自定义每页跳数调到最大。例如一共 100 条数据，默认每页 10 条数据，要完成全选需要点击 9 次翻页，10 次全选（表格的全选框勾选后一般只选中当前页面全部数据，而不是所有页面总数据），当把每页条数调整为 50 后，则只需翻页 1 次，点击 2 次全选即可。到这里关于 B 端的基础组件就全部梳理完了，后续我们就来揭开展示组件的神秘面纱。部分参考资料：《B 端产品设计-Mia》《Ant Design》本篇来源：优设网原文地址：https://www.uisdc.com/design-principles-3
定义 组件 原则 更多设计规范的相关教程：案例实操！从零开始教你构建产品颜色规范前言这一次的北农商银行的项目，是在企业版手机银行 App 上加入企业 OA 的功能。阅读文章 > 一、如何「理解」交互规范说起设计规范，大家应该都不陌生，一个成熟的设计规范对 产品设计、研发开发、用户使用 都有着重要的指导作用：产品设计：保障产品内不同模块的设计一致性，同时提高不同设计师间的设计、协作效率研发开发：通过定义的标准规范，提高流程、组件的复用率，提高整体开发效率用户使用：让用户能够在产品全局感受到统一且完整的体验，降低使用成本和学习难度而一个完整的设计规范一般分成「视觉」「交互」两个部分合并组成，在全局原则的指导下，侧重不同的维度和内容分别展开规范的定义，最后再合到一起形成一份完整的设计规范。从用户体验要素来看，视觉主要是在「表现层」「框架层」进行规范的统一，主要包括：形、色、字、构、质、动 六个层面。而交互角度相对抽象，主要针对于产品的「结构层」「框架层」入手，定义统一的交互规范，指导页面、流程搭建和组件使用规则。包括：全局原则、页面布局、通用流程、标准组件、文案规范。整体维度呈“从抽象到具体的总分关系”，不仅对产品的各个维度都有具体的交互指导，而且不仅能保证长期使用，避免重复返工；同时也便于囊括后续的迭代内容。而这些内容，就是我们通常定义的交互规范，也是交互参与定义设计规范的发力点。有了对于基本认识和搭建框架之后，我们来详细聊聊如何定义交互规范具体内容。二、不同阶段应该定义哪些交互规范？产品有不同发展阶段，设计规范同样也有，不同阶段下的产品目标和规范需要覆盖的内容都不尽相同。我们要既要避免做多，保证投入产出比最大化；同时也要构建一个合理的规范迭代思路。产品探索初期：该阶段的产品核心目标是「验证产品或商业模型」，业务需求都是小步快跑、频繁迭代。产品处于从 0 到 1 的野蛮生长状态，存在着“先满足功能，再优化体验”的情况，导致该阶段的产品体验往往不太过关。搭建目的：通过定义原则，梳理关键页面和流程，搭建基本的规范框架。既让团队对产品有统一的设计价值观和认知判断；从页面到流程，又能对应设计参照标准；同时业务可以在规定的框架下发展，不仅让产品体验的根基牢固，而且不会限制功能设计自由。搭建范围：「全局原则」「页面布局」「通用流程」产品稳定发展期：该阶段的产品基本形态已稳定，也形成了初步的模型结构。后续迭代是在现有结构的基础上，进行增加或优化功能。虽然探索期定义了产品原则、布局和流程，但探索期产品的自由生长，会导致不少设计细节不一致，从而影响了产品整体的体验和效率。搭建目的：通过回溯整理过往设计，沉淀优化成完整的交互规范。再根据规范统一产品体验，进一步优化流程和效率， 让整个产品体验达到相对稳定的状态。搭建范围：「全局原则」「页面布局」「通用流程」「标准组件」「文案规范」三、如何「定义」交互规范1. 定义交互规范的原则与行业通用的设计规范（如 TDesign、AntDesign）“大而全”“通用”的特质不同，一般团队内构建的设计规范都是源于某一个产品或业务，主要的特点是“专精”。专注于「业务」本身，主要是「团队内成员使用」，追求的是投入产出比最大化。基于此背景，当我们在定义「交互规范」时，有三点原则：原则一：保持规范的业务性。设计规范既要贴合业务场景归纳完整，同时又要避免凭空定义脱离实际。故我们定义时要代入业务规划，尽量富有前瞻性，这样定义的规范不仅能覆盖当前需要，同时后续也能更好地迭代。原则二：保持规范的专注性。有的放矢，明确内容优先级，避免盲目追求大而全和形式主义。对于优先级高（覆盖面广、复用率高）的关键内容重点描述；优先级低（逻辑简单、认知一致）的内容可简要描述，避免事无巨细降低效率。原则三：保持规范的生长性。设计规范不是一成不变，而是跟随业务发展不断迭代完善的，所以需要阶段性的回顾规范。遇到规范未能覆盖或无法指导设计的地方，及时修订同步团队，避免墨守成规，固步自封。最后，还有一点建议：在定义规范时，可以站在前人肩膀，适度参考行业设计规范，能复用用的直接参考，具有业务特性的再集合业务综合考虑，使整个规范制定效率更高，科学性、指导性更强。在找到自己当前所属的产品阶段、明确要建立哪些设计规范后，具体应该如何进行落地执行呢？建议从以下 4 个步骤入手。2. 第一步：定义规范分类如上文中提到，一个完整的交互规范分为：「全局原则」「页面布局」「通用流程」「标准组件」「文案规范」五个维度，但每个维度具体含有哪些内容，都是不一样的。仍然需要根据实际业务需要去定义，这样才能尽量保证没有遗漏，也更好为下一环节评估工作量。通用的做法有两种：方式一：整理业务场景下不同的页面、流程等，并进行抽象合并。「全局原则」「页面框架」和「通用流程」具有强业务导向，可以采用此方式。以「页面布局」为例，就需要将关键页面按统一颗粒度收集（按层级或按场景等）。方式二：参考行业通用规范的定义，先罗列完整，再根据产品实际业务需要进行增删改。「标准组件」「文案规范」已经在行业内有了不少科学的目录和沉淀，可以采用此方式，例如下图组件的梳理。最后可产出如下图的规范分类和具体内容。（可以列的不是很全，后续补充具体部分内容时持续维护这张表。）3. 第二步：确定分工排期有了具体内容作为依据，便可以根据此进行排期分工。分工原则：推荐按规范分类进行分工，一个大的分类由一人负责，保证专注性。同时团队交互最好都能参与，保证后续对规范更好的沿用。排期原则：「定义规范」和「输出需求」两者经常要并行处理，此时提高效率，控制投入产出比就很重要了，我们需要明确优先级，先做什么后做什么。有 3 个思路可以综合参考：并行的思路：在定义完「全局原则」后，剩下的页面、流程、组件、文案都可考虑并行定义，彼此之间没有明确的依赖项。迭代的思路：近期有迭代的版本，如：即将改版的模块、反馈较多体验较差的模块，其中涉及到的页面框架、组件可优先定义。复用的思路：某些典型页面、典型流程、典型组件涉及面广，许多需求的设计都将借鉴参考，亦可优先抽象定义。4. 第三步：统一撰写原则设计规范是由不同的设计师一起合作完成，所以我们尽量在一开始，就需要统一规范的撰写和展现形式。以此提高后续合并的效率，同时又能保证其阅读体验，让其它使用者能够更好遵循。对此，我们定义了几个关键原则：目录完整：高效检索，快速让使用者找到需要的内容。原则清晰：抽象的内容往往含有许多概念和原则，需要让使用者先理解再参考，才能保证后续使用正确、举一反三多图少字：没有人喜欢看字，图片更容易吸收搭配案例：让使用者更好的代入场景，理解和使用规范。5. 第四步：定义具体规范 前面铺垫了许多流程性的内容，就像我们日常输出设计需求一样，大家或多或少在工作中都有遇到过。接下来，将重点聊聊，我们具体的内容应该如何定义。依然分成 5 个环节一一讲解。① 全局原则目标：明确影响整站各个模块、各个页面设计的原则和规范，指导我们后续各种规范的定义和设计。而全局原则也分两种，设计原则和业务原则两种。设计原则：每个完整的设计规范都需要包含的内容，如：设计价值观、设计准则。看似相对务虚的东西，实则影响后续整个设计方向。这个部分需要和产品经理、视觉同学结合产品的定位和发展共同提炼。具体定义方式可参考：你为什么需要设计原则？https://zhuanlan.zhihu.com/p/246430795业务原则：源自实际业务本身产生的问题，行业内没有标准定义。需要具体问题具体分析，推导出具体目标，最后再统一制定规范解决业务问题。举一个实际的例子便于理解：全局 Z 轴定义明确问题：整站层级高度没有统一定义，导致不同控件间相互遮挡，没有统一规则。需要定义全局 Z 轴规范，统一不同场景、页面、组件的高度。梳理借鉴：统一梳理相关场景、页面、组件，明确需要定义的范围。再查找行业规范，有无参考借鉴。（如 Z 轴定义，可参考 Material Design）定义规范：最后通过最具代表性的场景进行展示全局原则没有维度高低之分，例如可能全局涉及到的「右键菜单」也能被定义成全局原则。不必盲从行业交互规范内庞大且抽象的原则。只要能够实际解决你业务的需要，能够覆盖整站各个部分，都可以纳为全局原则。② 页面框架目标：梳理整站所有关键页面，整理抽象成相对固定的 框架布局&功能分区 让后续设计新页面时能遵循规律、找到参考。页面框架的搭建一般由四个步骤组成：第一步，收集页面：根据早期定义的规范分类，收集展示所有相同层级的页面。这些在定义规范分类时，应该已收集完成。第二步，框架布局：提取共性，搭建框架和布局，明确页面大的区域划分和结构。（TDesign 布局详细指南）第三步，功能分区：基于框架布局，细化区域内具体的业务功能属性，如：导航区、操作区等。这部分是页面框架内最接地气最具指导性的内容，同时也是最难定义的。主要原因如下：定义太细，担心缺乏前瞻性限制后续设计：定义越细灵活度就低，后续改动和限制性就越高。为避免这种问题，推荐在定义关键页面时，按输出设计稿的思路：整理「信息架构」定义「功能分区」，这样后续拓展性和前瞻性更高定义太粗，无法定义出明确的功能分区，担心缺乏实际指导意义：同一区域有些页面展示操作，有些展示导航。从规范角度好像不应该，但实际套在各个业务内却又合理。当遇到这种无法达成一致的情况时，建议就不定义具体的“功能分区”，避免因为盲目追求统一而限制实际设计。而可以采用“穷举举例”的方式，将该布局下可承载的内容均展示出来，既可以起到参考意义，又能供后续沿用达到统一的效果。第四步，加入案例：将刚刚定义的布局框架与功能分区，与实际案例完整结合，便于后续理解和沿用。③ 通用流程目标：梳理整站所有流程，对那些可复用的流程进行整理、抽象、封装。让后续设计师和研发能够直接沿用。“可复用的流程”是指：在多个场景下，不改变其原有业务逻辑的情况下能够“既插既用”。例如：登录注册流程、扫码关注流程、分享流程等等。往往一个通用流程中，不同的步骤亦可以打散，重新拼装成不同的流程，以适配具体的场景使用。下面就举一个具体的例子：注册流程。一般完整的注册流程如下，通过不同的入口触发后进入，通过一定步骤后注册成功。当业务有了进一步需求，需要通过插件快捷登录时，步骤便可以重新组合，再适配具体的场景。对于设计师要做的，就是识别具体的通用流程有哪些，并将其给「步骤化」串联起来。当有新的需求来的时候，判断能直接复用，还是需要重新组装，亦或是新增步骤。而这样拼装的思维，恰好对应了研发搭建流程时的思路。通用流程对于他们就是将不同的步骤进行组合起来。当遇到不同场景时，再以搭积木的方式进行拼装。而具体的搭建步骤也是由两个步骤组成：1.第一步，收集流程；2.第二步，抽象步骤。具体方式上面已提到，就不过多赘述。④ 标准组件目标：将产品内使用过的组件整理成“标准组件”，统一定义规则，让后续设计和研发时能直接调取组件，提高设计和研发效率。其实行业中已经有很多通用组件，可以快速调用。但由于不同业务的复杂度不一样，也会生成自己独特的业务定制组件。同时，产品持续在迭代，也很难能抽出时间单独定义组件。故基于这个背景，结合“需求设计流程”和“组件整理流程”，有两种高效定义标准组件的方式。方式一：调用行业通用组件第一步，业务设计确定基本逻辑。第二步，挑选行业通用组件，增加业务规则。（一般开发在搭建产品初期时，便会选择一家行业组件进行使用，而组件也仅能在这家提供的组件中挑选）第三步，视觉根据全局视觉原则，设计新的样式。第四步，将交互规则、视觉样式合并，统一成标准组件。基础规则直接引用行业组件已定义的内容，场景规则按需补充。方式二：业务定制组件第一步，进行正常的业务设计。交互根据需求搭建原型，视觉设计具体样式。第二步，判断组件是否通用，是否可复用到其它场景。例如：分享对话框，不同的内容分享都能够用得到，像这种就是可抽象成标准组件的典型案例。第三步，定义标准组件规范。简单的组件展示具体样式即可，团队内设计师基本认知一致，无需重新学习。而复杂的组件为保证后续的正确复用，建议包括以下内容：1）更新日志：因为组件是变动最多的规范，需要明确具体的版本和改动点2）组件定义：简要介绍用途和使用规则，如对话框定义：必须是用户主动触发时才出现、主要使用在二次确认场景需用户确认后才消失等。3）组件结构：介绍组件构成、功能分区、分区定义，详细展示不同分区内具体信息和对应规则。4）使用场景：详细区分多种场景下不同的使用方式，明确给予使用指导5）设计方案：备选，如果比较复杂的组件且涉及到流程中的关键环节，建议可以考虑复制一个完整的设计方案嵌入其中，便于团队成员理解沿用。第四步，跟研发沟通，封装成标准组件。这一步是非常关键也是重要的一步，这将大大提高我们后续的组件复用率，降低重复性走查的耗时。推荐使用 CoDesign-设计规范功能点击体验 CoDesign 小程序，上传「组件库」后能够按目录自动生成规范文档，同时将自动标注和切图，大大提高研发开发标准组件的效率。⑤ 文案规范目标：将产品内各个场景内文案进行整理，帮助业务更准确表达意图，让设计师更好沿用，同时让用户感受到一致的产品风格。文案就像“产品对用户说的话”，不同的人说话方式可能并不一样，没有绝对的对错。但清晰明了的语言表述，让用户更容易理解；符合产品气质的语气，能拉近产品与用户的距离；统一的文案描述，又能让用户在整站一致的语境下体验产品。需要定义的内容，包括但不限于以下 3 个部分：语言：语言是指我们通过什么样的规则来组合文字，让它形成一种惯用的表达方式。例如语句简洁明了，不过度修饰，避免重复描述，使用简洁清晰的语序，帮助用户快速理解；例如用词精准易懂，使用简单、易于用户理解的词汇，避免使用专业术语，或过于口语化的表述。单纯说规则可能太虚了，在实际定义规范时，还要如下图所示，加上实际案例示意避免误解。语气：语气是可以体现产品气质和风格，定义时要结合全局原则内的设计价值观，明确产品性格后才能更好的定义出符合产品的语气风格。同一种语境下不同风格的文案就有明显差异。如网络异常时：俏皮的文案可能是：网络开小差，请稍等一下而正经的文案可能是：网络异常，稍后重试。书写规则：主要包括常用词汇的书写方式，例如「日期简写方式」「英文大小写方式」「使用全角标点符号」等。以及易错的词汇短语示意，例如「账号还是帐号」、「登陆还是登录」等。这是团队设计师最容易沿用遵循的，也是接地气的部分。具体使用指南：以上「语言」「语气」「书写规则」3 个部分，是构成全局文案的基础规范。如果有充足时间的团队，可以考虑再结合实际业务，分别定义不同场景和组件下具体的使用指南。如下图：最后再附上各个行业内定义文案规范例子，供大家参考：B 端产品文案指南：https://www.yuque.com/linyecx/dragonAntDesign 文案规范：https://ant.design/docs/spec/copywriting-cnClarity Design 文案规范：https://design.teambition.com/doc/introduction国家标点符号用法：http://www.moe.gov.cn/ewebeditor四、如何「推进」交互规范定义完交互规范，后续将考虑如何将其顺利的推进落地。本文罗列几个推进时重点需要注意的事项。1. 团队评审，达成一致规范的定义不是一个人的事情，而是一个团队事情，它将关系到每个后续每个人的设计产出。所以在制定规范期间，应该定期在团队中进行设计评审。这不仅是评审设计好坏的过程，更是让团队达成一致、大家更深入了解如何使用规范的过程。注意，参与评审的人不止是设计师，当然也包括具体的业务开发，很多时候我们会得到新的思路和启发。2. 善用工具，沉淀规范规范搭建的过程中，有很多痛点：组件库需要多人参与维护和创建，容易造成冲突内容丢失；同时沉淀规范文档时，需要图片逐一复制、粘贴到文档内，更新时又要重复一遍这样的操作。而这些问题，使用 CoDesign 设计规范功能，就可以有效的解决提高效率。首先组件库支持多人同时维护，差量更新；其次组件库上传后，可以自动生成/更新规范文档，避免反复编写文档，整体提效；最后当组件库有新版本时，会自动提醒团队内其他成员进行更新，保障团队设计一致性。3. 运用规范，指导设计搭建规范的过程其实也是整体设计走查的过程，我们会发现有些设计可能有体验问题，或不符合规范。每当这个时候，我们就需要对这些设计进行标记。在规范定义完成之后，迭代排期优化线上的设计。而在实际设计使用过程中，可能又会发现规范无法满足的地方，此时又可以展开新一轮的提炼和总结，再反哺规范，形成正向循环促使设计和规范不断完善。五、写在最后在前言的时候就有提到「交互规范」只是整体规范中的一部分，最终是需要与视觉合并成一份统一的设计规范，指导后续具体的设计。具体的合并方式，在定义的章节内已有提到，就不再赘述。最后，我一直认为好的设计规范是提高设计效率，引导设计方向，而不是因为设计规范而局限了具体业务的设计，如果这样，还不如不去定义。欢迎关注作者「腾讯CDC体验设计」的微信公众号：本篇来源：优设网原文地址：https://www.uisdc.com/global-interactive-specification-formulation
组件 结构 需求 什么是设计中的解构思维，解构思维怎么产生价值？本章结合 B 端场景进行了应用解读，通过对组件深入的解构理解以及对业务需求的解构设计，示意解构思维如何来解决 B 端业务需求和组件运用的问题，反映了解构思维的运作模型与价值体现。往期干货：遇到设计瓶颈无法脱身？五大章节帮你正确应对！前言：每个设计师都会遇到瓶颈，至于瓶颈期挣扎了多久各有不同。阅读文章 > 一、设计中的解构思维（解释解构）1. 广义的解构思维是什么“解构”一词富有哲学色彩，早期的出现是哲学家雅克·德里达不满西方几千年来的传统哲学思想，而提出的一种批判方法，是指对一切存在事物或现象的原因及本源研究，得出的稳定结构及其中心进行消解，每一次解构都表现为结构的中断、分裂或解体，但是每一次解构的结果又都是产生新的结构。解构具有消除二元对立、打破固有传统、去中心化、多元开放、包容差异等特点，对当下世界的多元化包容性都带来不小影响。而其思想内涵也在不同行业中生根发芽，在服装、建筑、平面、影视行业中处处可见解构，以此为根源，20 世纪 80 年代“解构主义”作为一种设计风格的探索开始兴起，解构主义用分解的观念，强调打碎，叠加，重组，重视个体，不见本身，反对中心化或总体统一而带来的支离破碎和不确定性（例如肤色阶级的种族歧视、早期重男轻女封建思想等）。如何理解呢？“解”有分解、拆解、理解的意思，而“构”具有结构、构造的意思，字面意思就是对事物的内容结构进行剖析。通常解构被认为是对传统认知里的结构进行质疑和破碎重组，并建立具有新意义的结构。例如你一天放了 7 个不同声音的屁，通过解构，我听到的不再是屁，而是音符，经过谱曲，我成就了一首。好的翻译也可以视为解构，这个过程就是译者对本质含义进行理解并使用新的语言结构释义，其表达的本质没有变，却拥有了更为生动明了的译文。2. 体验设计中的解构思维一般结构形成表象，表象反应本质，但需求的构成是由其他本质推动的，这些本质既能形成 A 结构，就必定能造就 B 结构，所以解构主义不认为结构与表象能代表本质，设计中解构思维可以帮助我们跳出传统的条条框框，就好像在说时代变了，你那套不行了。体验设计的范畴中，我将解构思维简单概括为：不停留于结构表象，敢于质疑、深入本质，再创结构，是一种打破设计相关秩序然后再创造更为合理秩序的思维主义，是对本质的深入与多元化的理解，而体验设计中的本质常常是以需求作为出发点，以用户和场景作为合理性的准则，以解构出具有体验或商业价值的方案。一把舒适的椅子如何设计，从人体工学椅子到懒人沙发，依旧是一个不错的解构案例，原来舒适的椅子可以这样。3. 解构与拆解、原子理论的区别拆解是对某个事物按照一定逻辑或结构进行分解拆除，目的是获取更全面或更深入的信息与理解，从而加深对本质的理解，拆解并不影响事物本身的结构或中心，而解构主义则是出于对结构或中心的质疑展开的，并试图找到新的侧重点或视角来理解本质，目的就是建立具有意义的新结构，同时在建构的过程中，还会用到更替、融入、结合、间离等手法，而并非是线性的拆解组合，在体验设计的应用中，我认为解构有益于深入研究，以及跳脱竞品或传统结构设计的思维局限。原子理论在 B 端组件系统中有深入的应用，像搭积木一样，重心是找到可以复用的最小单元，然后利用这些单元组装出更复杂更庞大的结构体，并且对这些单元的资源进行重复性利用，以减少生产过程中带来的资产冗余、不一致、低效率等核心问题。侧重点是交互层与功能逻辑，是一种工具化、模块化的思维，主要是业务解构后进行 B 端交互页面搭建的工具。但是在传统 B 端业务设计的背景下，解构思维可以配合业务情况对组件传统的“组织”及以上的结构进行破坏重组，以诞生新的结构并更好契合业务。二、再说说 B 端组件系统（解构对象）1. 组件系统的诞生背景B 端向来是以业务操作为主，而在繁琐的操作过程中，尽管界面或场景不同，但是有很多操作行为或操作内容具备较高的一致性，为了减少对应资源的反复设计与开发带来的时间浪费与资源冗余，这些对应常见的交互组件被系统化了，同时在不断探索更基础或高频率通用的组件单元，以便后续的研发设计中可以随时调用，于是组件系统诞生了。2. 组件系统的核心价值从内部研发视角来看，已经提到的减少资源冗余与效率问题便是核心价值了，从界面设计与品牌调性来看，使得产品样貌与操作更为统一规范，便于资源管控。而从外部视角来看，一套开源的设计系统还能赋予生态上的改变，一套基础完善的 B 端组件系统可以支撑内部庞大的业务的同时，也可以赋予友商或帮助其他小微企业研发中后台，对于业务生态、研发生态都有好处，收获口碑的同时，是一种文化价值传递，也是影响力的渗透。3. 什么时候搭 B 端组件系统从技术难度工作量以及研发周期来看，显然不能短期获取回报，往往只能在业务生态需求量大、涉猎业务复杂或是发展迅速才有较好的价值体现，当然了不差钱为行业生态做贡献也可以啊，尽管如此但也不是说不建议设计组件系统，具体也要看研发背景与组件系统搭建程度；① 研发背景参考要素大部分中小型企业，业务不是特别复杂，研发资源很有限，那就直接考虑开源组件系统好了，用现成的真的便捷太多，并且也不会涉及到到数据安全的问题。如果要搭建组件系统，那就需要考虑自身研发资源(时间、人力、成本)硬不硬，然后就是业务复杂程度是否大多开源的不能轻易满足，这两点很重要。② 组件搭建程度情况第一层实现设计产出加工件：借助 Sketch、Figma 等主流 UI 设计软件搭建界面常用的组件库，用于内部设计资源流通，快速搭建 UI 界面，保证界面组件统一性和效率保障，搭建起步不要考虑全面，先从最基础最常用的开始搭建。第二层沉淀对应代码库：设计师有了可复用的设计组件还是比较初步的，重要的是研发工程师对可复用的组件开始沉淀，并建立资源库，研发过程中可能会伴随业务需求一起完善，对于已研发的组件可以同步记载完善交互，然后规划版本逐步完善。第三层设计代码一体化：设计与研发的组件完成版本一致，实现组件从视觉效果到交互效果反馈完整，状态齐全，引入即用，实现真正意义上的组件系统。③ 进行系统二开维护基于业务情况与开源组件系统进行二次开发，来建立沉淀自家的组件系统，如果这么做首先考虑的还是研发背景情况，进行二开可以节省不少时间，并且可以有更多差异化定制化的空间，需要注意的是目标二开系统的灵活性、扩展性等核心问题。三、用解构思维深度理解组件（开始表演）1. 从表象到数据背后我们通过 B 端中后台的表象开始解构，映入眼帘的往往是各种功能的导航、操作入口、信息反馈，很清晰很明了，各种操作都被组件结构所包揽并示意。似乎已经看到了组件的作用，但又好像看见的还不够，我们再次深入，组件的背后是便于操作，而操作的背后是什么，似乎很接近了，我们结合界面交互的构成结构换个视角看问题，如果没有这些组件，任务还能进行吗？显然具备代码能力是可以的（毕竟有些开发天天就是对数据 CRUD，不理解就问研发 [手动狗头]），那么现在看来组件的作用就清晰明了呢，“组件是提供间接的代码操作工具，便于我们通过界面交互来控制代码数据的交互，帮助减少操作的门槛与理解成本”，我把这理解为组件的底层价值。2. 解构组件的功能逻辑组件本身注重的是行为逻辑，即交互逻辑，非业务逻辑，是业务逻辑构件的工具。从交互视角切入，基本的交互原则是组件本身必备的，要易于理解、易于操作、及时反馈，而组件运作的本质逻辑我理解为对数据的约束、反馈与数据交互，什么意思呢？你听我说人话：① 约束作用看看以下图片中的举例，直观感受一下组件约束能力的价值。第一组是没有注重组件约束功能的，而第二组是采用了合适的组件约束能力后的效果；通过以上对比，不难看出输入输出的信息都得以约束和规范化，从数据、从业务、从浏览都产生了极佳的效果。而在不同场景下这些约束会有差异，为的是更好满足业务需求，因此就诞生了具有不同约束能力的各种组件，这里再枚举一些例子；② 反馈作用反馈即通过数据加工产生更容易理解的表象，以及在操作后的提示反馈。反馈可以告诉我们有什么是什么、帮助理解这些信息有多少类目、理解这些信息有什么特征、理解这些信息量情况、理解此处有何操作等，尽管相同作用的反馈可能有不一样的样式，但这并不影响统一性，差异化只是满足不同场景或不同容器特征而已，例如会话窗口通知与文本 tips 同样是信息反馈，那么显然会话窗口更加重视信息接收程度，出现场景更加正式醒目；而这整个过程的反馈基本上围绕“映射”原理进行，从代码层获取信息框架再通过界面释义，就像是一段巧妙而精准的翻译一般，业务是否吃透、组件用的是否得当、体验是否良好，都要看这“映射”的功夫下足了没有；③ 数据交互具备数据交互能力，即可以通过组件对界面上的数据发生变化以达成任务操作的目的，说人话就是可以直接帮助我们控制界面元素和数据增删改查，例如搜索就是利用组件输入查询的关键词，并通过按钮或键盘发起数据索引，最终获取反馈信息帮助我们完成任务。B 端数据交互的类型相对是比较简单的，主要包含了富文本、图片、动图、音频、视频为主，复杂的地方在于特殊格式的兼容和深入编辑的需要，因为要有指定的解码器支持文件的显示以及操作存储，这也就意味着可能需要制作新的配套组件，或是引入其他的组件进行二开，例如代码编辑器大多 B 端公开系统是没有提供的，这就需要新开发或新引入。3. B 端组件的同质化现象在第一台携带操作界面的计算机诞生时组件就有了，时过境迁，计算机界面的交互组件也配套设备输入输出的特征逐步定型，对比当下主流的开源 B 端组件库，不难发现基础的组件只存在细微交互动画与视觉差异，功能逻辑基本一致，这是源于多年来计算机的快速发展沉淀下来的人机交互认知与共识，一切看似有标准但又没有绝对的标准，约定成俗一般。尽管 B 端组件还有一定个性化或差异化的空间，但大多也只是视觉表现层的一些调整，并且面对市场大众化的组件认知与趋势，很难做出别致的差异化了；也许在 B 端组件发展的道路上，只会同质化越来越严重吧，没有新型业务需求驱动，可能现有的基本组件就定型了，而市场上的组件系统也会被广泛的应用与习惯，当广大用户养成了认知与操作习惯后，就更没办法对组件做出差异化了，这会违背大多用户的认知与操作习惯，所以对组件本身进行解构创新的价值不大，解构的重点是功能用途的深入理解与应用。4. 组件对设计师的价值B 端重业务、重效率、少个性，而 B 端组件同质化正在加剧，那么设计师也就没有必要去过分考虑组件的差异化或个性化，聚焦新型业务的交互组件或是业务需求设计才应该是众望所归，而组件系统的概念与组件的理解应用也应该成为设计师的标配能力，“组件”一定是 B 端设计师的重要价值，却一定不能是核心价值，所以了也不要老是说 B 端的设计师们就是在搬组件了，这墙砌的不好吗？四、解构思维让组件得心应手1. 用好组件，先从需求解构开始不同组件的功能用途首先要理解，至于使用什么组件取决于需求的数据交互以及约束条件和反馈需要，而这些条件均来源于需求，这个过程中，要发挥好解构思维的精髓，那么第一件事就是说“这是个伪需求”，一定不是思考如何执行需求，而是从质疑需求开始，接着就会开始对需求拆解厘清，当需求的结构被你摸清时，你就能感知到需求是否合理，是否有更优方案。然后就可以跟需求方说说你的观点，我早些时候也是得益于这种思维模式，能够加深对需求的理解，同时跟产品有来有往，对方也更愿意主动来探讨，当然呢，需求方是不是傻*心里也就更有数了。要开始需求解构呢，就要先清晰需求的结构，一般来讲即构成需求的背景、场景、人群、流程、目标、模式等问题，然后拆解分析找到关键因素攻破。当我们完成需求解构后，就需要进一步通过对需求的流程、信息、关键词进行提炼，以匹配需求实现所需要的组件，匹配的本质是依据信息特征和功能要求，即信息的图文视频音频类型、格式兼容属性、数量单位、映射反馈、逻辑含义、约束条件等关键词，整个解构过程可以用以下这个模型来概括；案例一：组件区块解构案例中，在这套传统数据表格里，我们需要添加部分微型数据图表信息，提供给部分角色查看和比较前后行的数据差异，那么是你会如何进行解决呢？传统选手使用添加“查看图表”操作，通过点击后利用抽屉或弹窗承载图表数据；并在图表显示面板上补充了切换上下条数据用作比较；解构选手把传统表格给改了，采用了可扩展表格，并将数据图表以卡片的形式嵌入了表格，通过点击展开查询图表数据，可以随时展开和收起数据的图表信息。两者间有何差异：传统往往是做加法，解构则是对现有结构做改变。这个过程中解构的是表格扩展数据的各种可能性，以及需求本身的目的是什么，而结合起来找到一种新的表格方式来实现需求。尽管后者方案表格代码需要做更多调整，但是优势显而易见的，在保障能够实现的情况下，约束了表格横向的宽度延伸、展开数据支持二次加载减少了请求并发、支持多行数据展开图表对比，尽可能减少了操作步骤。案例二：解构树状列表需求需求简述；要做一个树状结构的表格，用于呈现控制节点的基本信息和关系示意，主要是提供给节点管理角色使用，构成的主要信息框架如下：传统设计中，提供设计的关键信息与关键词基本已取得，我们可以根据需求开始构建页面了，第一步搭建支持展开收起的表格，用于反馈节点的层级关系，表格 Title 主要由节点名称、描述、Owner 名称、工号、部门抬头、分布域、节点开关构成即可，开关进行操作时进行二次确认弹窗确认即可，大致原型图如下：解构思维怎么设计呢？第一步质疑结构：为什么是树状，为什么是表格，这个结构主要包含了什么，重点是什么？表象反映出了什么样的本质？这样带来了什么问题？第二步破碎拆解：带着问题对结构拆解，对构成的各方面深入理解，找出新的发力点以及更全面的信息。——需求结构特征：树状结构、信息显示、开关操作——需求本身的问题：信息优先级、节点数量规模、默认显示节点、是否支持过滤、关联数据或功能情况——需求结构化：需求对应的场景、参与和使用的角色、服务的作用影响、底层逻辑与流程、交互的信息框架当然了，需求结构化的方法并不是固定的，可以如上将构成的因素厘清，也可以通过服务蓝图或运作模式来将不同阶段进行拆分和理解。——拆解结构深入理解：对结构构成的多方面进行思考，找到关键因素或核心价值，并重新审视结构，来帮助构思新的需求方案。以上需求通过对需求服务对象和需求方进一步沟通，了解到节点管理者更关注树状结构的关系、节点的名称、描述、分布域信息，然后才是负责人跟开关操作，并且节点分为三大类型，有时候会先注意是什么类型，然后办公时会根据名称路径去找想要指定操作的节点，其实节点数量一般在10-30个之间，并且一般都是从第二级开始操作，后续数量上也不会怎么变化，节点与节点之间的互通则由开关直接影响...第三步重塑结构：经过解构我们将构成聚焦放在节点管理员身上，并获取了更为全面和有价值的信息，接着我们进入建构阶段，思考如何更好的满足节点的层级与流通性，当前现有的数据支撑和遗漏可用数据有哪些，数据的显示并不是难点，我们开始思考哪些组件区块具备层级关系与流通状态示意能力，在呈现时，如何更好服务节点管理者的使用场景，带着这些问题我们开始重新对需求进行设计，以及匹配合适的组件搭建原型。第四步匹配资源：放弃了树状表格，但是延续了树状结构特征，对于节点的类型重新补充了进来，而信息也重新调整了优先级，使得整个需求结构更加完善合理，原型阶段，我们通过拓扑结构来取代了表格，支持子集展开收起，并且以卡片来承载节点信息与操作，节点之间的卡片也用不同颜色的线条示意流通性，在有限节点中，也更好的突出了个体，默认也直接显示完所有二级节点，大致原型图如下：案例小结对于解构思维应当施加一定的灵活性，要识别是否具有深入和颠覆的解构价值，没必要过度的解构，解构以后的建构也很具有挑战性，你要思考优化结构赋予价值。另外有时候经过解构思考后，结论与原本的需求结构差异不大，甚至你也认同原本的方案，这并不冲突，这说明原本的设计者也是严谨或靠谱的，并且深入理解的过程是宝贵的，在体验设计的范畴，解构思维应该是为我们提供别样的视角，帮助我们深入本质解决问题，并不是为了生成新的结构而解构。五、解构思维对 B 端的价值1. 突破对传统结构的思维局限产品设计中，常常开玩笑说就是互相抄来抄去，要是竞品毙光了，都不知道接下去怎么设计了，很多时候我们看问题常常凭借经验或直觉看表象，未能深入或大胆的批判人家的不好，对权威提出质疑，而解构思维正好反其道行之，以使得我们对竞品分析或用户研究后不会拿出一个显而易见的结果，却没有深入的结论做业务抓手。解构思维可以去中心化去权威化，帮助我们深入并注意到构成个体的价值，以为业务带来更多的可能性。2. 业务优化或改版的得力助手看起来没什么问题，或是对方案没有底气，那就试着解构一下，先把页面里的业务拆出来，在把业务之间的关系和逻辑才拆出来，当你解的足够清晰明了时，面对不同场景或角色特征，需求优化的方向就开始清晰了，解构思维能让你变得游刃有余，是业务分析和理解的一把好手。3. 深度理解组件原理与应用以前总是问这个组件怎么用，其实应用解构思维后，才发现原来是自己太懒了，没有进一步的对组件进行思考和理解，其实运用解构思维想想人家组件为什么这么做、还能怎么做、什么场景下用，马上就通透了，并且对于组件的模块化改造也是有着相当的作用。六、结语早些时候，我以为的解构，就是对某个结构进行拆解加深理解，而之后又意识到还要用一些颠倒、反转、重组、叠加等一些列手段进行建构，目的是形成一个不同于以往的结构，再后来才发现解构也没那么简单，解构主义更注重的是对传统观念中的结构发起的质疑，从而引发新的深思，将本质不再停留在结构与表象本身，并试图找到新的或其他合理的点进行重新建构，最终带来不一样的结构或价值体现，这种例子也在当今多元化的世界处处可见，稍加灵活的应用，解构也会是不错的工具。当然了解构已经在各行各业开出了不一样的花，怎么理解怎么运用会有所不同，这里主要也是分享了在体验设计领域中我对解构思维的理解与运用，算是抛砖引玉吧，你有看见什么好例子吗？评论里告诉我，我们一起解构解构本篇来源：优设网原文地址：https://www.uisdc.com/deconstruct
产品 组件 系统 前言本文总结了在工作过程中可能面临的疑惑与问题，并结合自身经历输出相关设计经验，希望能够帮助新人设计师快速上手 B 端设计。首先，作为一名新人，在接触 B 端设计的时候应该怎么样才能快速上手呢。我们可以从：了解 B 端的基础知识、了解组件的用法、体验优秀产品这三个方面去快速了解 B 端设计知识。一、了解 B 端基础知识1. 什么是 B 端产品B 端产品的使用对象是企业，组织；目的是帮助企业，组织解决某一类经营管理相关的问题，进而帮助企业提高收入，提升效率，降低成本，控制风险。B 端产品更讲究严谨的流程设计、贴近现实的场景面积、低风险、高效率、数据精准；B 端产品的用户无法决定自己使用的软件，决策权在为软件付费的人手中（例如：公司高层，老板等等）。2. B 端产品的价值B 端产品的价值在于：集中管理（举个例子：公司通过要求销售人员将客户信息录入后台系统，避免因为销售人员的离职导致客户的流失），降本增效（可以规范化，集中化管理销售人员的行为）3. B 端产品的分类我们常见的产品有：SaaS，PasS，IaaS，SCRM，ERP，OA 等等，但我们可以根据产品针对的服务对象去进行分类，我们可以分为四个方向：专业领域产品，行业解决方案，办公协同系统，运营管理平台专业领域产品：是针对企业的某类工作场景所使用的 B 端产品，常说的 SCRM（销售自动化平台）、ERP、HRM（人力资源管理）都是专业领域产品的范畴。一家公司可以拥有多个专业领域产品，例如公司拥有一个 OA 系统的同时，销售的同事还可以拥有 SCRM 系统。行业解决方案：围绕某一个行业进行的，针对行业所需要的功能进行拓展，能满足行业的使用需求即可。办公协同系统（OA 系统）：针对公司内部协同办公使用，例如我们常见的钉钉，飞书，企业微信都属于办公协同系统（OA 系统）运营管理平台：针对客户端运营活动或者具体内容展示，对推送目标人群进行管理。例如火山引擎，极光推送等等同时，我们可以根据产品交付方式进行分类，可分为：Saas，Paas，Iaas，定制化产品；引用 IBM 架构师 Barron 用披萨作为比喻来具象化这些交付方式的形式：定制化产品：服务于大型企业功能定制设计；需要什么特殊口味/形状的披萨都可以找餐厅定制。标准化产品（SaaS）：把开发、管理、部署都交给第三方，客户选择功能的权力较低；他人直接制作好完整的披萨，不需要你的参与，你只需要把他卖出去，最多在包装一下印上自己的 logo 就好。配置化产品（PaaS）：开发者只需要关心业务逻辑，不需要关注底层，客户选择功能的权力较高；除了基础设施，他人还提供披萨饼皮，你只需要把自己的配料放上然后让他去帮你烤熟即可，也就是说你只需要设计好披萨的味道（海鲜口味或者意式披萨），他人提供平台服务帮你把设计完成。基础服务产品（IaaS）：是云服务的最底层，主要提供一些基础资源，用户需要自己控制底层去完成业务逻辑；他人提供厨房炉子这些基础设施，让你来烤这些披萨。除了去了解关于 B 端的一些基础知识以外，如果想要更高效的去完成工作，设计师们通常都会去深入了解通用组件的使用方法。二、了解组件用法花时间去了解组件的使用是非常有必要的。组件作为我们设计当中的基础单位，等于说我们了解了组件的使用，就知道 B 端设计的基础原理。目前市面上已经有很多开源并且很成熟的组件，并且每一个设计系统里面都有对应的设计资源的分享、设计组件的解析、以及设计原则的确定，可以通过参考这些深入学习。1. Ant DesignAnt Design 是蚂蚁集团的设计语言，目的是为了提供完善的设计指引、最佳实践、设计资源和设计工具，来帮助设计者快速产出高质量产品原型。2. Element UIElement UI 是 一套基于 VUE2.0 的桌面端组件库，Element UI 提供了丰富的组件帮助开发人员快速构建功能强大、风格统一的页面。3. Arco DesignArco Design 是字节跳动出品的企业级设计系统，对于新手入门有一定的参考价值。字节跳动全新发布！ArcoDesign 设计系统正式开源https://v.youku.com/v_show/id_XNTgxNjA2OTQwNA==.html?spm=a2hcb.profile.app.5~5!2~5~5!3~5!2~5~5~AArcoDesign 是什么？阅读文章 > 通过了解成熟的组件，我们可以比较局部的去了解 B 端设计控件的使用方式。所有的产品在控件与控件、控件与页面、页面与页面之间都会存在一定的联系，所以设计师们为了提升自己，经常会去体验市面上比较优秀的产品。三、体验优秀产品B 端和 C 端一样都可以通过临摹去了解现有的设计模式，参照市面上优秀产品做设计对于新手入门而言是快速提升的途径之一。通过临摹，你能够确定阅读的具体宽度与内容，让你对整个产品的页面布局有了初步的认知。关于临摹哪些页面，本人有一些小的建议。通用的典型页面可以临摹 Ant design pro 和 Arco design pro 里的页面作为参考进行设计；涉及到行业领域进行设计的话，可以参照一些优秀的竞品进行设计，例如运营管理平台，可以参照 神策智能运营 进行设计；更多竞品查找方法：B端设计师如何体系化了解业务？4个步骤快速搞定！前言接触 B 端设计的小伙伴会发现，很多业务具有角色多，业务场景复杂，功能链路长等特点，所以在工作中会经常遇到以下几个问题： 突然被调配到新业务，拿到一个不熟悉的业务或者新产品，不知如何开展工作？阅读文章 > 写在最后以上几种方式只是新手快速上手的小窍门，在工作中 B 端的设计也不仅仅是套组件和抄界面；移动端和电脑端的交互方式还是有所不同的，所以如果想要得到提升还是需要通过阅读相关书籍，主动了解基础的设计模式，了解业务场景、角色使用场景等等，从而优化用户操作路径，让 B 端系统的体验得到真正的提升。欢迎关注团队微信公众号：兆日 UCD本篇来源：优设网原文地址：https://www.uisdc.com/beginners-guide
插画 组件 用户 在互联网企业日常的项目需求中，插画经常会大量的运用在各类产品设计、产品运营、产品宣传中，但是传统的插画方式主要存在以下几个问题：不同岗位不同的设计师产出的插画风格不一致，质量参差不齐每次的设计插画需求都是从头开始绘制，插画的产出效率太低插画的风格不一致很难形成一致的品牌印象，品牌感太弱于是我们可以看到一些互联网团队已经走在了前面，通过构建系统的插画组件库来解决以上 3 个问题，对于设计师来说，插画组件库虽然已经不是什么特别新鲜的话题了，但是实际的执行过程中大部分设计师可能会遇到很多难题。那么，今天的飞凡指南就通过 3 个方面来深度解读下插画组件库的这个设计话题。更多插画组件库干货：保姆级教程！手把手教你做超实用的插画组件库（附组件库下载）今天给大家带来的是如何建立设计师个人的插画组件库，因内容过长并知识点过多，请泡杯枸杞观看。阅读文章 > 一、插画组件库的价值1. 设计提效当我们通过传统的流程去设计一个运营页面的时候，往往需要 2~3 天的时间，但是有了插画组件库，设计产出的效率基本上可以提升 1 倍以上，而节省出来的时间，设计师可以去考虑更有价值的事情2. 统一风格整套的插画组件库，在构建的时候，对风格、色彩、人物、元素、背景都有着统一的规范，在面对不同设计能力设计师的时候，都能够较大程度上保证风格统一和插画的产出质量3. 提升品牌感插画组件库在构建之初就要考虑和产品调性、品牌调性的一致性，这样在传播的过程中才更能在用户心中形成一致的品牌形象，提升品牌感二、插画组件库需要考虑 4 个方面的问题当我们在构建插画库的时候，以下 4 个问题是我们需要重点考虑的：如何凸显产品属性；如何体现品牌调性；如何满足用户场景；如何打造差异化的风格凸显产品属性：插画的最终目的是辅助文字去传递产品信息，我们需要直观的向我们的用户告诉我们是干什么的，而避免用户做过多的思考；如何体现品牌调性：和消费品一样，品牌是用户考虑的一个非常重要的因素，插画是传递信息和塑造品牌调性一个非常重要的渠道，所以插画库应该考虑如何能够对我们的品牌调性或产品调性进行补充如何满足用户场景：在考虑插画的元素构成的时候，我们也需要把用户考虑进来，他们使用产品的时候是哪些场景，再基于用户的场景去设计我们的插画组件元素，这样在实际应用插画库的时候才能够尽可能涵盖传播的场景如何打造差异化的风格：我们可以看到各大互联网产品的插画风格都基本上非常雷同，很难有明显的插画风格特征，这样的结果就是用户很难记住你，所以对于插画差异性的考虑也是一个很重要的点三、插画组件库构建的 3 个步骤对于设计师来说，最重要的还是如何将插画组件库落地了，总结下来可以分为 3 个步骤：插画风格推导、插画组件库搭建、插画组件库应用1. 插画风格推导插画风格我们主要可以从 3 个方面去推导：品牌、用户、产品① 品牌我们需要了解的是品牌的调性、色彩、辅助图形、logo 特征、品牌资产...，这些都是我们构建品牌插画库的基础参照。比如下面这张图是梳理的出来的 fashion data 的品牌相关元素：② 用户&产品了解我们的用户和产品，我们可以用以下这个电梯宣言的方法去梳理：关于用户：为了满足「目标用户」，他们的「什么痛点或需求」关于产品：我们的「产品名称」，是一个「怎么样的产品类型」；它可以「关键优点，通过什么样的功能，为用户带来什么样的价值」；而不像「市场上某竞品及其特点」；我们的产品是一个「主要独特价值点」比如，下面这张图是对 fashion data 的用户和产品进行的梳理，去快速的了解用户的需求痛点、产品定位、产品价值...了解完品牌、产品、用户之后就要推导出插画库的风格方向了。在讨论 fashion data 的插画风格选定的时候，其他几组插画在风格上差异性和个性表达上虽然会比较强，但是和 B 端产品的定位差异比较大，最后还是选定了普通的矢量风格插画风格，它能比较好的像用户传递出 B 端产品的高效、专业、严谨的品牌形象，后期差异化主要是通过融入品牌元素和塑造插画角色这 2 个手段来体现。2. 插画组件库搭建插画组件库的搭建，可复用性是我们考虑的重点，要达到这个目标，我们构建分子的时候就应该尽可能的把插画拆分成比较细的分子，比如头部我们可以拆分成不同角度的基础头型、发型、表情...① 角色组件定义角色基础的形体比例、肢体细节形体比例、肢体细节基本上就能够确定我们的角色是何种特点，比如，我们常见的互联网扁平插画风格就和我们的正常人物比例、肢体细节比较接近一些，但是一些欧美的插画风格经常会用很夸张的比例造型来塑造个性的角色，比如头特别小，肢体特别大。还有不同人物的比例也会有所不一样，比如男性女性的黄金比例是 9a（九头身），小孩的比例大大约是 4a，但这不是固定不变的，还要看具体的插画风格。为角色搭建灵活的骨骼系统构建组件库，我们自然是希望我们的插画能够和人的骨骼一样，能够灵活的做出各种动作，这就要借助于灵活的骨骼系统了，通常情况下我们可以将我们的人体骨骼拆分成以下的组织。在组织的连接处，我们尽量都能够采用正圆形，这样在变换动作的时候才能够更好的衔接上，大家可以看看传统的皮影人偶也是采用的这种连接方式，才能在舞台上作出灵活的动作。建立不同角度下的表情、动作、服饰等组件人物的应用场景不仅仅只有正面的角度，还有其他的角度，我们一般只需要设计正面、半侧、正侧这 3 个角度即可，在这 3 个角度我们需要构建不同的表情、动作、服饰...尽可能满足角色在不同场景的使用需求。② 通用组件通用组件我们一般基于用户场景来制定。比如下面的这个案例，fashion data 是一个高效的跨境电商数据管理平台，主要针对店铺运营人员，为他们提供快速管理店铺商品、直观查看店铺经营数据等服务，所以用户的场景主要办公场景和业务场景，办公场景的元素有比如：书桌、电脑、办公用品...；业务场景的元素有，比如：仓储、物流、数据、商品... ，最后我们再基于这些元素去制定通用的组件。③ 背景组件背景组件一共可以分为 2 种类型，场景背景和纹理背景。场景背景一般是基于某个特定的场景来制定的，用来交代画面所处的环境，比如室内背景、白天、黑夜、晴天...纹理背景一般是用来装饰和丰富背景，比如下面的插画，加了背景纹理插画明显层次和画面更加丰富了。3. 插画组件库应用搭建完组件库之后，就可以在产品运营、线下物料、产品界面使用它们来提升设计的效率了。当然随着业务不断的变化和用户场景的变化，我们的插画组件库也应该及时的扩容和优化。写在最后需要提醒的是，插画组件库的目标是帮助那些重复、且设计质量要求不高的设计需求提效，而设计难度较高的设计需求还是需要设计师来处理，而这才是设计师能够真正体现价值的地方，同时，把时间节省出来，设计师才有精力去思考更多更有价值的事情。本篇来源：优设网原文地址：https://www.uisdc.com/illustration-component-library-design-guide
组件 场景 业务 在 B 类业务里，服务多产品、多角色、体验复杂，设计师该如何做好体验标准化，保障基础体验一致性？下面我将从实战案例同大家分享。更多B端设计干货：B端设计太复杂？掌握这三步帮你理清设计思路！写在最前B 端界面的元素众多，视窗范围大，布局设计多种多样，为了简化布局思维，我们通常给界面添加三个方向上的轴-X、Y、Z。阅读文章 > 一、业务背景以我们 CCO 体验设计团队为例，主要服务阿里体系的消费者、商家、经济体等业务领域。随着业务不断扩大、用户角色多、体验复杂、设计师人力有限、定制化需求不断增加，设计面临严峻挑战。业务多：30 多个产品应用角色多：覆盖消费者、客服小二、服务管理、业务运营、中台管理、客户 6 大类用户群体。体验复杂：设计师需兼顾用户和客户两个视角。从组织上，85% 设计师纵向支撑业务，15% 设计师横向做标准化，反哺业务设计师。标准化实质解决的问题是保障基础体验一致性。二、标准化怎么做核心通过页面梳理、抽象、分发、衡量，保障基础体验一致性。三、案例实战以数据可视化场景为例，讲述如何做标准化。1. 业务现状共有 11 个应用，涉及 89 个页面。2. 问题体验不一致：各个工作台页面架构、组件、样式野蛮生长，缺少规范导致体验不统一。低效：部分场景缺失，组件重复建设，大量定制；沟通协同内耗大，成本高。3. 策略体验统一：框架、组件、样式。提效：代码化、工具、交付机制。4. 体验统一包括框架、组件、样式。① 框架现有页面收集用户场景分析：页面归类：结合用户看数内容（例：概览、分析、详情）和交互形态（例：平铺、下钻），对页面进行归类。通过统计高频复用形态，确定典型布局。② 组件页面结构分析组件的收敛，需要先对页面分析，确定模块层内容。例：模块包含页头、筛选、图表、表格。模块层分类横向收集全部业务，将模块层分类。细分模块扩展形态，放到对应的篓子里。模块专项治理接下来，需要对每一个模块进行专项治理。比如图表模块，再拆再抽象成指标、图表、单选、多选 4 类场景。场景里再对主体和变体（也就是扩展形态）分类。③ 样式确定优化内容围绕视觉凌乱，要做的便是完善设计语言。设计师需要结合自身技术底层，补充缺失规范。例如布局、色板、字体、动效。确定组件范围通过统计高频复用组件，确定需要梳理的组件范围。布局图例位置：线上有 9 种，通过从业务场景按阅读顺序划分，最终收敛成 2 种。组件高度：真实线上情况，只能看 2 个指标，高度规范缺失。需要根据用户分辨率调研，提炼典型分辨率。比如用户是 win 系统，包含菜单栏、任务栏等默认高度，再减去本身页面页头等默认高度，得到 3 档。确定组件建议默认行高 240px。轴标签旋转角度：现状有顺/逆时针两种，通过分析标签类型，结合阅读顺序、轴与标签亲密度，确定默认角度为顺时针。色板通过场景梳理，确定不同组件使用的色板类型及缺失色板。补充语义色板：从业务里抽象 2 类场景，指标和柱/饼/环场景，定义颜色。例如带正面语义，用绿色，比如升、已到岗、正常。带负面语义，用红色，比如降、旷工、失败。字体结合自身业务场景问题，从场景、版权、风格、识别、极值共 5 个维度选择字体。举例场景一，纵向数据场景里，将市面上数据竞品用到的字体都横向铺开尝试，做排除法。比如 din 没版权，苹方非等宽字体，普惠 102 识别性弱。举例场景二，在核心数据呈现中，helvetica 品牌风格弱，普惠在 1 亿以上极值过宽。最终我们根据自身业务场景特征，用普惠和普惠 102，运用在对应场景里。并同前端提炼规则。动效首先，需要确定动效价值，明确动效需要解决的问题。这里围绕舒适度、活力、层级、反馈来讲。通过动效场景链路分析，确定优化范围。加载动效：围绕让用户认知过程更为自然。通过组件横向梳理、抽象图形、组合样式的思路，输出方案。比如这里共梳理 17 种组件类型，抽象成 9 类，包括点、线、面、饼、环、柱、文本、图标、词云，再进行组合产出方案。出场动效：通过业务分析、提炼场景、优化效果。比如这里共提炼 3 类场景，有通用、监控、舆情。围绕过渡不自然、卡顿、缺少情感化表达来优化效果。浏览动效：通过提炼场景，来强化元素之间的层级与空间关系。比如单个组件、联动、下钻场景下，围绕点击感知弱、重点不突出、缺少悬停态来优化效果。沉淀速度参数：将优化动效场景的速度参数，同前端约定规则沉淀组件库。5. 提效包含代码化提效、工具提效、机制提效。整体思路从设计组内到技术产研的提效过程。提效面向用户依次是：组件设计师、业务设计师、前端、产品。搭建目前还在进行中，这里主要从交付-工具-代码化来分析。交付内容业务设计师：sketch/figma 物料 (样式、组件、区块、模板、规则 )业务设计师：kitchen 工具（样式、组件、区块、模板）组件工程师：组件规范/组件官网交付机制新需求：通过评估复用性、抽象、内审、沉淀物料。现有业务：通过页面梳理归类、抽象、内审、沉淀物料。6. 衡量从物理到行为层，包括样式、组件、框架、组件交互 共 4 个维度。通过一致性评分衡量标准化覆盖的好坏。四、总结回归课程，在 B 类业务里，服务多个产品、多用户角色、体验复杂的场景下，在定制化+标准化团队阵型里，标准化实质解决的问题是保障 60 分基础体验一致性。总结：B 端体验标准化包括物料的产出、交付以及衡量标准。产出：包括框架、组件、样式的收敛来梳理、抽象页面。交付：面向 2 类用户群体，业务设计，需交付物料和工具。组件工程师，代码化需提供组件规范，组件线上化需助力组件官网的建设。衡量：一致性评分包括样式、组件、框架及组件交互。欢迎关注作者的微信公众号：「AlibabaDesign」本篇来源：优设网原文地址：https://www.uisdc.com/experience-standardization
字段 系统 组件 选择对于 B 端系统来说究竟意味着什么？如果将下图两个组件摆在设计师面前，它们唯一的差别便是 一个有着右侧的下拉箭头、一个右侧没有下拉箭头。当听到了这种解释时，我也就只能摇摇头，一方面感觉很多设计师的基础薄弱，同时又觉得需要和咱们读者来讲讲，关于选择这一大类，对于我们设计师究竟有什么意义？首先，选择类的组件对于我们来说已经非常常见，比如简单的：单选框、复选框，难一点的：级联选择、层级选择、树形选择，这些都是我们选择类组件的一个大的范围。同样的输入也是，输入通常会包含有 输入框、网址输入、特定规则输入 等多种输入方式，这些都是我们输入类组件的一个大的范围。那先来了解一下选择和输入当中的差别。往期B端设计干货：5000字干货！超全面的B端设计指南：消息通知消息通知在我们设计的过程当中非常重要，因为它作为系统与用户之间沟通的桥梁，能够帮助我们提示用户：“目前的操作状态、系统的公告、用户之间的互动内容”，而不同的消息内容，我们需要使用不同的消息通知组件来进行反馈，比如用户与用户之间的互动应该采取什么互动方式？阅读文章 > 一、生活当中 输入与选择 的差别想要理解 输入与选择 的差别，我们先来理解生活当中关于输入选择的差别。举一个生活当中的例子，图片当中的这个物体是什么？我相信大家给我的回答一定不会相同。比如：有的人可能会说是它是苹果；而有些人则会说是红苹果、红富士、大苹果 等等...也就导致虽然大家说的都是苹果相关的词汇，但是这些词语往往都会存在细微的差别。那假设同样一张图片，我们提问的方式是，图片当中的物体是下列四个选项当中的哪一个？A.香蕉 B.苹果 C.西瓜 D.火龙果这时候你会发现，得到的结果大多数都是选择的「B.苹果」而上面讲到的便是我们输入和选择的一个差异，从结果上来看我们就会发现 输入要更难一些、选择则会更加的容易。这就像我们在学生时代做的卷子，选择题往往还能动动笔，而到了填空题完全就是一头雾水。二、实际项目当中的例子这种情况，在日常的工作当中，有非常多的例子，比如在一个 CRM 系统当中，我们会有一个叫做客户类型的字段。假设最开始把它设定输入框，这时候销售将二次购买的客户录入系统当中，那不同的销售录入出来的结果完全不同。销售 A：二次客户销售 B：复购客户销售 C：老客户而数据在整个系统当中非常重要，因为我们录入数据的最终目的都是在各个地方使用数据。比如在数据分析页面、数据筛选页面，由于出现了上诉提到的混乱的结果，系统的数据无法正常使用，在管理上就会出现很多问题。假设把客户类型的字段换做是选择，那这些数据就能够正常使用，并且能够在系统当中我们就能够合理的在各个页面当中利用。三、输入与选择的定义通过上面两个例子，我们会发现输入与选择的意义是完全不同的。我们就来看看，输入与选择究竟存在什么定义上的差别。1. 录入方式上的差异输入就是提供给用户进行无规则的信息录入，也就是用户想输入什么就可以进行填写。而在输入的过程当中，通常都是通过键盘的方式进行进行的数据提交，这也就意味着输入的难度较大。选择则是系统预设好的条件提供给用户进行规则的录入，并且在组件的展示当中，都是以鼠标点击的方式来进行的信息录入，它的难度更低，但是选择在系统当中是预设好的情况，也就意味着需要提前预设。如果是一个灵活的 B 端系统，就一定需要在管理后台对于预设的系统进行配置，否则整个系统就缺乏灵活性。这就是在 飞书 的管理后台系统当中，我们需要单独的配置一些自定义的信息，其中就可以定义选择录入的选项。当然为了保证系统的灵活性，我们还会为组件去设定一些小心思，就是选择录入时，底部会有自定义选择项的功能，这就叫能够保证用户都有自己想要的选项。2. 字段属性上的差异关于两个字段，其实在字段属性上也会存在不同。首先是输入类型的字段，在整个系统当中，主要针对的是：名称、手机号、地址、邮箱 等，系统本身无法规则化的字段，这时候只能采取输入的形式。而选择字段，主要是针对的字段是：类型、属性、状态 等，用户能够快速选择的字段，两者在字段设定上存在差异，因此并不相同。四、选择与输入的作用关于作用，问大家这样一个问题，你们认为在 B 端系统当中是输入更多，还是选择更多？我想看完文章过后大家都会觉得输入的限制过多、过于麻烦，因此输入在整个 B 端系统里 录入难度高、规则复杂，只会使用在少数位置来进行使用。同样的逻辑选择则会更为高频使用。字段，其实是涉及到 前台、后台的页面信息，也就造成关于字段的影响，我们不能单纯从表单一个页面来进行看待。而表单、表格、详情页本身是一个整体，这些字段的差别，会影响到后面的页面的展示。比如在表格页面当中，会什么要采取 搜索 而非 筛选？其实这就是在表单页面当中，如果选择了输入，那在检索的时候一定是 搜索的方式。那如果是选择，那在检索的时候一定是 筛选的方式。那在其他页面呢？详情页？这个咱们就不多说了。这其实就是字段的对应关系，在整个系统当中是一个链接的整体，我们在去看待组件的时候，要关注的并不只是组件的样式，而更应该在乎的是组件背后之间的关系。如果觉得文章还不错，也别忘了点赞转发~我们下篇文章，再聊~欢迎关注作者的微信公众号： CE青年Youthce本篇来源：优设网原文地址：https://www.uisdc.com/select-field
组件 复用 场景 在上一篇文章中，我们通过实例讲述了构建和维护组件库的一些方法和思路：组件库设计指南（一）：组件库的诞生编者按：组件库该如何构建？阅读文章 > 在聊到关于持续维护组件的意义时，我们说到，组件在保证合理性的同时，还需要满足复用性、易用性，以便更好地服务于日常的设计需求。所以在组件维护过程中我们不可避免的需要考虑复用性和易用性二者之间的平衡。此时我们需要思考“如何使一个组件在满足多业务场景需求的同时，又能保证其易用性？一、关于复用性复用性是指组件具备一定的可配置属性以适用不同场景的能力。适应的场景越多，组件的复用性就越高。「可配置」主要体现在以下方面：支持通过替换内容，样式，尺寸等操作改变其状态，以适应不同的场景；支持局部元素展示隐藏，例如商品卡片的标题、说明、标签、价格等可根据接口数据控制展示逻辑；支持多种布局和排列方式，例如商品卡片的左图右文排列、上图下文排列；我们在上一篇文章中的提到的基础样式或组件，例如文字(字号、颜色、对齐方式)、颜色、图标等即是可配置属性，通过这些基础样式预设的变量，来满足各场景的需求。组件的内部元素的可控性越高，其适用的场景就越宽泛。为了满足不同场景的需求，设计师在调用组件时往往需要通过“覆盖层”设置其嵌套逻辑和样式选取，整个过程中所产生的思考与操作成本较高。但相应地，正因为「组件」高度整合了多个可配置属性和变量，组件库的整体规模会相对容易把控，结构也会相对清晰。二、关于易用性易用性是指组件对于使用者的友好程度，即组件的设计能够符合使用者的认知及需求，使用者能通过较低的学习成本、快速上手使用。我们通常需要从以下 4 个指标来度量组件是否易用：结构清晰：组件所包含的所有组成元素是否可视；便利检索：指在文档内查找组件的难易程度，通常与组件命名相关；即拖即用：单一组件用于业务设计所花费的成本；帮助可视：是否容易获取组件使用的提示和帮助。组件内部元素的可控性越低，其适用的场景就越单一。对于使用者来说，可以快速地检索、发现所需样式，并能快速完成调用，也更易于组件的认知和记忆。但要满足多样化的设计需求，所需「组件」的数量需要足够多，组件库的整体规模相对较大，后期更新和维护成本更高。总的来说复用性和易用性是优秀组件必不可少的特性，二者缺一不可，但任何一个极端都不利于构建高效实用的组件库，设计师需要明确组件库的目标并制定规划，针对每一个图标、按钮、组件、模块，考虑如何实现复用性和易用性的平衡。下面将以“Gtech UI Kit (Mob)”组件库当中的实例，来简单阐述我们对于二者平衡的思考，以及我们是如何做的。二、以商品卡片(网格布局)为例以电商 PLP 页面（商品列表）中常见的商品卡片为例，我们知道在列表中每个商品最终呈现在用户面前的内容取决于商家后台的配置。对于承载内容的组件来说，我们在维护时需要结合业务需求考虑诸多问题：例如自适应场景、商品名称的长短限制、卡片内容的布局和排列方式等等...1. 拆解 - 从业务出发，拆解组件的表达结构和所需元素如果对商品卡片进行拆解，最基础的商品卡片通常包含：背景、图片、名称、标签和价格等元素。图片通常以 1:1 的比例展示，无论在什么屏幕宽度下，均保持比例一致；商品名称通常不会超过两行，需要考虑自动布局以适应不同的文本长度和屏幕宽度；标签行通常展示 1-3 个不等，甚至没有的情况，标签组件中需预设足够多的样式支持；价格通常会展示折前价和折后价对比，或仅展示最终售价。当某一组件拆解到足够细分的时候，可拆解出多个可配置属性（即基础样式和组件）可以形成多种组合。依照这些组合，我们可以开始创建组件的工作。2. 组合 - 通用的组件的布局及可配置属性的搭建母组件建立商品卡片的基本结构和内容排列：网格布局以上图下文为主，将所有的元素设置成合适的大小，除图片外的其他内容均以名称、标签、价格的顺序自上而下展示，另外，建议标签和价格元素各自合并成组，以方便后续进行自动布局；选择所有元素，创建为组件；对于网格布局的商品卡片，我们除了一系列的自动布局和尺寸的设置外，需要注意的是新建一个空对象容器、将图片放置其中，以方便固定比例。以上我们就完成了满足上述需求的商品组件，我拆解了一下结构，如下图：按照上述操作，我们完成了一个基础商品组件的创建，我们通常称之为“复用组件”，通过复用组件我们在需求设计时可以根据实际业务场景进行替换图片、替换文字内容、增删元素或者拖拽拉伸均等操作。3. 精细化 - 从多维度，多场景输出子组件的方案和组合精细化是根据实际情况对复用组件进行细分管理，通过对可配置属性的替换，输出多个样式组合即“子组件”；子组件一般根据使用频次和属性分类展示在组件库文档内，以供使用者浏览、使用；如果需要调整某一子组件时，只需进行独立调整，无需改动复用组件，且其他子组件也不会受其影响。这种管理方式的优点诸多不一一赘述，但需要在前期整理、理解和细化时需要花费一点精力。三、思路在整个过程中，我们前期将目标进行拆解细分，中期整合多个属性变量创建可复用组件，最后通过精细化管理，尽可能的在单一组件目录下展示多个样式组合，并通过不同的菜单对其布局、类型、状态等属性进行分类，使之在使用环节能够易于检索、识别、并即拖即用，快速上手。以上是我在整理组件时的思路，抛砖引玉，仅供参考。在实际维护的过程中需要考量不同属性和变量的使用频率。并不是组件整合的属性和变量越多越好，兼容越多的属性和变量往往意味着组件的复杂度越高，对于各个场景的调整成本也越高，反而会增加额外的操作和认知成本，就舍本逐末了。再举个例子，如果设计能够在需求阶段就得知后台配置的商品名称有字数限制的情况的话，我们在创建商品卡片时，可以直接以最极端的场景考虑即可，这样也能减少试错成本，提高维护效率。所以也请大家注意，要结合业务需求和日常工作习惯，找到最适合自己的组件整理维护方案。四、易用性在前，复用性在后实际上，无论何种事物，复杂的逻辑往往是隐藏在看不见的地方，就如同我们日常接触的应用程序一样，展现在用户面前的永远是优秀的界面和体验设计，而其背后往往是开发者无数行代码交织形成的复杂逻辑。组件也是如此：在整理和维护组件的环节，我们需要考虑多种组合场景，衡量这些场景的使用频率，整合出一个或多个高度复用性高的组件，并以此精细化足够多的可供快速使用的子组件。而对于使用环节，我们希望设计师和开发者可以通过浏览设计文档、网页等方式查看所有子组件选项和使用帮助，并能快速选择业务所需的组件，减轻改造组件的成本，以实现更有效率的设计和封装工作。最后，不要盲目追求兼容性和复杂度，适合即是最好。更多组件设计干货：6000字干货！如何用 Figma 搭建系统组件库？组件库是一个强大的提效工具，对于设计师和开发来说有了统一的标准，输出的效率也会大大提高。阅读文章 > 用一篇文章，从零开始帮你用好 Figma 的组件库功能对于设计系统，我们最熟悉和常用的应该就是设计组件了，即 UI kits，包括输入框、按钮、文字、链接、下拉菜单等等。阅读文章 > 欢迎关注作者微信公众号：「Gtech UED」本篇来源：优设网原文地址：https://www.uisdc.com/guide-to-the-design-of-component-library-2
设计师 组件 功能 上期推荐了一波Figma插件，这期分享10个提高效率的实用技巧~提高200%的效率！13个腾讯设计师常用的Figma插件序言咦，同样是用 Figma，为什么同桌小花早早下班，隔壁二狗岁月静好，而你却在 Figma 中焦头烂额？阅读文章 > 一、快捷键面板｜宝典大全相信很多设计师一定看过一些快捷键操作，但是实际操作起来总是让人摸不着头脑。其实 Figma 提供了一个非常方便的功能，按"Ctrl + Shift + ?" 即可打开快捷键面板查看所有快捷键，有锦囊在手再也不用求助他人啦~二、快速填充｜“嘭嘭嘭”地填充多张图片遇到多个占位符的情况，有多少小伙伴还在一张张重复填充内容-选择图片-浏览并选择……在不使用插件的情况下，其实只要按下“Ctrl + Shift + K”选中多张图片或动图，就可以依次填充进去。三、自动布局｜界面布局的魔法想一下平常工作中遇到的高频但低效的场景，例如“做页面时删除一张图片则其它模块都需要微调好麻烦啊”、“过方案想看不同间距的样式但是一个个调整太浪费时间了”，用 Figma 的自动布局功能就可以解决这些问题，通过搭配使用等距排列、自适应变化等，你就可以完成一个调整细节就会自动影响整个界面的魔法。1. 关于自动布局使用键盘快捷键“Shift+A”即可为一个框架或选择的对象添加自动布局，同时，在右侧边栏会新增一块功能区域，你可以在里面控制自动布局框架的流动方式（选择垂直方向或水平方向的布局）、快速调节对象之间的间距。值得一提的是，自动布局非常好用的一点就是可以“套娃”，嵌套自动布局框架可以组合玩出非常多的花样，比如同个画框内同时存在垂直和水平方向的布局方向等。2. 响应式变化固定大小（fixed content）顾名思义就是“敌变我不变”，不跟随容器任何调整而变化，例如表单里面的头像和 icon；但如果是人为“天降大手”去对元素本身进行调整的话，元素依然会变化。适应内容 (hug contents) 用英文更好理解一些，去“拥抱”变化的内部，当内部是一个只能设计师调整尺寸(即固定大小)的容器，那么外部就会跟随内部发生变化。常用于容器内部包含文本段落，那么整个容器都会跟随文本变化而自适应容器大小。填充容器 (fill container)，即“填满”变化的容器，当容器是一个只能设计师操作尺寸(即固定大小)的容器，那么内部元素就会跟随容器发生变化。但值得注意的是，适应内容和填充容器只可选其一。例如表单长度根据昵称长短变化后，就不能再让表单长度去控制内部变化的适应，禁止套娃。3. 绝对位置很多设计师会遇到元素插入到在自动布局中，会按照自动布局关系自动进行排列，很难灵活调整位置，这时候你就可以绝对位置功能，使项目在自动布局中不占空间，自由定位。4. 负间距以前用 Auto Layout 的处理堆叠效果的内容非常复杂，在今年 Config 2022 功能更新后带来了负间距的功能，通过拖拽间距参数为负数即可完成堆叠的效果，效率翻倍！四、组件技巧｜组件库“瘦身”1. 变体当设计师创建组件库时，运用变体来管理组件的多种类型、尺寸、状态等，优化设计系统的层级关系，那么组件库就会极速瘦身，由原来各个形态的样式变为一个。设计师在调用时也可以更加快速地使用变体组件灵活调整为自己所需要的组件，而无需去逐个查阅组件库。2. 布尔属性布尔属性的作用在于够从设计面板中切换组件内部图层的可见性，设计师可以在着在组件中添加可切换可见性的元素，而无需对图层进行修改。设置后，在设计面板上有用于该图层的显示或隐藏的开关。3. 交换实例属性交换实例属性的作用是使用后不再需要深入图层面板，查找图层来交换实例。例如设计师可以从设计面板的属性中直接完成图标替换。五、交互原型｜实现界面可操作性Figma 最值得称赞的功能之一就是它的可交互原型，当所需页面和交互逻辑都排列好后，就可以像连线游戏一样，将页面串联起来，完成一个可上手操作的 app 啦！Figma 贴心地预置了常见操作触点、运动曲线、运动时间等。有了这些，你就不需要再切换不同的设计软件啦。下面给大家介绍原型动画中的一些关键功能。1. 触发器/交互行为触发器用于定义原型从一个框架到另一个框架的交互方式。你可以使用原型选项卡中的 Trigger 下拉列表进行设置。2. 智能动画利用 Figma 内的智能动画，设计师可以轻松地做出丰富的动画效果，例如开关的切换、tab 的平移、选择器的滑动等。简单来说，设计师只需要制作开始帧和结束帧的设计稿，利用触发器将两者串联后，智能动画会帮助设计师补齐过程中发生的动画，你也可以在这个过程中选择合适的动画曲线让你的动画更具表现力。3. 弹性动画Config 2022 的更新中，Figma 为设计师专门提供了在原型转换中的弹性动画。自带物理属性的弹性动画，让你更容易设计出更流畅、更自然的界面原型。六、Figma Tokens｜设计变量管理者推荐一款叫做“Figma Tokens”的插件，其强大之处在于可以通过可视化以及编码的方式创建并管理各种 tokens，且可以在 Token 之间做一些引用关系或是算法，让各个 Token 串联起来，甚至可以一键导出 json 给你的开发同事。下面来具体安利几个非常厉害的小技巧。1. 别名Figma Tokens 里一个非常好用的功能，你可以用这个功能对使用不同 token 名称，但却用了同一个色值的 token 做引用关系。这样，当你改动你的原始色板的时候，其他被引用的 token 都会随之发生变化。2. 使用数学在构建类型比例或间距比例时需要考虑到比例可能是有关联性的。在 Figma tokens 中，你可以引用已有的一个 token，并使用它进行一些数学运算。例如，你希望 borderWith.medium 引用 borderWith.small，但将其值乘以 2。那么，你可以将以下内容写为 token 的值: ({borderWith.small} * 2)。3. 创建渐变 tokenFigma 本身没有办法做到制作渐变色 token 时引用现有的纯色 token。但是在这个插件当中，设计师可以自由度更高的使用多个已有的纯色 token 作为被引用者。七、小组件｜Figma 工作流拓展前阵子 Figma 更新了一个小功能，FigmaWidgets，说是小功能，但其实一点也不小。利用小组件，你可以在 Figma 内做到很多之前意想不到的事情，比如上传 pdf，添加录音，计时器等等，而且是属于开放式的，所有人都可以参与到小组件的创作并上传至社区，想必不远的未来，这一功能一定会大放异彩。比如近期很火的一直跟随在画面中心的像素小人，或许你可以用它来搭建一个像素风的小游戏。使用小组件进行表态和投票。在 figma 内上传 pdf 等等等等。八、历史版本｜创作时间轴回溯不知道你是否也遇到过这样的问题，当你发现误删了某些元素，一直按“Ctrl + Z”也无法回退，其实你不必重新再做一遍这个元素，你只需要打开历史版本，找到存在该元素的版本，从该版本中复制这个元素回来就 OK 啦。九、FigJam｜灵感爆发集合地ios16 上新了共同编辑备忘录，而 Figma 早早就提供了一个丰富的协作编辑功能：FigJam。使用 FigJam 可以和你需要和你沟通的产品同学快速进行线上沟通，可以使用便利贴快捷记录下你们的灵感，并用一个大大的贴纸表示你对他的想法的赞同，更有非常多丰富的互动玩法，快快去发掘吧。十、Spotlight｜聚焦所有人视线问：设计师在阐述需求的时候，如何聚拢所有人的目光？秘诀就在你头像的下方的“Spotlight”按钮，点击后，可聚焦所有处于当前界面用户的视线跟随你移动。你在设计中是否也遇到过一些提效妙招呢？欢迎在评论区分享给我们，大家一起成为高效的设计师吧！2020年，一定要试试这 17 款超给力的 Figma 插件在世界范围内，Figma 已经作为主流的原型和数字设计软件而存在，和 Adobe XD 和 Sketch 相比，Figma 作为在线工具，有着更强的实时协同功能。阅读文章 > 全是高频神器！B端设计师常用的 7 款 Figma 插件最近打开 Figma，点击我的插件，发现我已经安装了这么多插件...我究竟要用哪一个插件？阅读文章 > 欢迎关注作者微信公众号：「腾讯设计族」本篇来源：优设网原文地址：https://www.uisdc.com/10-figma-skills
资产 需求 组件 对于 B 端数字产品来说，建立一套企业级的 Design Systems 可以提升团队生产力为企业赋能，这当中会沉淀很多设计资产（设计资产指设计体系中的所有产出物）。在有了设计资产后，如何确保使用者能够正确使用？如何维护其良性发展？如何管理设计体系资产？如何建立和谐的资产共创流程？这需要一套完善的、行之有效的更新机制。说到更新，那必然不是 0-1 的过程，而是 1+1>2 的事情。去年我们更新了设计资产 V2.0 版本，随着业务的不断发展，在使用过程中发现基础组件模式需要新的拓展以更灵活的应对业务、发现缺少了组件的应用指南、使用场景等内容以更好的指导使用者、发现图标库缺少统一的管理等问题，因此在我们做了充分的调研和分析之后，启动了 V3.0 版本的更新工作，刚开始我们仅借鉴有赞的更新机制执行更新，但在执行过程中，我们遇到很多现实性的问题，基于此，我们结合团队现状沉淀出了一套完整的更新机制，它更适用于没有专门设计体系团队的中小型团队，在此跟大家分享，希望可以启发你的灵感。在进入正题之前，我们先思考一下，为什么做项目可以从立项到最后稳定运行一步一步执行的那么有条不紊？那是因为在项目的整个生命周期中，有项目经理在利用十分成熟的项目管理知识体系，在指导每一步流程如何执行。那么同理，对于设计资产，它也是一个项目，我们借用项目管理思维去管理它，把更新流程代入到项目管理的闭环，该如何来做？下面从项目管理的五大过程来分享我们每一环节的方案。一、启动过程目的：触发开启、确定范围及周期首先我们需要在启动时明确的核心内容是：什么时候开始更新？以什么样的周期进行更新？更新的范围如何定义？1. 触发开启在项目开启前，需要决定什么时候开始维护设计资产，这个很简单，在一个发版后，就要开始思考下一版本需要做什么了，这跟项目的版本迭代是同理的。所以在开启之前我们就应该要定义好如何做准备工作，如何收集设计资产的需求，这一点是我们一开始没有想清楚，后来在执行过程中总结出来的。对于设计资产需求的收集是一个需要全员(资产建立者及使用者)参与的过程，需求的来源是每一个角色在使用设计资产做项目的过程中遇到的问题，把这些问题进行汇总记录，便形成了可能要做的需求。所以此时要有一个需求池承载这些内容，为确保大家更好的协作，我们在钉钉知识库建立了在线表格「设计资产需求池」用统一的格式提需求，让问题可追溯。2. 确定范围确定范围就像产品做需求管理是一样的，需要对大量的需求进行筛选、归纳、排序等，最终确认每个版本的需求范围。同样，针对需求池中的内容，我们是以月度为时间节点召集相关干系人（也会根据产品的更新频率动态调整为两月一次），对需求池进行定期评审，通过需求决策三角模型来决策是否转化为有效需求，从需求的普适度、拓展性和实现成本三个维度来筛选、归纳、整理需求，然后用采纳、不采纳和待定三个状态来决策是否要做，最后会根据迫切度对需求排出优先级，这样就完成了我们需求范围的定义。然后，针对范围内的需求，进行解决方案的讨论，或许是优化、或许是新增的内容，都需要对提出人的解决方案进行讨论，若方案被大家一致共识 OK，那么方案按其实现；若有人存在异议，则需探讨出更优的方案。总之，是为了得出大家共识的和更优的解决方案，这是建立共同意识的良好时机，也为后续的组件资产使用提前加深印象。3. 确定周期为了使每个人都能与设计资产的进化步调保持一致，它的更新是需要有节奏的、定期执行的。更新周期需要结合项目的实际更新节奏去定义，设计资产作为设计的指导工具，当然是不能很频繁的更新，特别对于 B 端产品来说，大部分是以业务为主，组件的更新多半是一个事后的行为，所以我们暂定的频率是月度进行一次需求评审，根据通用性、复用性这两大指标的重要程度，在组内讨论看是否需要对其更新，会先进行内部文件更新，以季度的时间节点进行一次线上更新需求的评审，以评估是否要进行线上库的更新，实际线上库是时隔一年我们发布了 V3.0 版本。二、规划过程目的：制定计划、明确分工有了节点划分，具体要做的事情该如何去做，应该存在一个流程规范，并且要根据参与角色的不同分别制定。在我们设计资产更新维护过程中主要有以下几个角色和对应要做的事项，具体为：设计共创者：发现问题、输出方案、提出需求、参与讨论、执行验收…前端工程师：发现问题、提出建议、提出需求、参与讨论、开发实现…资产负责人：制定计划、资产维护、组织评审、推进进度、全流程统筹管理…在设计资产维护过程中为确保角色之间的协作能够顺畅的进行，我针对多个角色从需求阶段、设计阶段、开发阶段三个阶段，分别定义了流程图和产出物流转图，需求阶段的流程如下：后续在我们的资产和流程成熟后，会规划把收集需求这一过程开放出去，让更多的角色参与进来。前提是我们已经在公司内做好了设计系统的推广和普及的工作，这是计划下一步要做的事情。因为在项目协作过程中你会发现，除了前端和设计之外，像产品、测试他们都有了解设计系统的需求，如在测试过程中，当他们对一些功能点的交互方式或组件的视觉呈现有疑问时，就会到设计这边来询问，或者有一些建设性的建议等，这些外界的声音我们作为设计系统的构建者应该及时收集，所以后续我们会思考如何更全面的收集需求，让更多的人参与构建。三、执行过程目的：执行工作、确认交付执行过程分为两条线，一是设计侧本地文档更新的执行过程，二是前端侧线上库更新的执行过程。1. 设计侧设计侧的执行是要及时的更新设计稿，根据每月对需求的评审，会按评审频率同步更新本地设计资产文档，也就是我们的 sketch 文档，这份文档更新之后便满足了设计组内做产品设计时可以使用完整的内容。对于设计资产文档的维护单独库对应到人进行一对一负责的，最初为了让大家共同参与进来，在基础组件库的设计时，让每个业务线的设计师单独设计，然后由负责人进行汇总，但这样受限于 sketch 软件本身，遇到一个很繁琐的问题：当组件由不同的人各自在不同的本地文件绘制后，汇总的人没有办法直接 copy 到公用的文档中一键生成可调用的组件插件（不知道使用云文档的团队是否可以直接实现多人对一个文档进行共同编辑，不用本地文档传来传去），所以最终的汇总基本是需要重设计一遍，这样就引起重复工作的问题，在经历了两次这样的流程后，我们对此进行了优化，后续改为每个库由单独的人来负责设计产出，图标库、基础组件库以及可视化组件库都分别由一人负责绘制、上传、对接、更新。2. 前端侧本地设计稿更新之后，需要前端支持进行线上库的更新，线上资产更新需要设计和前端协作完成，这时我们是通过产出设计资产平台文档前端版来进行协作的。这个文档是从使用者的角度进行设计的，按照：基础规范、通用组件两大类进行划分，其中通用组件包含：导航、数据录入、数据展示、数据反馈、其他五大块内容，每个组件元素的内容分为：实例、API 和指南三大模块，其中指南当中包含了：使用场景、组件构成、组件尺寸、交互状态等内容，是一份用来帮助使用者更好的使用组件的指南型文档。线上资产的更新频率以季度为周期（也根据业务产品的迭代频率动态调整），图标库的更新是跟随产品版本按照图标的固定流程进行更新。四、监控过程目的：发现偏差、做好验收开发过程中和完成后，需要对还原度进行监控，验证是否与预期保持一致，这里的做法跟我们项目验收是一样的，检查资产实现的质量，整理到验收文档中与前端对接优化。对于设计验收之前写过一篇复盘小文，感兴趣的可跳转查看。最后一道防线！五步提升 UI 交互验收效率（附验收模板）细节决定成败，这次跟大家聊聊项目开发中最后一个环节，也是考验细节能力的一个环节，即「设计验收」。阅读文章 > 监控过程是上线前的质量把关环节，这个过程中我们也是全员参与的，设计+前端，通过互查、自查、验收的方式对组件进行验收，这个过程也是建立共识的好时机，所以更应该积极推动每个组件干系人积极参与进来。五、收尾过程目的：发布版本、归档复盘在发布版本之前，需要编写更新记录，更新记录我们是维护了两份，一份是线上平台中展示的更新记录，主要由前端编写，内容涉及到组件具体的实现、调用替换等技术修改相关内容，较为细致。另一份是维护在钉钉公共库维护的「设计体系更新表」，此表格的内容更为概括，主要是做功能变更记录，两份文档的更新版本号是保持一致的。所有的工作完成之后，最后，发布版本。每个版本更新后，除了将更新内容同步给核心的使用者以外，还需要将设计资产更新内容进行更广泛的分享，需要主动的引导和推广团队内更多的人去关注和学习设计体系知识，才能使更多人更好的使用起来，才能使其良好且持久的运转，才能收集更多建议以建立更加和谐的资产共创流程。收尾并不是结束，而是代表新的开始。总结这套完整的更新流程是根据今年设计资产从 V2.0 升级到 V3.0 总结而来，整个思路和灵感来源有项目管理知识体系以及 Design Systems 这本书，所有知识都是融会贯通的，我们利用项目管理的思维找到了适合自己团队资产更新的流程，能够适应我们团队的自然工作流程，只有这样团队里的每个人才会具有主动性，大家对设计资产的贡献才能更加均匀。虽然在执行的过程中还是会或多或少的需要一些问题，比如按时间节点迭代不能快速的解决组件当下的问题以更快的应用、大家在业务外需要花费更多的精力参与到共创过程难免积极性会有差异、具有创新性的想法不能及时的被纳入库实现……这需要我们不断的去优化这个小而美的流程，以更好的为团队协作提升效率。流程提供的仅仅是大方向上的指南，具体的执行需要根据实际工作流程随机应变，在此把我们的思路和成果分享给大家，希望大家进行交流学习，路漫漫其修远兮，吾将上下而求索，设计的进步需要不断的反思和沉淀，需要更多的思维碰撞。总之，多读、多看、多学、多分享，步履不停……欢迎关注作者微信公众号：「做设计的小仙草」本篇来源：优设网原文地址：https://www.uisdc.com/design-asset-update
组件 状态 用户 大家好，我是 Clippp，今天为大家分享的是「组件设计」。现在有很多成熟的组件库，能为设计的规范性带来更大的便利。但作为设计师，不仅仅需要了解每个组件的样子、用在哪些地方，更需要清楚地知道组件的本质，即组件的形状、行为、状态等内在属性和设计细节，才能更深层地掌握组件设计。组件的五种属性想要全面了解并学习组件，首先要搞清楚组件具备的属性：作用：定义组件的用途和作用，明白组件用来做什么的。形状：不同形状的组件对产品、对用户分别有哪些作用。行为：通过用户点击或触摸等动作定义交互行为。状态：定义并告知用户当前的状态。语境：根据组件所属的场景考虑组件不同的用途。1. 形状通过形状的差异，我们能快速辨别不同类型的组件。在设计中，通常采用「文字与图形」相结合的形式来定义组件的形状。在设计组件时，要将形状、颜色、图标和文字等视觉元素组合在一起，并合理安排组件的层级结构。例如一个点赞按钮的设计，看起来很简单，但是如果我们结合不同的使用场景和吸引用户注意力的程度去考虑，一个点赞的组件就可以分为下面 6 种甚至更多的形状。所以在设计时，要充分地考虑使用场景和诉求，并对组件的形状有清晰的认知，在接下来的设计中需要哪种形状的组件直接对号入座，整个设计过程就会变得很明确。2. 行为行为和交互逻辑以及业务逻辑相关，会告诉用户操作后的结果。用来告知用户触发组件时的即时反馈，或者组件当前处于什么状态。3. 状态通过组件状态的变化可以告诉用户当前在进行哪一步操作，有助于用户了解组件当前的情况。常见的组件状态包括：正常状态、聚焦状态、悬停状态、激活状态、加载状态、禁用状态。正常状态(Normal)：是组件最常规的状态，也是设计师首先设计的状态，表示这是用户可以交互的元素。聚焦状态(Focus)：多用在电脑端中，表示元素已被选中。比如在填写表单时，点击键盘上的 tab 键，电脑的光标会切换到下一栏，下一栏的输入框出现聚焦状态。悬停状态(Hover)：当鼠标悬停在元素上时，元素会有状态的上的变化。另外，在移动端和 Pad 端上的组件不需要悬停状态。激活状态 (Active)：点击组件时，组件的颜色会变深，同时还会出现内阴影等效果。加载状态(Loading)：表示当前数据仍在加载中，需要等待。禁用状态(Disabled)：组件置灰状态，告知用户当前条件不满足，无法使用。4. 语境组件的用法跟随场景或环境会发生变化。即使是同一个的组件，在不同的使用场景中也可以有不同的使用方法。所有的设计元素都是相对的，它们会根据组件的排版位置、一起使用的其他组件元素以及用户的使用目的等来定义组件的用途。固定/可变：定义大小是可变还是固定。窄/宽：根据空间的宽度定义用途。层级结构：即使是相同的功能也需要根据层级结构定义组件的用法。浮动：定义组件是基于可访问性浮动还是基于滚动移动。组件的三种类型组件的类型大致可以分为三类：导航类（用于导航信息的组件）、输入类（用户输入信息时使用的组件）、信息类（用于向用户传递信息的组件）。1. 导航类组件作为导航提示或者展示信的组件，包括卡片、列表、网格、轮播、选项卡、菜单栏等组件。卡片：容纳信息最常见的方式。列表：用于对同一属性的信息进行排序，以便于识别。网格列表：用于在两列中显示卡片或信息单元。轮播：用于水平滚动而不是垂直滚动。选项卡：用于显示具有不同类型的信息。菜单：用于显示难以用选项卡显示的大量复杂层次结构。2. 输入类组件用于输入信息或做出选择的组件。现在很多组件库中的输入类组件形状都很相似，这样设计的原因是考虑到用户的使用习惯，避免使用让用户感到陌生的组件。复选框：当选择多个元素时使用单选按钮：当只能选择几个元素中的一个时使用文本字段：当用户输入文本信息时使用下拉菜单：打开菜单查看各种信息时使用按钮：用于在各种场景下输入有关用户决策的信息切换开关：用于打开/关闭特定状态3. 信息类组件用来传递信息的组件，根据要输入的信息类型来传达用户的选择。常用的信息类组件包括：指导文字：用于提供指导信息。工具提示：用于展示文字无法传达的内容。吐司提示：轻量级的提示，在提示过后通常会自动消失。警告：用来向用户传达需要清楚了解的重要信息。弹窗：向用户传达需要做出选择的内容。用户引导：用于传达用户不熟悉的页面内容。最后以上就是组件的属性和类型的解析，希望通过这些内容能帮助你对组件有更多的认识和思考。「组件系列」的其他文章，近期也会不断更新，欢迎大家关注如何构建维护设计组件库？我总结了这6个方法！原文引自 medium 上的一篇文章 Keeping Things Organized。阅读文章 > 欢迎关注作者微信公众号：「Clip设计夹」本篇来源：优设网原文地址：https://www.uisdc.com/component-design-details
容器 鼠标 组件 大概是出于对 Material 3 和 Matias Duarte 的热爱，我昨晚还是熬夜将 Google I/O 大会的 Keynote 跟了一遍，没有等来谷歌的设计高级副总裁，倒是看到了不少有趣的内容。值得关注的硬件AI 系统 LaMDA 2 越发强大了，不过真正让我感到亲切的，是用 PaLM 来命名一个人工智能语言路径模型，这可以说是非常的有情怀了。Pixel 7 系列的硬件直指 iPhone ，工业设计也越发的惊艳和高级了，而新的 Pixel Buds Pro 不仅带有降噪功能，而且续航也超过了有待更新的 AirPods Pro ：最令我想拥有的，还是带有圆形表盘的 Pixel Watch，从直觉上来说，它比 Apple Watch 的圆角矩形的外轮廓更加讨人喜欢，屏幕和表盘整体几乎融为一体的设计也颇为自然，知识 Wear OS 的实际表现还有待观望。而结尾演示的 AR 眼镜，则直接 Call back 了 演示开头的自然语言识别模型，呼应得恰到好处，只是用来演示的眼镜看起来仅仅只是普通的眼镜，不过从使用场景到演示效果，都非常合理和自然。相比于VR，AR 更加值得期待，我在 2016 年的文章《AR 可能是距离我们更近的未来》中就表达过这一点，而 Google 的探索方向也正好印证了这一点。不过整场发布会，最令我意外的东西，是全新的安卓平板，Pixel Tablet。疫情之下的产物和国内的产品策略不同，Google 在很长的一段时间以内，借助兼容了 Android 应用的 ChromeOS 的笔记本和平板类产品，直接拿下了中低端电脑市场和大量的教育硬件的订单。桌面级的浏览器和 Google 强大的云服务，搭配 Android 的软件生态，Chromebook 和 ChromeTablet 在教育市场上所向披靡，很多对电脑要求并不高的用户，在选择入门级电脑的时候，各色 Chromebook 的性价比简直是炸裂，如果你感兴趣，你甚至可以在「海鲜市场」上以极其低廉的价格买到各种 Chromebook 来尝鲜。Pixel Tablet作为平台的搭建者，Google 本身也一直是产品和服务的风向标。Google 自身的 Chromebook 系列的产品线年年更新，从最早的 Chromebook Pixel 2013 开始，一路到最新的 Pixelbook Go 和 PixelSlate，肉眼可见地可以看到 Google 对于 ChromeOS 生态的维护与推崇。Pixel SlatePixelbook Go而大屏 Android 设备，最后一次更新还是 2018 年所发布的 Pixel C，最有意思的是，这个有着独特磁吸式键盘的 Android 平板，其实是 Pixel 的硬件团队来完成的。Pixel C 之后，Google 团队开始放任厂商在平板领域野蛮生长，自由探索，直到……2020 年新冠疫情开始肆掠全球。远程工作和线上课程让平板电脑的需求前所未有的旺盛。国内一线手机厂商也在充分吸取了 iPad Pro 等热销排头产品的工业设计之后，纷纷更新或者推出了自家的平板产品线，用上次旗舰级别的芯片（骁龙870 准确来说），键盘触控板手写笔一次到位全给配上：小米平板 5 系列Oppo Pad Vivo Pad时隔 5 年， Google 决定在 2023 年再度推出 Andorid 系统的 Pixel Tablet 这一「官方指导产品」，毫无疑问是下定决心，收拢残兵，重新出发了。Pixel TabletAndroid 大屏设计我之所以如此之在意 Pixel Tablet 的发布，原因就在于，这是一个关键性的信号，那就是咱们可能要开始关注 Android 平台的大屏设计了。原因其实很简单。全新的 Material You 或者说 Material Design 3 的设计规范比起上一代更加完善，在机器学习和完善的工具的基础上，对于不同尺寸的屏幕和分辨率有了更好的支持，此是其一。Google 官方在去年发布新的设计规范和 Android 12 之后，还公布了单独针对大屏设备的 Android 12L 系统，并且提供模拟器和可供特定设备安装的系统更新，此是其二。折叠屏设备的出现，直接成为了普通智能手机（5-6英寸）和平板类设备（8-11 英寸）之间的桥梁。折叠屏手机交互不仅涉及到 APP 在常规手机尺寸和类 Pad 大尺寸屏幕上的呈现效果，而且还牵涉到不同尺寸屏幕切换以及交互状态改变等因素。在越来越多的折叠屏手机上市之后，这类需求会反向推进传统小屏 APP 做好大屏适配，此是其三。在 Android 折叠屏交互规范出来之前，微软早早地发布了 Surface Duo 的硬件，而且在 Fluent Design 的官方设计指南中，直接加入了双屏设计的规范，具体可以参看我的文章：重磅！柔性屏和双屏来啦，设计师必学跨屏设计规范我们总在期待 Next Big Thing，企盼下一次数字革命。阅读文章 > 5000 字重磅干货！设计师必备跨屏设计规范（交互篇）在上一篇文章《重磅！阅读文章 > 如果微软这个翻车前科过多的企业让你觉得不够有信心，那么来看看 2019 年苹果申请的折叠屏专利吧：iPadOS 和 macOS 在大屏界面上的协调统一，又何尝不是为 Android 的大屏设计提供一个良好的参考呢？微软和苹果在这一领域的探索，对于 Android 大屏界面设计的参考，我认为是第四个影响因素。而 Google 下定决心，放下 ChromeOS 系统的 Pixel Slate 改用 Android 系统的 Pixel Tablet 更像是官方深思熟虑后认定时机成熟。大屏设计要点去年 Google I/O 大会上发布的 Material You 算是第三代 Material Design，现在官方也会称其为 Material Design 3，或者 M3，依然是由著名的设计师 Matias 所主导，在 Google 的整个设计团队协同之下完成落地。最初的 Android 12 本身仅仅只是应用了一部分 M3 的设计功能要要素，比如说其中特别智能的「动态配色」，酸梅干超人的这篇文章当中有相对详细的介绍：零基础 UI 入门六：最新安卓规范入门解析安卓是由谷歌公司开源的，除 iOS 外的另一大手机系统，也是我们要学习规范的对象之一。阅读文章 > 而面向大屏的 Android 12 L 的发布之后，M3 的设计规范中，可访问性设计这一章节当中，也相应地添加了「大屏幕设计」的相关规范。关于这一部分的知识点，我将会梳理出相对重要的部分，更细致的内容可以前往 M3 的官网查看：https://m3.material.io/foundations/adaptive-design/large-screens/overview1、概述整套设计需要考虑到横屏和竖屏两种不同的方向，基于响应式设计的精神，采用多列布局，借助网格系统，让内容和元素可以在不同尺寸的设备上显示，并且符合人体工程学的需求1.1、响应式网格布局1-边距； 2-分栏；3-列间距随着界面尺寸和宽度的变化，网格的数量也会相应的发生变化。1.2、断点和响应式设计一样，断点定义了适合当前页面的 APP 的响应式布局。考虑到 Material Design 在总体视觉上的平衡，绝大多数的元素都尽量和 8dp 网格对齐，较小的元素，比如图标，则和 4dp 网格对齐。2、布局APP 基础布局是交互体验的基础，布局中可以承载较小的元素区域，比如卡片。1-导航栏；2-应用栏；3-内容主体；2.1、导航区域导航栏在展开状态下通常使用 256dp 的统一宽度，折叠状态下为 72dp 。使用竖屏状态下，宽度不足的时候，导航栏可以适当缩窄适配。1-抽屉式可折叠侧边栏；2-主体内容区域2.2、容器将具备关联性的元素打包呈现的方式为容器，容器氛围显式和隐式两种，但是不管哪种容器组件，都记得使用响应式尺寸，确保不同缩放状况下可读。1-隐式容器；2-显式容器隐式容器只是边缘不可见，实际设计和开发的时候都要赋予边界参数的。卡片是最常见的显式容器，通常使用显式容器是为了强化其内元素之间的关联。上面是一个错误的演示。不要在未对整体布局进行调整的前提下，简单地将包含文本的容器进行简单的拉伸。容器需要借助缩放来适应不同的屏幕尺寸。容器之间会出现嵌套的情况。在上方的案例当中，1 为卡片容器，2为列表容器，在内容主体作为父容器的情况下，内部的子容器需要使用统一的左对齐、右对齐或者左右两边对齐，而侧边导航栏中的子容器则可能是固定位置。3、组件组件需要随着屏幕尺寸和方向的变化，在填充方式、大小、对齐等方式上进行适当的变化。左-折叠纵向视图；右-展开的横向视图在缩放组件和布局容器的时候，可以根据实际情况，来考虑它们在不同屏幕上的缩放变化。比如底部导航栏变为侧边导航，原本移动端设备上的卡片容器，在大屏幕上变得更趋近于方形，从而更好呈现图片内容等等，按钮内的图标和文本可以锚定居中，横向放大的时候，也可以维持在对的位置上。3.1、直接呈现最直接的方式，始终是按照一定的比例来将原本移动端 APP 上的控件进行缩放，以适配大屏幕来使用。不过还有更好的方式。3.2、组件交换在不同屏幕尺寸下，不同类型的组件，有着类似的功能。比如之前提到过的移动端 APP 底部的 Tab 导航控件和平板上的侧边栏组件，就是可供互换的功能类似组件。而这种策略，使得 APP 大屏化之后，控件的大范围替换成为可能。又比如，移动端的列表式表单可以和大屏幕上所用的弹出对话框进行互换。两者在功能上几乎完全一样，而且在不同屏幕尺寸之下，显得足够「本地化」。下面是一些常见的可互换的组件对比列表：3.3、响应模式除了上述的缩放和组件交换的方式，还可以使用重新定位组件位置、呈现隐藏组件的方式来实现 UI 的大屏化。在涉及到较大断点和大范围额外空间的时候，可以将原本隐藏的组件直接呈现在大屏幕上。比如在移动端上通常折叠起来的菜单，在大屏幕上直接以侧边栏的形式显示出来。而在移动端上原本简单纵向排列的组件或者容器，可以在大屏幕上重新排版布局，这样更加贴合大屏的使用场景。4、设备在大屏的 Android 设备上可能会涉及到触摸板、鼠标、外置键盘、触摸手势 等多种交互模式。不同的硬件接入 Android 平板所涉及的不同交互能够很大程度提升界面的可访问性。外部输入设备通常是鼠标、触控板和键盘三种，它们所涉及的主要交互要素如下：外部输入设备的常规交互，和交互之下的通常大家所预期的行为：下面针对这些常见的交互进行详细梳理。4.1、鼠标和光标的交互当鼠标或者触控板连接 Android 大屏设备的时候，光标都应该出现在屏幕上。在没有专门针对鼠标进行优化的 Android 设备上，鼠标单击理应和触摸点击的反馈相同。当触发鼠标和触控板的次级按键（右键）的时候，会触发上下文菜单，也就是常说的右键菜单。当光标悬停在可交互的组件上的时候，这些组件应当呈现并告知用户它们是可交互的。当光标悬停于链接和图片上的时候，光标变为手型，用来强调光标下控件的可点击属性。光标悬停于文本内容之上的时候，呈现出 I 型，强调文本内容可以选中。用 I 型光标来强调选中文本的边界。当光标在不可被选中的文本上时，不应该显示为 I 型，以上为错误演示。在使用鼠标、触控板、触控笔选中文本之后，使用单一颜色突出被选中的文本，并且不要在选中区域周围显示触摸交互的控件。如果用户直接用手触摸选中文本，则需要显示触摸控件，即使 Android 设备连接了外部设备，也需要显示。在选中文本上点击右键菜单，能够呼出上下文菜单，即使是在带触摸屏的设备上，也需要如此。4.2、鼠标滚轮和触控板手势鼠标滚轮、触控板手势让大屏交互有更多可能性。当光标位于列表上时，滚轮和触控板两指滑动手势支持上下垂直滚动，注意，只有光标所在的那个列表。在触摸屏上，向上滑动，页面向下滚动。使用鼠标时候，可以通过点击拖动来选择文本和图像。使用鼠标的用户，可以通过鼠标滚动来让横向滚动的组件移动。同理，使用触控板的用户，应该可以通过双指横向滑动来滚动横向滚动的组件。4.3、键盘交互即使 Android 平板连接外置键盘的时候，设备的虚拟键盘都应该是可以被调用的。连接外置键盘之后，虚拟键盘会自动隐藏到一角。移除外置键盘之后，虚拟键盘会自动呼出。用户可以通过物理键盘的回车键（Enter），来发送信息，确认操作。用户可以通过空格（Space）来暂停和播放多媒体内容。写在最后Pixel Tablet 的出现更像是新的转折点，Android 大屏 UI 设计的需求在接下来会随着市场变化越来越多，大家又有新的事儿干了。另外，关于折叠屏设计的规范，可以参考龙爪槐的守望者所翻译的下面的几篇：Material Design 折叠屏设计指南（1）：概述折叠屏使用柔性屏幕可以折叠或展开，根据你的需要无缝扩展可用的屏幕空间。阅读文章 > 如何设计折叠屏？来看这份设计指南！最近做了HUAWEI Mate Xs手机折叠屏的相关设计，借此机会「趁热打铁」分享一手界面操作体验、适配技巧分享给大家，希望对各位设计师同学有所帮助和参考。阅读文章 > Material Design 折叠屏设计指南：完结篇本文为 Material Design 折叠屏设计指南中文版译文第三篇，超多干货建议收藏。阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/android-pixel-tablet-design
组件 玩法 此类 前言在现如今的社会中，每天都有各式各样的商战。运营设计则是至关重要的一部分。所谓运营设计即是运用完善的设计思维、产品思维和设计技能去完成视觉设计，在保证设计美感的同时，兼顾用户和产品营销的需求，达到流量多、曝光量多、积累口碑等目的。运营活动具有周期较短、业务目标明确、用户群体明确、玩法简单等特点。运营类活动生命周期较短，常在某一段时间(也可能是周期性的)，一般跟随时节热点或者运营节奏来进行。较短的生命周期给设计、开发、数据等带来较大挑战，那么作为运营设计师怎么才能做出一系列快速、高效、高质的运营设计呢？本文主要从运营设计师，需要什么样的思路、技巧？并明确哪些步骤是可以快速搞定的？哪些内容是需要精修打磨？怎么归类？怎么统一？等内容去引导大家做好运营设计。灵活把握设计思路、避免陷入程式化设计师长期处于单向业务线的设计中，往往都会有思维模式固化的特点，每做一个项目，可能需要清楚设计目标、背景、品牌定位、用户人群等等。岂不知一个短短的运营设计，哪有那么多时间去深入了解，我们要做的就是依据项目的重要程度，做思路筛减，灵活运用，了解到哪些是必要的，哪些是非必要的。我们依据项目的重要性，大致分为四类运营活动：S 级大促活动、A 级节日&平台类主题活动、B 级品类&渠道等日常活动、其他助力玩法&推广类活动等。那么接下来我们考虑以什么样的设计思路去应对这四种不同级别的项目活动。1. S 级大促活动S 级大促活动，常见的有双十一、年中大促、春运大促等。此类的活动有爆发量高、活动周期较长、促销力度大、出现次数较少等特点。那么此类活动对于无论是产品运营还是设计师都是重中之重，而且 S 级活动往往涉及到的物料输出非常多，包括各个会场、换肤、顶通等等，所以针对每个环节，我们都要做到深入了解，精细打磨。我们要做的有：1. 理解活动目标，包括活动效果目标、业务转化目标、品牌形象目标、设计影响力目标等；2. 明确目标用户，掌握用户行为特征、思想和情感需求，洞悉目标人群的特征才能实现精准的设计触达；3. 制定设计策略，包括规划设计排期、定义设计风格、设定活动符号、把控节奏点等内容；4. 细化流程，规避风险，视觉风格定好后，依据关键词，先草图绘制，进行创意联想，避免过早陷入细节，待方案确认后，再进行精细化打磨，按照时间节点，各个端口物料输出；5. 关注设计结果，总结复盘，要及时了解用户反馈、可量化数据验证，项目结束后做总结和复盘，把项目过程中遇到的问题及时列出，好的经验和方法延用。A 级节日&平台类主题活动A 级活动，常见的就是节日节点和平台主题类活动，例如春季家装节、回收焕新季等。此类活动一般上线时间为 3-8 天左右，频次相对较高，此类活动可以根据活动属性和项目特点，打造系列化运营设计，既可以保证设计质量又可以节省时间。我们要做的有：1. 规划时间、统筹归类，将一年内的 A 级活动，依据活动特征属性，进行归类整理，进而为做出系列化的运营设计做好准备；2. 确定阶段性设计风格，依据当前设计趋势结合业务熟悉，打造适合业务转化的视觉风格，包括 C4D、插画、酸性、场景合成等；3. 定义设计语言，包括设计版式、构图、色彩和字体符号等，将此类信息进行明确定义，在设计时，就可以直接使用，也不需要每次投入时间去考虑；4. 关注数据，及时总结，A 级类活动相对频次较高，所以实时的总结经验教训，为下一次活动做准备是非常有必要，也只有这样，才能使每次的运营设计越做越好；B 级品类&渠道等日常活动B 级活动，也就是我们所说的日常运营活动。此类活动一般我们打开 app，每日都会看到，常见的有福利日、品类日等主打活动。此类活动有上线周期长、频次短、营销力度小等特点，基本上一个月或一个季度更换一次、有的甚至半年或一年，基本是跟业务及品牌主打相关。此类活动的目的，一方面是为了促活、留存、流量汇聚等，另一方面是为了传达品牌理念，提升业务及品牌形象。我们要做的有：1. 深入了解品牌形象和业务属性，根据品牌规范对运营活动进行设计，B 级活动对用户来说，曝光率会比较久。所以我们在设计的时候，尽量依据品牌关键词，选择规范中的品牌色、字体、符号等内容，加深用户对品牌的印象，从而提高知名度和业务转化；2. 模版规范化、统一处理，针对于 B 级活动，做相应的模版规范，统一视觉样式，是非常有必要的。不但能提高设计效率，同时也能逐渐沉淀出符合产品调性的品牌基因，从而保持产品的一致性；3. 视觉降噪、简洁处理，B 级活动视觉避免花里胡哨，能够让用户在有限的时间内 Get 最有价值的信息，找到所得，从而实现转化就可以；4. 版本优化，迭代更新，总所周知，一个 app 要想保证用户留存和拉新，是必须不断升级和改进，那么 B 级运营活动同样也是如此，会伴随着主 app 的设计调性，不断优化迭代。其他助力玩法&推广类活动除了以上分析三种类别的活动外，我们常见的运营活动还有助力玩法和推广类活动，通常依赖游戏化手段或任务类玩法带来优秀用户体验，有领红包、领劵、抽奖、限时秒杀等形式，从而获得成功拉新转化的一类活动。此类活动有运营感强、行为体验丰富、流程触点多等特点。另外此类活动对产品运营和交互设计的要求比较多，需要对玩法策略和交互逻辑有清晰的设定，那么作为运营设计师我们需要怎么做呢？我们要做的有：1. 参与策略制定、提出创意想法，针对玩法推广类活动，在设计前期，我们一定要参与策略制定，能够将自己的一些设计创意和灵感，融入到活动中；2. 了解玩法逻辑，强化设计价值，当设计玩法确认后，我们一定要配合交互设计师，对玩法中的每个流程逻辑，要有清楚的了解。并对每个流程页面中的内容进行层级分析和强化处理，包括利益点、文案和激励机制等；3. 市面设计分析，融入自身创意，在开始对活动进行设计的时候，我们首先要对此类玩法市面上的设计进行收集整理，吸取别人的优点，同时将自己的创意融入，最终做出更好的玩法设计；4. 案例整理，提高复用，当我们做完一系列的玩法活动时，要学会对其进行整理，做成通用模版，从而提高设计复用性，降低设计成本。综上所述，对四类活动进行了一些设计思路分析，其中的思路方法也不是一成不变的，有些点是互通的，这就在于设计师在设计中要学会灵活把握，找到快速有效适合自己的方法，只要有了清晰明了的设计思路，我们做设计的时候才能达到事半功倍的效果。运营物料规范制定众所周知，运营设计师的需求内容有专题页、详情页、H5、Banner、闪屏海报等等，分别对应不同的设计要求。我们在运营设计的时候，在输出物料上花费的时间是非常的大。所以运营设计物料做统一性的规范标准是非常有必要的。一般来说我们针对运营物料，需要明确规范的有尺寸大小、图文结构、字体字数、配色、元素等内容；用一个项目实例来具体说明一下：为 58 同城本地服务运营活动入口的 banner 图，涉及到 APP 和 PC 端。当我们已知素材和文案内容后（如下图左），我们就可以制定其版式结构，包括尺寸大小、字号间距、主视觉等内容（如下图右），那么我们每次设计的时候，只需要更改文案、主视觉和配色即可。以下两张图是按照 banner 规范做出来的效果：另外再举个例子，就是我们的活动页面设计，常见的页面信息结构：首屏+副屏，首屏：主副标题+氛围图，副屏：模块平铺/叠加，我做设计之前就需要对页面中的内容进行布局的规范化，包括位置尺寸等等，有助于我们更清晰的表现画面内容和层级的划分，如下图所示：组件化降低设计成本对比设计规范来说，组件库更像是一个强大的工具库，是提高工作效率和保证团队协作一致性的基础。组件库作为设计系统的一部分，在运营设计过程中设计师可直接调取，组合构建出新的页面，通过组件库带来的价值主要体现在三个维度：1. 设计一致性当我们使用统一的设计模式和组件库，能够在保持基础体验一致的同时，针对业务特性做差异化设计，给用户带来一致体验和品牌感知。在团队中有新成员加入时，也能够快速上手工作。2. 提高设计效率我们做运营设计的时候，总会使用到相同的元素和组件，通过组件库的调用能够减少重复性设计时间。当组件设计细节有改动时，只需要改动组件库，所有共用组件库的页面即可实时响应。针对新的业务线也能够快速进行页面搭建，实现设计效率的提升。3. 高效协同我们在进行运营设计的时候，可能会涉及到产品、开发及数据等人力侧的支撑，组件库能够随着业务发展不断的优化和完善，在不同的需求和各人力侧之中，能够灵活支撑页面内容进行延展和扩充，从而实现全链路、多场景的高效协同。以下是我们在做 58 到家的家庭服务运营设计中，部分的组件样式，包括服务列表、弹窗等等。在组件库的构建过程中，我们需要整体思考，明确组件化的设计内容，不断去优化和完善组件细节，包括设计原则、应用场景以及拓展性等。同时组件库需要根据产品的发展不断迭代和创新，才能让它的可持续性特性发挥至最大。写在最后设计行业是一个不断发展、推陈出新的行业，新的风格和形式层出不穷。而随着互联网和人工智能的发展，运营设计也在大的时代浪潮下产生着变化。我们需要在新的维度上进行思考，充分调动用户的感官，用更具有创造性的思维完成设计表达，在更丰富的场景下实现多通道的感官设计，创造更新鲜的体验。设计师需要不断学习和成长，为设计行业注入新的活力。以上是个人在运营设计中的一些经验总结，从设计思路、物料规范和组件化三个方面进行了论述，不足之处请多包涵，同时篇幅有限，关于运营设计的内容无法一次详尽，欢迎大家一起讨论。设计师应该懂的运营基础知识由销售演变成运营在我看来，当今互联网行业的经营实际上与传统行业的销售并无区别，我们可以从以下两个行业的业务结构图看出，互联网行业的经营实际上是从传统行业的销售模式转变而来。阅读文章 > 欢迎关注「58UXD」的微信公众号：本篇来源：优设网原文地址：https://www.uisdc.com/operation-design
功能 团队 组件 前段时间 Figma 的事闹得沸沸扬扬，身边很多设计师和团队都打算放弃这款软件，毕竟数据存在他国云端，谁也不知道这柄达摩克利斯之剑什么时候落下。但用惯了 Figma，想再投 Sketch 的怀抱非常难，Sketch 的问题太多了：修改无法实时同步，多人协作效率极低；无法一站式完成设计工作，需要在多个软件里切换只有 Mac 版本，内存占用大，崩溃是家常便饭所以这段时间优设也一直在搜罗可替代 Figma 的国产软件，这不，今天又发现了一款能与 Figma 媲美的一站式设计协作软件 —— Pixso。Pixso 隶属于上市公司万兴旗下，你肯定听过这家公司的诸多产品：墨刀、MindMaster、亿图图示等，特别是墨刀，是风靡一时的原型设计神器。而 Pixso 作为万兴这两年的扛鼎之作，无论是功能完整性还是使用流畅度上，都能与 Figma 过过招。Pixso网站链接：https://pixso.cn/九大功能亮点本土团队出品，全中文界面！实时在线协作，高效反馈效率倍增三大平台任意切换：Mac、Windows 和 Web 随开随用，截至目前是国内唯一一个能同时支持导出 Sketch、Adobe XD 和 SVG 的软件。从原型、交互、UI 到交付评审、版本管理、视觉资产管理全部集成在一个平台，一个软件就可以搞定所有设计工作。自动布局、组件变体、全局样式、矢量网格等实用功能应有尽有实时云端自动保存，无限历史版本回溯，再也不怕改回第一稿1000+设计组件、30000+精美图标，海量设计资源任意取用支持企业私有化部署，提供高级定制功能，团队使用更安全更稳定Pixso 承诺：个人用户永久免费使用！接下来我们详细聊聊，以上的亮点功能有多好用。至少提升 80%效率的「团队实时协作」全中文界面无需详述，你只需要知道，以后不用再担心网络卡顿了。如果你之前没用过也没关系，官方贴心准备了一份用户使用手册 https://bos-pixso.feishu.cn/docs/ ，从 8 大方面帮你完整学会使用 Pixso。当然，如果你之前用过 Figma/Sketch，不用看手册也能直接上手，之前习惯用 Figma 的同学，现在也可以直接导入 Fig 文件，目前 Pixso 的 Figma 文件导入功能已达到商业可用的级别：支持导入包含 10W+ 图层的超大文件，导入数据不丢失，可以 1:1 还原文件中的组件变体、原型交互等，确保从 Figma 到 Pixso 的文件迁移做到无缝衔接。已经有不少设计师实测过，导入速度非常流畅。但我想着重聊聊的，是「团队实时协作」功能。疫情当前，很多团队都实行居家办公，这时用上 Pixso 的团队，面对一个复杂的设计项目，不再需要等主视觉完成后再进行子页面设计，在 Pixso 完全可以多人云端协作设计，彼此互不干扰。同时还有 4 个惊喜细节：观察者模式：直观了解设计师的工作进度和内容在线评论功能：给设计提意见只需要一个链接，跨部门沟通一分钟完成！无限云端空间容量：目前注册独享福利，传多少设计文件都不怕！无限协作人数：同样是目前注册独享福利，不花一分钱可以直接团队用4 大 UI 设计利器大家最关心的肯定还是，这款软件的设计体验能否与 Figma 一战。如果说团队实时协作提高了沟通效率，那这 4 个功能就是实实在在提高设计效率的利器。自动布局顾名思义，无论是增加还是减少界面，Pixso 都会自动适应，类似于观看响应式网页般丝滑的体验，设计师再也不用因为文本框过长，一个个修改组件了： .video_pc { width: 100%; height: 585px; } @media (max-width:767px) { .video_pc { height: 50vw; } }当视频无法加载时请刷新页面，或前往PC获得最佳体验。至于全局样式，那更是设计师期待已久的功能。以前界面完成后，如果上级说配色不对，得重新改，一个个组件都去修改极为耗时。有了全局样式，一键搞定： .video_pc { width: 100%; height: 585px; } @media (max-width:767px) { .video_pc { height: 50vw; } }当视频无法加载时请刷新页面，或前往PC获得最佳体验。当然，组件变体功能也是 Pixso 的拿手好戏。有了组件变体功能，就像这个视频里演示的那样，改变卡片的样式仅需在右侧面板选择序号即可，任何组件都可以实现一键切换样式，非常方便。 .video_pc { width: 100%; height: 585px; } @media (max-width:767px) { .video_pc { height: 50vw; } }当视频无法加载时请刷新页面，或前往PC获得最佳体验。在平时绘制界面上，矢量网格也能派上大用场，这个功能相比 Sketch 和 PS，简直是碾压级的好用？相信我，看完演示视频你会回来下载的： .video_pc { width: 100%; height: 585px; } @media (max-width:767px) { .video_pc { height: 50vw; } }当视频无法加载时请刷新页面，或前往PC获得最佳体验。从交互到交付，全都帮你准备好了！得益于墨刀的深厚底蕴，Pixso 在原型制作上毫不逊色专业的原型制作软件：支持添加页面交互、原型播放等，也就是说，产品经理和交互设计师都能用这款软件完成对接协作。而设计完成后，交付流程更是让我大开眼界：Pixso 拥有自动标注功能，标注会按更新的设计稿自动生成，研发可以自动获取代码并复制，设计师只需生产一个图标，研发就可以直接导出多倍图，大大提高工作效率。关键是，这一切不需要上传下载，只需要一个链接通通搞定。无限历史版本保存，告别杂乱桌面当你还在为桌面数不清的文件夹发愁，为文件命名想秃了头，Pixso 早就帮你解决了这个问题：实时云端保存，每一步都不会丢失无限历史版本，支持任何版本回溯改回第一稿也就是一分钟的事：海量设计资源在线免费领！除了刚刚提到的 30000+精美图标素材，Pixso 还集成众多大厂优秀的设计体系（华为、腾讯、阿里、字节、京东、饿了么、滴滴等），上手直接用，和大厂高手肩并肩。同时团队可以共享一套资源库，统一管理设计资源，并形成产品独有的设计规范。最后提一下，有的设计师担心国产软件技术积累不够，使用体验不够丝滑。对于这个问题大家尽可放心，Pixso 采用的是和 Figma 相同的 WebAssembly 技术，而且依托万兴强大的技术研发团队，产品的迭代速度也排在了国产软件的第一梯队。如果你在使用中遇到任何问题，也可以直接在右下角和开发团队反馈。用心做好产品，真诚做好服务，这大概就是 Pixso 最打动人的点，也是我推荐给大家的原因。本篇来源：优设网原文地址：https://www.uisdc.com/pixso
组件 产品 系统 最近互联网行业迎来很多波动，企业在裁员的同时，也带来设计趋势的变化。造成了越来越多的 C 端 UI 设计师想要来淌 B 端体验交互设计这趟浑水，出现了很多设计师在观望，想要入局？但又不知道，应该如何学习？这里推荐五个快速学习的方法，能够让你理解 B 端设计入门知识。阅读书籍虽然读书在很多时候会被嘲笑为效率低、内容过时。再加上 B 端设计，放眼望去国内真正值得阅读的书籍其实并不多。其原因主要是在国内，界面设计的传播，很大程度上是源自移动互联网的普及，也就造成了我们对于桌面端的设计理解非常欠缺。这时候不妨把视野放大，去看看国外的设计书籍。这里推荐几本较为经典的书籍，能够帮助大家快速入局。《决胜 B 端》虽然这本书主要是为产品经理写的一本书，但是里面的很多内容也同样适用于 B 端设计师。谁叫 B 端设计师就是半个产品经理呢？建议大家可以去阅读这本书的前五章，书中讲清楚了关于 B 端与 C 端的差异，同时你可以站在设计的角度，去思考他们之间存在的差异《WEB 界面设计》虽然这本书的 “年事” 已高，但是也不妨碍它里面的内容值得大家去阅读。正因为国内桌面交互设计书籍的欠缺。也就导致了我们只能够多去看一些国外书籍。当然里面的案例是非常久远的，需要小伙伴们根据书中内容，结合自身产品去思考对比。《WEB 表单设计》表单是 B 端产品当中非常重要的一个环节。如果做过比较系统的小伙伴就会知道。一个系统当中如果不包含任何的数据，他就如同人们只有外面的躯壳。而没有灵魂。大家可以想一想，你再去试用一个低端产品的时候，你根本不知道这款产品的用途究竟是什么。因此在低端系统当中，表单的设计非常重要。如果你设计好了表单，也就意味着你的系统已经非常成熟。因此他可以认真的阅读这本书。去了解表单背后设计的逻辑。他不光是简单的信息排列组合。里面会涉及到不同字段的真正的用途。上面这些书籍就不做过多的介绍，都是一些经典好书，看名字就知道它究竟是用来做什么的。组件用法在你阅读上面的基础书籍过后，便可以深入了解 B 端产品的组件设计。因为从原子设计的理论来看，B 端产品就是由原子、分子、组织、模板、页面所组成，而组件作为我们设计当中的基础单位，等于说我们了解了组件的使用，就知道 B 端设计的基础原理。在组件的设计过程当中，我们可以通过目前较为成熟的设计系统去窥探一二，这也是建议很多零基础的小伙伴需要去认真阅读的内容。这里建议初学者可以多看国内较为出名的三款设计系统：Ant Design、Element、Arco Design从设计师视角，聊聊 Ant Design 设计体系的建设Ant Design 设计体系本文的主题叫做 Invisible Design System，隐形的设计体系，主要是想和大家分享，我们对可见的设计体系背后隐形的设计规则的思考，以及如何通过设计工程化的方式，让这些复杂的规则可用而不可见。阅读文章 > 字节跳动全新发布！ArcoDesign 设计系统正式开源https://v.youku.com/v_show/id_XNTgxNjA2OTQwNA==.html?spm=a2hcb.profile.app.5~5!2~5~5!3~5!2~5~5~AArcoDesign 是什么？阅读文章 > 并且在每一个设计系统里面都有对应的设计资源的分享、设计组件的解析、以及设计原则的确定，能够让你了解到在之后的工作当中，我们究竟需要去做哪些设计相关的事情。当然，很多人在了解设计系统时，其实是较为茫然的，你可以通过这样两种方法，去对设计系统进行简单分析：对比法：在阅读不同设计系统之间的设计组件规范时，通常你会感到非常的迷茫，比如在设计原则上，很多小伙伴不清楚多个设计系统之间的差异，当你对某一类型的规范产生疑惑时，这时候可以打开各大设计系统，去对比他们之间存在的差异，这样你的理解会更加的深刻。思考法：思考为什么他们之间会存在差异，是服务对象不同？还是产品规模差异？对于他们的差异，一定要知其所以然。不然简单的对比只是一个笑话。当然并不是了解了组件，就会知道应该如何设计，还记得我们刚才说的原子设计？我们还需要了解具体组件，如何在页面当中进行使用。组件落地当你了解完组件过后，你对整体的设计就有了初步认识，但真实的工作当中，你会发现组件只是设计当中一小部分，除了组件之外，我们还需要去理解整个组件在页面当中存在的意义，这样你才能够对组件有一个全方位的认知。建议大家可以将每一个组件进行截图，然后在真实落地的产品当中，去寻找一到两个案例。试着通过页面的分析，让你理解到在这个产品当中，组件究竟存在于哪些页面当中，它为什么要这样设计？如果让你去设计会有其他的设计结果吗？通过组件的页面分析，能够让你快速理解在真实的工作当中，这个组件究竟是如何使用，你可以考虑一下如果是你，你会怎么去做。页面临摹页面临摹，一定是设计师再熟悉不过的一种方法。通过临摹，你能够确定阅读的具体宽度与内容，让你对整个产品的页面布局有初步的认知。就像移动端设计一样，我们 B 端产品的页面布局也会存在一些固定的设计模式，通常情况下 B 端产品不要去标新立异，所以了解页面的设计模式就显得尤为重要。关于临摹哪些产品的页面，我这里也会有一定的建议，可以尝试：“Coding、飞蛾” 两款研发管理的工具产品。关于两款产品的截图，已经为大家提供了截图版本，感兴趣的小伙伴可以附件下载 “测试产品截图” 。前后台推导其实在我看来，很多 C 端转型 B 端的设计师，缺乏的是对于 B 端产品的理解。分享一个案例：大家对站酷这个网站应该非常熟悉吧？假设现在让你去设计站酷的后台文章管理系统，如果是你，你会怎么做？在对课程的授课当中，其实就会发现，很多人能够合理的运用各种各样的组件，但是在组件的选择当中，往往缺乏前后台关联的思路。因为对于一个 B 端产品来说，系统当中每一个字段信息都会有在系统当中存在的意义。而我们 B 端设计，真正目的不在于将几个信息联合、分组。如果你不明白这些信息出现的前后关系，对于系统而言，是不具备任何价值的。由此我们可以通过前台页面，尝试着分析后台产品的具体内容，这样能够帮助你进行很多联动的思考，让你的设计不会在评审时受到多方面的质疑。最后说说虽然目前网络上信息非常的多，但是很多刚入行的同学切忌好高骛远，先要了解基础的设计模式才好为后续的设计铺路，关于基础的 B 端设计，后面还会给大家带来一系列的分享，也希望小伙伴们能够利用好有限的资源去更好的学习。我是 CE 青年，一个 2B 行业 的 2 B 设计师从6个层面，帮新手快速入门B端设计系统什么是设计系统？阅读文章 > 欢迎关注作者的微信公众号：CE青年交互设计 文件名 如何下载使用 文件大小 提取码 下载来源 测试产品截图34.3MB8866 点此复制 登录下载 本篇来源：优设网原文地址：https://www.uisdc.com/tob-design-getting-started
干系 组件 项目 在日常工作中，大家是否都会遇到一些事情或者一些项目的推进，需要其他人甚至是其他部门人一起协作帮助。有些比较“亲切”的同事，会很认真听，边听边赞同你的想法真棒，让你感觉似乎你已经接近了成功，但是后续你向他要产出，他跟你说没时间，没做。此时你充满了无奈又全都是无可奈何。或者有些不太好沟通的同事，直接对你的消息已读不回，你又无可奈何。举个真实的案例：小 B 是酷公司某产品的推广负责人，对该产品的流量和转化负责。小 A 是一位设计师，发现了该产品的使用体验很不好，但是又是一个很重要的产品。他预判，从该产品入手做一些优化改版是一件杠杆很大的事情。小 A 自己搜集了一些资料，做了一个初步了解，然后给出了一个初步解决方案，就约了小 B 沟通。过程中，小 B 很支持，并且对小 A 表示感谢，双方也对未来一些产出内容和产出时间节点达成意见一致。N 天后，小 A 在企信上问小 B 做的咋样了，明天就到时间了，约个地方碰一下吧。小 B 说最近比较忙，都没开始做。小 A 很无奈，但是又无可奈何，该项目最后不了了之。小 A 是一个好设计师，工作之余主动发现问题，并且主动尝试去落地解决问题，但是为什么最后没成功？小 B 做错了吗？他可能真的一直在忙自己原本规划的事情，真的没有时间跟你一起去做这次改版。那么，到底问题在哪儿呢？本次课题以跨部门沟通为主，侧重“如何说服别人跟我一起干”这一方向，通过体系化的学习和分析，识别职场中频繁发生这一现状的本质原因，以及有什么手段，能够在今后的工作过程中尽量避免这一现象的发生。本质沟通的本质是“双赢”。当你开始一场跨部门沟通协作的时候，先想想自己能够给同事带来什么，就算是别人的本职工作，你也应该多考虑自己能够做点儿什么来触动对方。有时候，我们没有办法去要求同事完全按照我们的想法去做事，我们却可以通过沟通，让同事心甘情愿帮我们去做事，而“双赢”就是最厉害的武器。跨部门沟通协作障碍要实现双赢，跨部门沟通协作涉及的因素有很多很多，比如权力、利益、责任、目标等。而且，在职场上，凡是牵扯承担责任、或者互相之间有利益冲突的时候，每个人都会本能的想：这事对我有好处吗？我值得投入做吗？会不会要我背锅了？影响跨部门沟通的 5 大因素：目标不一致，无法说服对方与你一起干；利益不一致，对方没有动力与你一起干；责任不明确，可能出现甩锅现象；流程即合作过程的方式，没有共同确立一个好的合作方式，有可能花了时间效果不佳；找错干系人，可能会让你推动项目时无法得到最有力的资源；这五大障碍中的任何一项没有处理好，都可能导致沟通失败。只有在沟通前做了充足准备，对这些影响因素都有了规划和解法时，才可以找别人进行沟通。方法基于上面总结的 5 大影响跨部门沟通的因素，我重新梳理了各因素之间的关联关系，总结了自己的方法，希望能体系化的将“跨部门沟通-如何说服别人跟我一起干”形成一个可复用的方法模型。1. 提前思考好我们推进该项目想要最后达成的目标是什么；2. 提前识别干系人是谁。干系人通常是指项目组内部成员，也包含公司内部的领导或者其他项目内部成员；如图所示，权利/利益矩阵是根据干系人权力的大小，以及利益对其分类。这个矩阵指明了项目需要建立的与各干系人之间的关系种类。首先关注处于 B 区的干系人，他们对项目有很高的权力，也很关注项目的结果，我们应该“重点管理、及时报告”，让 B 区干系人满意。其余的 ACD 则是按图示的方法去管理。3. 要让合作方认可我们的目标，并且愿意跟我一起干，我们得分析合作的共同利益在哪儿，用利益捆绑责任，用角色划分流程；了解对方 OKR，找准对方想要什么，建立共同利益诉求点，把我认为重要的，也让对方认为重要，这一步至关重要。在双方都认可，有真实合作意愿后，共同分析合作过程中是否有阻碍因素，资源有哪些，各方负责的职能范围是什么，用利益去捆绑各自的责任，并且在节奏规划，关键节点的内容产出都达成共识，建立合作流程的意见一致。4. 过程中注重额外的情感沟通及心怀感恩之心；除了正常的工作合作交流，也可以尽可能创造其他非正式交流的机会，建立更信任的合作关系，比如一起约个饭，一起喝个下午茶。并且怀有一颗感恩的心。无论对方是否是份内的工作，无论对方动机是什么，他给了我帮助，我们就要认下这份人情，并且在适当的时机下进行回馈。我的实践项目：MUYA 复杂组件的落地推进；目标：创建 MUYA 复杂组件库，通过复杂组件的利用，提高设计和研发效率，统一产品规范；干系人：小 A：MUYA 组件库项目负责人；小 B：业务线前端负责人；沟通过程：1.分别了解小 A 和小 B 的 OKR。小 A 是 MUYA 组件负责人，除了基础组件外，他还负责组件落地到业务中，即我发起复杂组件项目能与他的 OKR 绑定。小 B 的 OKR 有对研发效率提升的目标，即业务组件项目与他的目标不谋而合。2.既然已经识别了他们俩是我推进项目的主要干系人，并且该项目与协助他们完成 OKR 起到了正向帮助。我分别与他们先进行了线下沟通，用当前存在的问题以及我提供的解法向他们表明我的计划和目的。用该项目能带来的价值和收益说服他们，分析能带给他们各自的价值点，用“双赢”将我们捆绑在一起，分别确立我们就是研发和设计的负责人。3.召开复杂组件项目 kickoff 会议，叫上所有干系人。确认了一期要做的所有内容，各自的职责，对应的节奏和时间节点。结果和进展：复杂通用组件和业务组件都分别进入了两个前端组各自的 SP，稳步迭代中，计划 2 月完成一期所有复杂组件内容的开发。复盘1. 项目干系人管理中，没有很好的识别各类干系人。比如我只找到了 C 类干系人，却忽视了 B 类这一最重要的干系人。所以在项目初期，小 B 遇到困难存在情绪时，我有点推进受阻，一时不知该怎么办。2. 我的 mgr 也是我推进项目的一个重要资源。她帮我识别了最重要的 B 类干系人应该是两个前端组的大 boss，mgr 帮助我与该 boss 进行了沟通，让我的项目能够得以继续顺利进行。3. 在情感沟通层面我也做的一般，没有找到其他非正式途径去深入沟通，这块可以做的更好。结语跨部门沟通是一门很深很难的学问，需要我们有更多的实践和经验总结。用我归纳的「跨部门沟通法」也许可以帮助初期的小伙伴进行简单的跨组沟通协作，了解一些基本的方式方法和注意事项。如何在设计中构建共情？收下这份6000+的干货总结！编辑导语：同理心对于任何人来说都是难得可贵的，它在人际交往中有非常突出的优势。阅读文章 > 欢迎关注公众号「酷家乐用户体验设计」本篇来源：优设网原文地址：https://www.uisdc.com/cross-department-communication
组件 变体 样式 组件库是一个强大的提效工具，对于设计师和开发来说有了统一的标准，输出的效率也会大大提高。随着设计工具的不断发展，Figma 逐渐成为各大公司的主流设计软件。Figma 强大的组件库能力，非常适合团队设计系统的建设与应用。相比 Sketch，Figma 在 Auto layout、变体和实例等方面极大的提升了组件库的设计灵活度和效率。看完本文你将会学到：1. Sketch 与 Figma 组件库的区别2. Figma 组件库搭建经验分享基础样式：字体（分层分级技巧）、颜色（分组排列规则）、阴影（分类、三层阴影）等组件与变体：组件分类结构化原则、变体创建命名技巧、优化变体层级、组件预览展开还是合并、开关的使用和组件的链接等组件文档：文档结构层级组件库发布、使用、更新3. Figma 组件库搭建 Tips 分享先简单聊一下为什么要做组件库？组件库是将界面设计中的具有通用性和标准规范的基础元素和重复出现的控件进行归纳整理，通过对控件进行分类和命名，最终形成一个可快速复用，便捷维护的资源库。对于设计师和开发来说，简单上手，可复用强，稳定且高效的组件库是非常有必要的。组件库更像是一个强大的工具库，既能提高团队的协作效率，也能保证团队设计输出的统一性、高效性和延续性。相对 Sketch，Figma 组件库有哪些特点？在 Figma 之前，我们都习惯了用 Sketch 创建组件库。但当开始使用 Figma 后，发现 Figma 不仅继承了 Sketch 组件库的优点，并且更加灵活和强大。举一个简单的例子，如果想要修改组件的文本样式或者不同组件的颜色时，在 Sketch 中，就必须提前做好所有可能的文本/图层样式，非常的费时费力。但 Figma 强大的实例 Instances 功能，无须提前做好所有的样式，可以直接在实例上修改字体、颜色、描边、投影等，但又不会干扰到父级的样式，而修改父级的样式又能修改全局，非常的方便。又比如想要去切换一个按钮的状态，或者是否带图标时，Figma 强大的变体功能可以将这些属性进行分类整合在一起，组件调用更便捷，这都是 Sketch 组件不具备的功能。除了实例、变体功能外，跨团队使用组件库（样式、组件）、实时更新、组件库的主题颜色一键切换、组件可以增加提示语等功能，都是 Sketch 不具备的。Figma 组件库搭建提到组件库，不得不提到原子构建理论。Atomic Design（原子设计）是构建 Design System 的核心指导理论。化学中，所有的物体都是由原子构成，原子组合构成分子，分子组合构成有机物，最终形成了宇宙万物。上万字干货！设计师必读的原子设计完整指南「我们不设计页面，我们设计构成元素的系统。阅读文章 > 2013 年 Brad Forst 将此理论运用在界面设计中，形成一套设计系统，包含 5 个层面：原子、分子、组织、模板、页面。那么对应设计系统来说，我们的颜色、字体、图标以及按钮、标签等都会对应到相应的原子和分子，通过组件之间的搭配组合，最终构成页面。组件库的基础构成按照原子设计理论的思路，首先需要将组件库的类型进行分类，然后再从基础和核心的元素入手，进行元素、组件、模块的搭建。组件库一般由基础样式、控件和组件文档构成。基础样式包括颜色样式、文字样式、效果样式（主要是阴影），组件主要就是控件（相当于 Sketch 的 Symbols），组件文档相当于对组件的样式和状态的展示说明。1. 组件库：基础样式搭建我们可以直接在文档里创建样式库，简单且灵活。当然更建议大家单独创建一个全局样式的文件，包括颜色、文字、效果等，这样做的好处是在以后进行项目切换时，可以很方便快速的进行配置和替换，且可以共用一份原始的组件，高效且有关联性。这里要跟大家提一个概念 Design Token。Design Token 是存储样式值（如色值、字重、阴影、圆角等）的载体。Design Token 最重要的意义是做到设计与研发的样式完全打通，进行无损耗的沟通，增强系统的可维护性，同时可以约束设计侧的样式数量。但是 Figma 本身对 Token 的支持不够全面，比如圆角等，所以需要自研插件来弥补这些不足。全局样式：颜色样式颜色是页面整体风格表现的重要基本元素，它可以建立品牌的识别性，梳理页面的视觉层级关系，突出内容并平衡其他视觉元素。建议大家可以按照功能和属性，将颜色进行分组分类命名，比如主色、浅主色、中性色和功能色等，并将默认、悬浮、点击、禁用等颜色放在一组，方便大家使用。全局样式：文字样式在文字样式中会包括：字号、字重、行高和字距等。在创建文字样式前，将文字样式分为段落样式和文本样式加以区别。将产品内的一些文字梯度以及功能描述等用表格的形式进行整理，并分别创建相应的字号和字重。需要注意的是不要单纯的将名称命名为 T0、T1 等纯符号性的名称，可以在后面加上适当的描述，比如 T0 辅助、T1 标准等文案，同时也可以在描述里添加对应的使用说明，这样当鼠标悬浮在这个样式上，会给用户带来提示性的预览。这种办法同样适用于颜色、阴影等全局样式，会更加方便大家调用且能够很好的解除新用户的使用疑虑。全局样式：效果样式效果样式一般来说主要是常用的阴影样式，比如外阴影、内阴影等。阴影值应该遵循现实物理世界中物体的特性。因此在阴影的设定上采用了三层阴影的表达方式，让阴影更加柔和，更符合真实光源下的物体状态。物体的高度直接影响阴影，离地面越高阴影越大，模糊值越高，反之相反。同时，为了让组件库阴影层级更加丰富通用，我们将阴影层级划分了 S 类和 L 类两个层级。S 类阴影用于通过交互后出现的场景，其内容带来上下文信息切换，需要抢占用户注意力，更需要提供明确的边界，主要用于基础组件。L 类阴影往往用于多个共存的列表，更加强调整体的柔和性，主要用于导航、首页、模版等业务场景。同时为了能让大家更加清晰的区分阴影的层级，会将常用的一些组件和场景填充在一个表格中，方便大家查阅。2. Component 组件Component 组件相当于 Sketch 的 Symbol。不同之处在于 Component 比 Symbol 更灵活更强大，我们可以用更少的组件做更多的事情，接下来会通过以下几个方面来简要介绍一下 Figma 中组件的相关知识。Auto layout：创建组件能用尽用Auto layout 是 Figma 非常强大的一个功能，创建带有自动布局的组件，通过组合这些响应组件，可以创建可跨多种设备类型工作的设计。在创建组件的时候，一定要把这个功能很好的应用，这样对于组件的拓展和应用会非常灵活。比如常用的按钮、对话框、Toast 等等组件，能用尽用。组件结构化：寻找操作更容易结构化的基本原则是：方便检索控件（Components）、方便编辑控件、清晰地传达控件分组和状态。建议在团队或公司中定义好组件的结构，可依照自己相关的业务，将一些通用性较强的基础组件进行划分。将组件按照属性和状态放在不同的页面里，而不是将所有组件全部堆叠在一个页面。比如数据输入类下面，将常用的输入框、单复选、上传等放置到一起，这使得以下操作变得更容易：在资源面板中查找组件、相关组件之间的交换、提高公司内团队资源库的使用率。强大的变体功能：构建组件库的灵魂和精髓谈到组件，不得不提到 Figma 强大的变体功能。用户可以通过变体功能更加方便和灵活的调用组件库，这相对于 Sketch 来说，简直是好用太多。当你创建组件并建立起你的设计系统时，你会发现需要一些彼此相似的组件，而只有微小的差别。例如：多个按钮的组件，有不同状态和尺寸的独立组件，以及明暗模式或者有无 icon 等，都可以用变体的形式去创建。超好用的变体功能——理解属性和值的概念很重要大家在创建变体的时候经常会有一些困惑，尤其是对于状态非常繁杂的组件，简直是无从下手，尤其是对于属性 Property 和值 Variant 更是觉得很模糊。这里有一些经验分享给大家:首先要了解下一相关的概念，属性 Property：是组件的可变方面。例如：一个按钮组件的属性可以是尺寸、状态，或是否有 icon，可以将其理解为分类。值 Variant：是每个属性可用的不同选项。例如：状态属性可以有默认、悬浮、点击和禁用等，可以将其理解为分类下的参数。然后再了解一下 Figma 的命名规则，Figma 使用斜线命名系统来组织资产面板和实例菜单中的组件。组件名称中的每一个”/”都会创建一个层次。第一个”/”之前的文字将成为组件集的名称，这里需要着重注意一下。比如名称为 Button/Primary/Large/Default/False 的按钮组件将有以下属性和值。组件名称/值/值/值/值。变体名称遵循这个结构，Property1=value, Property2=value, Property3=value。分门别类：变体创建的精髓掌握好命名规则就掌握了变体创建的精髓。教给大家一个非常好用的方法，在创建变体前，首先把需要创建变体的组件进行分类，并统一放在一个草稿上，比如说按钮的尺寸、状态、有无图标等。然后将对应的分类写出相应的值，比如尺寸对应的值就是 m 和 s，状态对应的就是默认、悬浮、点击等。分类好以后，按照上面所述属性和值的对应关系，分别将这些属性和值一一对应填在草稿上。然后再根据 Figma 的命名规则，将所有组件的名称命名完成，比如 Button/m/默认/no/yes，然后就可以直接创建了。化繁为简：优化变体层级Figma 的变体功能很强大，可以进行很多样式的排列组合。但是我们也发现在创建变体的时候，如果按照每个状态、种类进行划分的时候，整个组件会非常的繁杂臃肿。比如 Popover，会发现在创建它的各种状态时会非常麻烦，除了箭头在各个方向的位置外，还要考虑里面元素的组合，比如纯文本、标题+文本、标题+图文、文本+按钮等等，这样组合起来的组件会非常的臃肿，也不利于设计师去选择。所以我们要学会层级的梳理，比如可以将箭头、按钮、标题图文进行一个分布组合，然后再将这些组合成一个新的组件，通过嵌套的层级关系去调整每个层级的位置关系或者剔除某些不需要的层级。组件链接：组件跳一跳，规则全知道创建好组件以后，可以给每个组件都添加相关的链接，这个链接可以添加到组件的描述中，这样开发人员和设计人员就可以在 Inspect 中点击相关的按钮直接跳转链接了，简直不要太好用。比如组件文档链接（可以查看详细的交互规则）、线上的开发地址（可以查看线上的样式），以及直接点击右上角的跳转按钮跳转到组件文档。这样就打通了所有线上线下的样式规则，非常方便用户查阅和使用。资源预览：展开还是合并更好？相信大家在调用组件的时候都会发现一个问题，有的变体预览是展开显示的，有的变体预览是合并在一起的，那么这个分类办法到底是怎么去划分的呢？通常来说需要大家一眼就能选择，减少用户思考的，可以考虑分开建设变体，比如常见的按钮。我们只需要预览图下的各种形态就能找到想要调用的按钮类型。如果按钮全部的集合到一个变体中，那么大家看到的只有一个按钮，对于用户来说会增加判断和选择的时间，是很不方便的。但是对于一些大家理解起来比较容易且展开后的变体样式非常多的的组件，比如 toast、表格，不需要将其各种变体分别的罗列出来，引导用户点击进去，再选择就好了。开关：怎么这么好用大家在建设组件的时候都会发现一个问题，有的组件是开关显示的，有的是下拉显示的。这是因为如果你有一个只有两个可能选项的属性，Figma 会自动将 true/false、yes/no 和 on/off 都识别为开关。所以大家在做变体的时候，尽可能的将这种只有两个可能属性的选项显示为开关，减少用户的操作流程。组件文档：组件类型和状态的展示说明为了方便大家能够清晰知道组件的相关属性和类别，可以为每个组件创建一个组件文档，方便大家查阅和调用。这对于刚接触到这个组件的人来说非常友好。组件文档的结构一般是由组件名称、母文档链接（交互说明）、基本样式、主要组件和相关组件构组成。在这个文档里可以查看组件的类别和相关状态，以及组成这个组件用到的其他组件，并且通过链接都可以跳转到相应的组件，非常方便。组件库：发布、更新、使用可以将组件库发布到团队的资源库。如果要跨文件使用组件，只能通过专业版团队的团队库发布和使用。当每次有更新发布样式或主组件时，Figma 将自动通知到每一个成员，点击更新即可应用。管理员可以提前默认设置将哪些组件库开启哦，减少了新用户每次进入页面还要重新选择。在 Assets 面板下，可以通过搜索的方式找到需要调用的组件；也可以通过展开菜单的方式找到需要的组件。将需要使用的组件直接拖动至文件中，便可使用。推荐大家使用搜索的方法，效率会更高。组织版：更加强大的功能体验对于组织版来说，我觉得比较好用的功能就是组件统计和分支。Figma 组织版可以统计组件数量、使用团队、调用次数等，这对于组件的使用情况统计来说，非常的方便和直观。分支功能可以让每个成员单独创建主文件的分支，可以在其中探索对文件或库的样式、组件和其他方面的更改，而不会影响主文件。当更改感到满意时，你可以查看分支并将其与主文件合并。所以对于团队来说，组织版的这两个功能还是非常实用的。Figma 组件库搭建 Tips：全是干货，一目了然为了确保值与属性相匹配，每个组件都需要有相同数量的斜线。如果你有一个只有两个可能选项的属性，Figma 将 true/false、yes/no 和 on/off 都识别为开关。修复值的冲突错误：如果任何变体的值组合完全相同，Figma 会让你知道存在冲突。即使变体本身在视觉上不同，也会看到这个错误。Figma 将使用左上角的变体作为默认变体，此变体将代表资产面板中的整个组件集。如果你不确定某个组件集有哪些变体，或者它们的原始样式，你可以在原始文件中查看组件集。使用·或者_可隐藏不需要展示的组件。组件内部预设元素只能减少，要增加需拆解。不要将组件完全拆解、嵌套元素都支持修改。使用 Autolay out，对齐自适应更智能。使用全局样式，一键修改更方便。跨文件使用组件，只能通过专业版团队的团队库发布和使用组件。结语组件库是一个强大的提效工具，对于设计师和开发来说有了统一的标准，输出的效率也会大大提高。对于团队来说能很好的提升产品的品牌感和体验，尤其在 Figma 强大特性的帮助下，将发挥更大的作用。同时我们也一定要学会整体思考、善于总结，不断优化和完善组件的细节，将组件库的特性发挥到最大。由于篇幅有限，关于组件库某些内容介绍的不够全面，如果有不严谨、错误的地方还望大家给与指正，欢迎大家一起学习和讨论。用一篇文章，从零开始帮你用好 Figma 的组件库功能对于设计系统，我们最熟悉和常用的应该就是设计组件了，即 UI kits，包括输入框、按钮、文字、链接、下拉菜单等等。阅读文章 > 欢迎关注作者的微信公众号：「百度MEUX」本篇来源：优设网原文地址：https://www.uisdc.com/figma-building-a-component-library
操作 用户 组件 浮层是在页面上方展示的浮层容器，可展示文本、按钮、列表、标签、表单项等内容，在 B 端产品中有着非常广泛的应用。根据内容和作用，可以分为不同的设计组件。例如 Notification，Tooltip，Dialog 等等。这些组件都可以看作是页面空间的延展，最近在项目工作中有了一些新的思考，今天我们就来讨论下浮层组件的设计，希望大家能够有新的收获。主要内容包括以下 4 部分：浮层组件的类型浮层组件 3 个的特点几个应用案例浮层组件应用的注意事项浮层组件的类型说起浮层就离不开“模态”和“非模态”。简单的理解，“模态”就是用户必须进行交互操作的浮层，否则浮层会一直存在，并且无法进行页面功能操作。例如对话框，这种强制性保证了对话框信息的有效传递，但是对用户操作流程造成了比较强的阻断。“非模态”则不需要给出反馈，不影响用户的其他操作，没有强制性，可以说是“来去自如”。微信 PC 端图片查看功能中信息提示很好的反映了两者的差异。对于无法查看的图片，采用模态弹窗形式，提醒用户无法查看的原因，用户需要点击确定后，才能继续操作。如果查看到最后一张图片，系统采用非模态的 Notatifion 组件提醒。组件未消失时，用户也可以回看或其他操作，更加轻量化。具体到组件设计层面，浮层的类型就比较多了。例如 AntDesign 设计规范共定义了 8 种浮层组件，Element 设计规范则定义了 9 种浮层组件，增加了 Messagebox 组件，其实就是 Dialog 对话框的简易版。具体的差异感兴趣的同学可以自己去查阅一下。Ant Design设计规范Element 设计规范浮层组件的特点1. 构建独立空间，简化页面信息量浮层在一定的条件下触发展示，作为一种容器可以形成临时的内容空间。不会占据页面空间，并且可以简化页面的信息量，有助于页面的内容布局。例如常见的数据可视化展示时，重点在于图形展示，详细数据放置在浮窗中展示，从而保证了页面的可视化效果。浮窗展示空间2. 交互轻量化对于强调操作效率的 B 端产品，如非必要，需要尽量减少页面的跳转次数，实现当前页面内的流程闭环。在交互流程上，浮层组件停留在当前页面，相比页面跳转的交互方式效率更高。在触发机制上，非模态浮层可以实现悬停展示，移走消失，操作更加方便。某些信息反馈类的组件还可以自动消失，最大程度上减少了用户操作。并且非模态浮层同样可以承载按钮、选择器，表单等功能性组件，用户可以就近操作，从而提高效率。QQ浏览器设置浮窗在页面布局方面，浮层也更加灵活，可以出现在页面中间、侧边、上方、下方等各个位置，尺寸可大可小，对于不太复杂的信息都有较好的适应性。3. 实现操作的所见即所得由于非模态窗口不具有强交互性，一般不占据屏幕中间位置，更多的是跟随功能选项或者页面边缘。这就为功能操作的所见所得提供了便利性，方便用户做出操作决策。例如表格列设置功能，操作后即可实时展示操作结果。或者页面皮肤的设置，用户选择后即可预览效果，方便用户对比选择。QQ浏览器皮肤切换浮层组件的应用案例在实际使用场景中，浮层组件主要应用在信息反馈、内容展示和功能操作 3 个方向，给大家介绍几个案例。1. 预览展示，减少用户的操作成本Windows11 任务栏悬停程序图标时，显示浮窗预览当前运行的任务，通过图形化的方式，让用户更好的识别任务内容，便于用户做出选择。在淘宝 Web 端订单页面，商品在未收货状态下，物流状态就成为用户更加关心的信息，悬停显示物流最新状态，用户可以不进入详情页快速获取信息，交互上更加便捷，有效的减少了用户操作成本。2. 就近原则，快捷操作在 B 端产品中，表格信息如何快速拆分内容，查看单个数据的详情信息呢？如果采用跳转页面，或者表格按钮等形式，都无法带给用户更加流畅的操作体验。通过浮层展示功能选项，就可以实现点对点的查看信息详情。类似于操作系统的右键功能，方便快捷。同样在微信公众号编辑器中，悬停和选中图片都可以调出图片编辑功能，就近的设计形式，保证了用户的操作效率。3. 引导作用，辅助功能指向我们使用 Chrome 浏览器登录网站时，经常提醒我们保存或者更新密码。这是脱离了网页之外的浏览器自带功能。如果采用模态对话框方式，在屏幕中间弹窗展示确认对话框，会阻断用户的正常操作流程。使用了非模态窗口，并与密码管理功能入口强关联，可以引导用户认知功能入口。组件使用注意事项对于组件如何使用，各大厂商都给出了较为明确的场景说明。但是规范是死的，如何灵活运用就需要“仁者见仁、智者见智”了。1. 基于用户场景的思考当我们面对删除功能的时候，基于防错原则，首先想到是增加确认弹窗，这看起来是没有问题的。但是不是最优的解决方案呢？例如同样是删除网址收藏功能，QQ 浏览器和 Chrome 浏览器给出了两种解决方案。QQ 浏览器删除时，增加了确认弹窗，用户确认后可删除。QQ浏览器确认弹窗Chrome 浏览器的方案时，顺应用户操作，直接删除内容，显示成功提示的同时，增加了容错的“撤回”按钮。Chrome浏览器浮窗提醒我们可以先思考下用户场景，删除是个比较高风险的操作，用户一般只有产生了强烈又明确的意图时，才会主动删除内容。无论是确认弹窗还是撤销功能，都是为了避免用户误操作。所以就要评估用户误操作的几率和误操作后带来的用户损失。就书签而言，用户损失并不大，误删除后再加入收藏就可以了。关于误操作的几率QQ 浏览器只有选中内容后，才能激活删除按钮，另外还可以通过右键菜单、更多按钮、选择”删除“选项后才能完成操作，其实防错机制做的比较好的，因此误操作的几率比较低。关于操作成本误操作几率比较低的情况下，我个人认为 Chrome 容错的设计方案更优一些，删除的流程更顺畅，只需要在误操作时撤销就可以了。QQ 浏览器确认弹窗的方式操作成本更高，不过好在能够批量删除。在一定程度上解决了频繁弹窗的问题。这种容错思维在 Chrome 其他场景中也有应用，我觉得还是值得借鉴的。2. 避免滥用现在各种反馈有点泛滥的趋势，所见即所得的场景下，我觉得并不需要增加反馈信息。例如登录页面成功后会直接跳转至系统界面，登录成功的提示就有点画蛇添足了。3. 毫无来源的反馈信息当用户打开页面，没有任何操作就弹出一个提示信息，而且是一闪而过，只会让用户用户一脸疑惑。所以需要注意提示信息的形式和节奏，避免让提示信息成为用户的负担。新人来收！4个底部浮层的科普知识点关于底部浮层的定义相信大家都很熟悉，底部浮层通常称为「浮层」或「浮窗」，可用于给予信息提示，也用于展示更多的拓展信息。阅读文章 > 欢迎关注作者微信公众号：「子牧UXD」本篇来源：优设网原文地址：https://www.uisdc.com/floating-layer-components
在路上
落霞与孤鹜
飞翔的企鹅
表哥
张大湿
