Smashing Podcast 第 9 集与 Stephanie Walter：我如何使用 UI 框架？

作为一名开发人员，我喜欢 UI 框架的一件事是它们通常带有默认样式，但这是我们在项目中应该依赖的东西吗？ 简单地使用默认样式并相信制作框架的人在设计这些组件方面做得非常好？ 加入我今天的播客节目，我将与 UX 设计师 Stephanie Walter 讨论我们在构建 UI 框架时应该考虑的事情。

显示注释

• 斯蒂芬妮的网站
• 斯蒂芬妮在推特上

每周更新

• Anna Prenzel的“如何使用 Angular 和 RxJS 创建卡片匹配游戏”
• Sarah Drasner的“如何在 JAMstack 上创建无头 WordPress 网站”
• “魔术翻转卡：解决常见的尺寸问题” ，作者 Dan Halliday
• “Django 亮点：用户模型和身份验证（第 1 部分）” ，作者 Philip Kiely
• Shajia Abidi 的“如何使用 React 和 Leaflet 创建地图”

成绩单

Drew McLellan：她是以用户为中心的设计师和移动体验专家，她跨越了令人愉悦的产品和界面，特别关注性能。 她曾为卢森堡大学、欧洲投资银行、宝马和微软等客户开展项目，她帮助这些客户从战略到最终产品的整个过程中向他们的受众交付成功的项目。 她是产品设计方面的 Google 开发人员专家，也是一位充满激情的教师，她在众多博客文章、文章、研讨会和会议演示文稿中分享她的知识。 所以我们知道她是一位专家级的用户体验设计师，但你知道她曾经有一份为埃尔顿约翰爵士安装地毯的工作吗？ 我的 Smashing 朋友，请欢迎 Stephanie Walter。 你好斯蒂芬妮，你好吗？

Stephanie Walter：嗨，我非常喜欢这个介绍。

Drew：所以我今天想和你谈谈一个特定的问题，那就是使用现成的用户界面框架的主题。 现在你是一名用户体验设计师，你与许多不同的客户一起工作，你的工作是通过制作高度可用的用户界面来帮助这些客户创造最佳的用户体验。 因此，能够使用一套现成的工具来做到这一点的想法对我来说似乎有点牵强。 您在工作中经常看到 UI 框架的使用吗？

斯蒂芬妮：是的，这是我经常看到的事情，尤其是在过去的几年里，因为我开始在一家机构工作，现在我在公司工作。 所以在那些超级大的 IT 技术团队中，是的，目前有很多框架 UI，比如我看到最多的是 Material-UI，基本上 Material design 是一种谷歌设计的指导方针和东西，而 Material -UI 是来自 Angular 的团队，也是来自 React 的团队。 他们使用来自 Google 的 Material Design 的外观和感觉创建了自己的框架。 但这与谷歌无关。 就像他们一样，我不知道，我认为他们喜欢这种外观和感觉。 所以目前，这是我使用的两个主要 UI 框架。 还有一种叫做 Ant Design 的东西，它变得非常流行。

Stephanie：这是一个 React 框架。 我不知道他们是否也有 Angular。 我认为它是由中国的一个团队制作的。 这很有趣，因为它不仅提供了组件，React 中的所有东西，而且如果你访问他们的网站，你还会得到草稿文件，这实际上很有趣，因为它可以激励或帮助设计师构建或塑造该框架使用的 UI 组件的接口。 所以是的，我经常看到这种情况，尤其是在大型 IT 团队中，因为大多数时候这些团队都没有设计师。 目前，我基本上是欧洲投资银行的一个小团队中的一个 UX 团队。 所以我是一名 UX 设计师。 我与一个由开发人员、业务分析师和所有优秀的人组成的团队一起工作，但仍然是整个项目的一名设计师。

斯蒂芬妮：在我到达之前，没有设计师。 所以这是一种在很多公司中实施的解决方案，尤其是在内部产品上。 他们通常会说，好吧，我们真的不需要设计师。 我们只需要对我们的内部用户有用的东西，让我们只使用一个框架，因为它对开发人员来说很方便。 大多数组件已经存在，并且由于团队中没有设计师，所以它有点取代 UI 设计师的角色。 是的，问题在于，好吧，那么你就有了组件，但 UI 设计师的角色不仅仅是决定按钮应该是红色、绿色、橙色、蓝色等等。 通常UI设计师的角色是信息架构，了解用户需求。 所以一切超出了界面。 所以即使你有这种框架来处理整个用户界面，所以在视觉上你在屏幕上看到的东西。

斯蒂芬妮：在某些时候你仍然需要有人来理解我们在屏幕上放了什么，它会如何表现？ 当我们点击这里时会发生什么？ 用户如何实现他们的目标？ 我们如何从 A 点到 B 点？ 因为我们可以使用模型，我们可以使用选项卡，我们可以使用所有组件。 所以这就是为什么它总是有点复杂和棘手。

Drew：有没有可能，你认为能够使用现成的 UI 框架创建一个可用的用户界面，还是总是需要妥协？

斯蒂芬妮：我有点希望如此。 我有点希望如此，否则我正在构建不可用的接口。 所以这个答案是完全有偏见的，但是是的，我认为是，但这也取决于你愿意做出的妥协程度，并且双方都有妥协。 例如，目前我正在牺牲很多按钮，因为您在 Material-UI 中有一些非常具体的按钮，我不太喜欢按钮上的涟漪效应。 我认为它在移动设备上效果很好，因为在移动设备上，当用户点击或触摸按钮时，你需要一种很大的反馈。 但是这些步骤是一种连锁反应，一直在按钮上。 这有点矫枉过正，尤其是当有很多按钮时。 但是我们仍然会保留这种连锁反应，因为移除它会非常复杂，因为它是内置在 React 框架中的。 并且在这个按钮上有另一个悬停效果，更微妙的东西在这里不会是这种令人毛骨悚然的东西。 这将是超级复杂的。

斯蒂芬妮：所以这就是你所做的妥协。 但与此同时，我不会在自定义组件的特定事物上妥协。 我以前工作的地方，是一家旅游和航空公司的当前客户。 航空公司有一些非常非常特别的需求。 例如，航空公司的日历，你想放价格，你想放……如果你没有在特定日期前往这个目的地，你不知道什么时候放，你有这个出发和到达，大多数这些 UI 框架的基本日历都没有提供这些东西。 所以在某些时候你可以说，好吧，我们将只使用他们拥有的日历。 就是这样。 你需要超越这一点。 所以大部分的妥协基本上都是建立在基础之上的，我们是不是使用了基础组件呢？ 我们是否创建了一个适合用户需求的自定义？ 还是我们将两者混合？ 例如，在日历的情况下，我们使用日历网格，所以我们使用基本组件，然后我们在此之上通过自定义对其进行了增强。 所以那是很多 React 开发。

斯蒂芬妮：是的，所以通常你会做出很多妥协。

德鲁：所以听起来使用用户界面框架可以让你获得一定程度的成功，但要真正拥有一个好的用户界面，你需要在上面做一些定制吗？

斯蒂芬妮：通常。 是的。

德鲁：这种定制是否超越了主题？

Stephanie：是的，我的开发人员希望它不会超出主题范围。 尤金 如果你听我的话。 我想如果我们在每样东西上改变一些颜色，他会非常高兴。 但是，是的，在某些时候你需要超越定制，因为首先，就像 UI 框架一样，乐高工具是一种工具箱。 所以你在盒子里有很多不同的组件，但这并没有建立一个页面。 你仍然需要一个页眉，你仍然需要一个页脚。 您仍然需要框架中没有的额外内容。 因此，有时您可以将组件调整为您需要的内容。 据我了解，我们正在使用卡片组件来构建模态窗口，但模态窗口的问题是它的行为并不像卡片。

斯蒂芬妮：你有点超出了这个范围。 你需要一个模糊的背景。 您需要在点击时触发它，而通常您的卡已经在界面中。 所以我们使用这个卡片组件是因为它有很多我们需要的东西，比如背景，顶部的标题和标题，底部的一些按钮。 所以我们有了结构，然后我们稍微调整一下。 但是我们有时会在语义、HTML 方面遇到一些冲突。 因为例如，我想要没有按钮形状的按钮，所以就像链接按钮一样，开发人员说，“好的，所以我们使用像你的 href 链接这样的链接。” 我说：“不，这不是链接。 这是一个按钮。 当他们单击它时，它不会打开新页面。 它清除了表格中的所有内容。”

Stephanie：所以从语义上讲，它应该是一个按钮。 “是的。 但它不存在于框架中。” 我说：“好吧，我知道我们该怎么办？” 所以通常你会开始讨论这些小事情，因为我真的让我的开发人员对可访问性感到厌烦，这是另一个额外的尝试，以确保我们拥有他们可以很好地工作的基本组件。 而且它们在语义上就像我不想在 gif 中的 gif 中使用带有 gif 的按钮。 否则我们最终会有问题。

Drew：我想开始一个将使用 UI 框架的新项目，你可能需要从某种用户研究开始。

斯蒂芬妮：是的。

德鲁：公平吗？

斯蒂芬妮：你应该。 你需要。 所以是的，通常你可以拥有你想要的所有组件。 您仍然需要知道您的用户在页面上需要什么，他们将如何导航？ 你需要建立一个流程。 所以通常甚至在决定一个框架之前，我们所做的就是去找我们的用户，我们与他们交谈，我们试图了解他们的需求。 所以目前我很幸运，因为用户在银行内部。 所以我们和他们一起做了很多研讨会，你必须想象这是一个超级复杂的界面。 我们正在从 10 甚至 15 年前构建的东西迁移到使用 Material-UI React 的全新闪亮的东西。 所以这是一个很大的变化，你必须明白，在这 15 年里，每个想要东西的人都可以寻求支持，然后他们要求 IT 团队实施。 因此，目前我的界面就像 400 页，其中包含表格、表格内、表格内、其他表格以及甚至不应该在表格中的内容。

斯蒂芬妮：就像我们有很多东西只是关键价值，关键价值，关键价值。 所以他们用两列构建表格。 我想，“不，也许我们可以做得更好。” 所以目前我们正在做的是我们做了一些用户研究来了解用户的不同目标。 所以我们确定的是他们对界面所做的事情，他们有一些规划目标。 他们需要计划他们的工作。 所以我想知道这个操作将去这个会议，所以我需要在那个时间表上，像这样的东西。 他们想监控一件事，他们想报告数据。 所以监控就像查看数据并确保一切正常。 报告能够利用数据，利用数据做一些他们想要分享的事情，并与同事进行协作，所有这些都是我们通过直接与用户讨论而发现的。

Stephanie：我们发现，实际上我们最终计划迁移的一些事情对于用户来说是每天最重要的事情。 所以规划用户目标是目前最大的一种。 所以我们真的，真的在努力。 所以是的，我们确实使用了面试，现在我们处于超高水平的阶段，我们需要构建外壳，我们需要了解导航。 但目前我们并没有真正检查所有数据，这就是我们现在要做的。 这很有趣，因为我们有很多表格，我们说我们可以采用一种不聪明的方式，将表格放在新界面中就完成了，或者我们可以说，好吧，让我们试着理解什么这些表是，我们的用户用这个表做什么？

Stephanie：然后也许一些表格可以显示为数据可视化，然后你需要了解整个业务，这样数据才有意义。 所以如果你有一个不错的框架，你说，好吧，让我们使用这个图表……我认为它被称为图表 JS 框架。 你有很多东西，你可以有直方图、饼图和图形等等，但在某些时候你仍然需要一个设计师来帮助你做出决定。 好的，这些数据，如果我们将其显示为图表是否有意义，或者将其显示为饼图更有意义，因为我们想展示整体的一部分，或者我们想比较一个国家在过去 10 年的演变年，那么直方图更有趣。 因此，根据用户想要对数据执行的操作，您将以完全不同的方式显示它们。

Stephanie：通常这不是开发人员的工作。 我们的开发人员，他们是超级聪明的人。 我很抱歉，但我老实说与男性开发人员一起工作，我希望我有一些女士，但没有。 他们都不是女性。 所以超级聪明的人，但他们不是超级有资格说，好吧，这个数据应该这样显示，那个，那个，那个。 所以最后你仍然需要一些设计师去和用户交谈，了解你可以用数据做什么，这不仅仅是说，好吧，这应该是一个标签栏，或者这应该是左边的导航。

德鲁：在根据与用户交谈做出这些决定之后。 您通常会将生成的原型或设计带回给用户以再次对其进行测试，以查看他们是否了解您选择的图表类型？

斯蒂芬妮：是的，我们实际上做了很多，这真的很好，因为在你知道它会有用和可用之前你不会开发一些东西。 所以这取决于。 如果实际上开发这个东西更快，因为他们已经有了大部分组件，我通常会做非常快速的纸质原型设计，然后我们开发这个东西，因为它很快，即使没有数据。 如果它是复杂的，非常非常新的东西，需要花费大量时间来开发，那么我们会说，好吧，我们设计几个屏幕，然后直接在屏幕上进行一些测试。 所以我们有一个叫做 InVision 的工具，基本上你把所有的设计放在里面，你可以在不同的部分之间创建链接。 问题是它还取决于您要测试的内容。 例如，如果您想测试手机，那么在 InVision 中测试它们是一场噩梦，因为人们无法真正感受到它们，尤其是在手机上。

斯蒂芬妮：所以它总是有点聪明。 最快和最便宜的方法是什么？ 只测试设计是否更快、更便宜？ 这够了吗？ 通常对于表单，并不是因为您已经自动完成了您在前端实际用户填写表单的所有繁重工作，因此对于表单，实际构建表单并对其进行测试可能更有效。 但是对于新事物，是的，我们做了很多设计。 我们去找用户。 所以目前我们要么做一对一，但我的用户真的很忙。 这是一家欧洲投资银行，所以他们没有那么多时间。 所以我们通常做的是，如果我们与用户进行一对一的交流，我们会举行一些小型会议，更像是焦点小组。 这也很有趣，因为有时你会有一种对抗。 有些人说，“是的，我认为它对我有用，因为我就是那样工作”，然后会有其他人说，“哦，你那样工作？ 其实不，我就那样那样做。”

Stephanie：所以，让几个人在房间里听对话，做笔记并说，“哦，也许我们可以这样做”和“这个组件会更好，基于我刚才的内容，这也很有趣听到。” 诸如此类的事情。

德鲁：如果您正在为您的产品与更广泛的受众合作。 所以也许不是像你这样的内部用户，而是更多的普通大众，设计师有没有廉价的方法可以利用研究？ 如果您不直接知道您的用户将是谁，是否有更简单的方法？

Stephanie：你应该知道他们将是谁，否则在构建产品之前它会完成营销人员的工作。 但是，是的，我们进行了一些游击用户测试，例如，您仍然可以使用 InVision。 因此，您可以在 InVision 中构建一些原型，然后您可以通过社交媒体招募用户。 我正在为一个有帮助的产品工作，叫什么名字，汽车经销商修理东西，然后还通知客户额外的修理，诸如此类。 所以我们在 LinkedIn 和 Facebook 上已经有了一个不断发展的社区。 所以你能做的就是招募这些人。 您可以进行远程测试，就像我们在在线工具之类的工具中进行对话一样。 你可以做一些屏幕共享。 所以我们也为一些项目这样做了。

Stephanie：我只想给你一个建议是之前测试过这个工具，因为我正在使用它，它被称为appear.in。 但我认为他们将名称更改为 Whereby 之类的，但实际上是在浏览器中，我说，好吧，这很好，因为用户不需要安装任何东西，但用户不是在真正的计算机上。 他们进入了 VM，进入了 Citrix，而且他们没有麦克风，所以我们最终做的就像他们使用我的工具来共享屏幕一样。 他们在点击原型，同时我让他们通过电话，就像固定电话一样，直接与他们交谈。 所以总是有，这是一个相当便宜的日子，因为这是招聘的美好一天，我想我们有 10 个用户或类似的东西。 是的，即使你不能面对面，你也可以做很多事情，我已经直接在 Skype 或类似的东西上做了很多可用性测试。 所以总有一些便宜的方法可以做到这一点。

Drew：在选择要使用的 UI 框架时，如果这是您要走的路线，那是您将只留给开发人员的事情，还是设计师也应该参与的事情？

斯蒂芬妮：对我来说，你应该让整个团队都参与进来。 像设计师、开发人员，如果你有一些架构师，也许还有架构师，因为框架的构建方式也可能会影响这些事情。 不幸的是，大多数时候当他们到达项目时，框架已经确定了。 不，实际上这很有趣，要么已经决定，要么他们要求我验证他们对框架的选择，但我没有做任何评论或研究。 我完全不知道项目中有什么，因为他们甚至没有向我展示他们的屏幕。 他们就像，“是的，做你的事。 我们可以使用这个框架。” 我不知道。 好吧，我们有屏幕吗？ 所以他们最终向你展示了几个屏幕，这是他们想要迁移到云中的 Windows 原生应用程序。 他们说：“是的，我们只需要按钮，而且主要是表格之类的东西。”

Stephanie：但是真的很难说，“是的，选择这个框架，我们拥有我们需要的所有组件。” 或者像，“如果你不知道你的内容是什么，导航是什么，就不要去。” 所以我认为在选择你的框架之前你仍然应该有一个全局概览，除非你 100% 确定你拥有所有的组件。 但是我有一种感觉，大多数时候框架的选择基本上是基于开发者现在喜欢什么技术，在此之前他们是否有使用框架的经验？ 我们在一些项目中使用 Ant 只是因为一些开发人员有这方面的经验，他们真的很喜欢它，而且他们使用 Ant 的效率很高。 对于 Material React UI，它也是一样的。 这就像因为开发人员已经在以前的项目中使用过它，所以他们使用它很有效率。

Drew：因此，实际上必须在开发人员熟悉的内容、他们所知道的内容、将与他们的技术堆栈一起工作的内容以及产品在创建良好用户界面方面的要求之间取得平衡。 而且您需要以某种方式平衡这两者以找到理想的框架。

斯蒂芬妮：是的。 我对某个项目有一种特定的要求，那就是……我在卢森堡，我们有很多欧洲机构之类的东西，所以我们对其中一些有额外的可访问性要求。 通常在决定框架时，​​他们并没有真正检查框架的可访问性，然后他们在项目开始几个月后回来说，“哦，刚刚告诉我们有这项新法律，我们应该可以访问，但我们不知道该怎么做。” 是的，现在有点晚了。 所以对我来说，要选择一个框架，你需要真正了解项目开始时的所有约束，如果可访问性是其中之一，你需要测试你的组件并确保它们是可访问的。 但我不是 React 或 Angular 开发人员，但我很确定将不可访问的 UI 框架变成可访问的东西是非常复杂的。 我想重建所有组件可能有点复杂，所以就这样。

Drew：如果您发现自己正在从事的项目尚未进行该过程并且已经选择了 UI 框架，那么是否存在用户界面可能开始受到该框架中已经存在的组件影响的危险，而不是被用户的需求所驱动？

Stephanie：真的，老实说，我参与的大多数项目最终都会有很多取舍，即使你真的很努力。 所以它主要是关于平衡和与开发人员讨论。 所以通常我做的是我们做一些线框，甚至是快速的纸线框，说好的，在这个页面上我们需要那个那个那个组件，我做的第一件事就是问开发人员我们的目前的框架？ 它是什么样子的？ 然后我们一起决定，好吧，这是一个可以完成工作的组件，或者好吧，这不会完成工作。 我们调整它吗？ 就像我们仍然保留组件但稍微更改它以使其完成工作，还是我们从头开始构建一些东西？

斯蒂芬妮：当然，最终这将取决于预算。 所以你最终做了权衡。 就像我会接受那些几乎从未使用过的小组件，如果它们不完美并且几乎没有问题。 但是对于主导航，主要结构，例如你一直在屏幕上看到的东西，这真的需要工作。 用户需要了解他们如何有效地工作，是的，正如您所说，如果您没有任何框架，您希望获得的理想体验与您手头的东西以及预算以及定时。 如果我们说，好的，对于这些 sprint，功能需要在这个 sprint 结束时完成，然后他们说，好的，但是如果你想要你的组件，我们永远不会在这个 sprint 结束时完成这个功能，那么你开始讨论，好吧，我们是否在下一个屏幕中完成此功能，我们是否需要更多时间来正确完成？ 通常这真的取决于。

Stephanie：最让我沮丧的是，当我知道我们使用了裁剪修复组件时，他们对我说，哦不，别担心。 我们稍后会解决这个问题。 而且我知道，不幸的是，后来的事情可能永远不会发生。 所以要看团队。 但过了一段时间你有了经验，你知道，这会迟到吗？还是不会？ 是的，这是关于妥协。 当您使用这些工具时。

Drew：作为一名开发人员，我喜欢 UI 框架的一件事是它们通常带有默认样式。 所以这意味着我不一定需要一个设计师来帮助我设计所有组件的外观和感觉。 这是我们应该在项目中依赖的东西吗？ 只是默认样式并相信制作框架的人在设计这些组件方面做得非常好？ 或者您会自己设计这些组件的样式吗？

斯蒂芬妮：我认为这真的取决于。 例如，Material-UI 的问题是您的网络应用程序的外观和感觉基本上是配置的 Google 产品。 因此，如果您实际上不更改字体，更改一些颜色并带上您自己的品牌标识并这样做，那么您将拥有一个看起来就像任何 Google 产品的产品，这可能是一件好事，因为如果您的用户已经习惯了 Google 产品，这可能有助于他们理解它。 所以通常如果你团队中没有设计师，你有什么选择吗？ 就像我见过的许多不同的作品一样，它们带有自定义主题，因此至少您可以更改颜色。 我认为您也可以很容易地更改字体。 但同样，如果你改变颜色并且你不擅长设计甚至可访问性，也许你将使用的颜色会发生冲突，它们可能会有对比度问题。

Stephanie：例如，我喜欢橙色，但它是最令人讨厌的颜色之一，因为要拥有真正易于使用的橙色，例如，作为带有白色文本的按钮，它看起来几乎是棕色的。 如果你想拥有这个真正闪亮的橙色，你需要在它上面加上深色文本以使其可读，但它会让你的界面在一天结束时看起来像万圣节。 是的，我看到你在笑。 但这是真的。 所以它总是关于这些妥协，如果你是一个开发者，你想使用框架，而你没有设计师，我认为它仍然比没有任何东西并从头开始构建它要好然后使用起来超级复杂。 但问题是，仅仅因为您拥有组件并不意味着您将构建一个出色的界面。 就像乐高积木一样。 如果你有乐高积木，没关系，但你可以做一个真正好的宇宙飞船，或者你可以做一些不能结合在一起并且会因为你没有真正的计划而分崩离析的事情。

Stephanie：所以设计远不止这些。 设计是关于真正了解屏幕上的内容，它将如何工作。 我认识一些真正有能力做到这一点的开发人员。 所以他们非常擅长可用性指南，并且他们了解很多设计规则，例如。 因此，在选择组件时，他们真的很擅长。 我知道开发人员不知道要选择什么组件并选择第一个完成这项工作的组件。 但是过一段时间就不行了。 例如，就像选项卡一样，我们有一个界面，一些开发人员可以在其中选择选项卡。 我认为一开始只有三个项目是有意义的。 但是然后屏幕上有 12 个项目，然后你有三行选项卡的选项卡，所有这些都是相同的一级选项卡，并且选项卡内有选项卡。 所以他们有了组件，它看起来不错，因为他们使用了框架，但它并不是真正可用的。

Stephanie：例如，我也有类似的模态窗口。 他们在没有设计师的情况下构建项目的地方，过了一段时间，我认为客户要求越来越多的东西进入这个模式。 所以他们最终得到了一个带有表格的屏幕，当你点击添加一行时，你打开一个模式，在这个模式中你有两个选项卡，然后在其中一个选项卡中你甚至还有另一个表格，然后他们想要添加一个额外的东西，我想，好吧，也许我们可以把一个模态放在一个模态之上。 并且在某些时候设计师会回答，好吧，如果你在模态中有这么多的内容，它不应该是一个模态窗口。 它应该是一个页面。 因此，即使您拥有组件，您仍然需要某种架构师来制定计划并确保所有这些组件都能很好地协同工作。

Drew：所以如果作为一名设计师，你被要求改变一些组件的样式，你会尝试改变所有的样式吗？ 您会自定义所有内容，还是会关注某些领域？

斯蒂芬妮：我认为颜色是你首先看到的东西，颜色实际上可以给你带来身份。 如果您有一个强大的品牌标识，至少在按钮或图标上使用产品的颜色或类似的东西，已经可以帮助您自定义框架。 字体，因为我认为这很容易，如果框架构建良好，通常你会在某个地方更改整个字体系列，然后它应该在网站的其余部分上层叠。 所以颜色和字体是我认为快速定制框架的两种简单方法。 图标是另一种带来个性的好方法，但这可能很困难，因为据我所见，大多数框架都带有自定义图标或 Font Awesome 或已经内置的库。所以要替换这些，首先你需要一个很多图标，如果你想全部替换它们。 所以它可能有点复杂。 我还看到了允许您选择要使用的图标包的框架。 比如 Font Awesome、Glyphicons 和其他一些。 所以这是你可以很容易地定制的东西。

Stephanie：然后是外观和感觉，例如页眉，通常你有不同类型的页眉、页脚。 你如何导航这样的事情。 因此，您已经可以进行很多小的自定义，使其看起来不像 Material-UI-ish，它更像您的品牌，然后您可以使用例如边界半径。 无论您想要完全圆形的按钮，还是想要方形按钮，或者您也想要中间的东西，比如阴影。 因此，一些通常很容易定制的小东西，因为大多数框架都将它们放在 CSS 变量中。 除了这些连锁反应之外，我认为这是您无需付出很多努力就可以自定义的那种小东西。 我讨厌那个。 我要与之抗争。 我有点希望他们最终改变它。

德鲁：我想像这样的事情，看起来很明显可能看起来就像表面水平效应，你认为这很容易改变，而在这种情况下，事实证明它不容易改变？ Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. 你知道吗？

Drew: Yup.

Stephanie: It does. 好的。 So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. 它可能不起作用。

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.