 It's not a misspelling. It's the Norwegian spelling of the name Lyssa. I also respond to Lyssa, but if you can avoid calling me Lyssa, I actually get it all the time. I would really appreciate it. So I am a UX UI Distinguished Engineer from Discover Financial Services. And I just wanted to take a minute. I know you guys all have all heard the terms UX and UI before, but I want to differentiate what they mean because a lot of people get those things confused. So UX stands for User Experiences. And we all have hundreds of user experiences every day, like checking into your hotel, buying a cup of coffee, checking into a conference. And yes, more and more of those experiences are digital. And when they're digital, they do have a UI, right? And then a UI becomes a very important piece of creating a great user experience. So it's one of the levels set on that before I dive in. So I am both an engineer and I'm a designer, and this is why I'm super passionate about the subject that I'll be discussing today. I know the magic that happens at the intersection of design, engineering and collaboration. So, and there's no better platform for collaboration than open source. So today I'm talking to you about design and open source. So here is a quick agenda of the journey I'll be bringing you guys on for the next 40 minutes. It will be fast because I have a lot of information to cover. But anyway, what I'm first going to do is just talk about the terms engineering design and open source. I'll provide a summary of the pain points in the existing design to development to deployment pain points that exist. I'll explore some what ifs and introduce a concept called unified design. And then I'm going to talk about the impact of the unified design discovers contributions to the idea of design and open source and talk about the future or the hopeful future for design and open source. All right. So we all know the terms design and engineering. This is nothing new. But what I did want to address is that there's many facets of course of design and engineering and far more than it represented here. These are just roles that are generally involved in the creation of digital experiences. But there are assumptions made by engineers and assumptions made designers by designers that if you're an engineer, you probably know how to do all those things. You know how to be a front end developer, you know, cybersecurity and equally on the other side, engineers often assume that designers like UX designers are also visual designers and they know accessibility design and, you know, motion design and that's simply not true. So one of the most important things in design thinking is to address assumptions and, you know, find out if they're true or not. And so that is one of the things I just wanted to address before we dive into it. All right. The one thing I will say is all those roles that are differentiated are really necessary to create amazing user experiences. So everybody is super important. All those roles are super important. And then I wanted to, you know, talk to you about the definition of open source. Now, again, this isn't something that I need to tell you guys what open source is, but I just wanted to look at some of the wording around open source. Open source software is code that is designed to be publicly accessible. Anyone can see, modify and distribute code as they see fit. Now this is a definition that I grabbed off of red hat. And I just want to highlight the word anyone right so anyone should be able to contribute to open source. And I think we'd all additionally approve, you know, acknowledge that open source would probably, you know, could benefit from the involvement of designers. Seeing that open source is used by companies all over the world in real products and then consumed by real end users, often in a digital interface. So, you know, I think we can agree that designer should be able to join and designers would be beneficial to the open source community. And yet there is a profound lack of designers in open source. And I wanted to explore this with you guys. Now, I started on this journey of putting this to get this deck together. I found a really great blog and case study done by designup.co. So I'll be referencing some of their research in this. But first of all, the findings were to no surprise that open source is generally developer led like that's no big surprise right. But because of that open source is generally focused around contribution of code. So contribution of bugs, new features, and developers are acknowledged for their contribution to open source. Designers are actually very comfortable in a collaboration space. So design thinking is sort of the bedrock of a lot of design work. But even designers who don't know what design thinking is are actually practicing it on the daily. If you're a designer hired to do a logo for a company, you sit down with a person you talk to them about what are their needs, you're emphasizing with them, you're defining their problem, you're defining who their customer is, what their desired message is. Then you ideate and you come up with some ideas, you put together a couple of logos, you show them to the company, you get their feedback, and then you give them the final logo after everything's done. Well, that actually demonstrates the whole of design thinking, which is empathize, define, prototype, ideate, prototype, test, and deliver. So we're very, very comfortable and we love collaboration. Our tools represent that too. You probably have all worked in Muro or Muro. Additionally, our design tools, are you a design tools like Figma allow multiple designers to be working on a file at the same time. So although designers are very comfortable collaborating, a lot of designers just don't know what open source is, or if they know what it is, they're kind of afraid of it. Now, again, to engineers, what's to be afraid of? It's not scary, but your terminology and your technology is intimidating designers. Just as sort of like our terminology for design is like, kerning in the golden ratio and skeo morphism and, you know, those terms are probably not things that you're familiar with. So it is intimidating for designers to understand things like, you know, cloning and stashing and things like that. So just one of the levels set on that. Additionally, you know, our tools aren't well integrated at all. So like a lot of open source projects don't have a master Figma file that they're pointing to, and those things aren't referenced in GetRepo. And also designers aren't rewarded or acknowledged in any way for their contributions and open source if they're doing it. So just wanted to mention all of that. So what did we do at Design at Discover? So we started to look at, you know, as far as the applied design thing, to look at our design, to development, to deployment lifecycle. And just want to mention that we started this observation looking at the UI design. You know, hopefully everyone's practicing design thinking in UX before they're rendering a UI, but that is a whole nother subject that I could be up here for 40 minutes talking about. So we concentrated on the UI design to deployment lifecycle, and we found a lot of pain points, right? So there were a lot of pain points on the designer side. There were a lot of pain points on the engineering side. And there were a lot of pain points that got delivered to the customer, right? So I won't have time to go over through all the pain points, but I did want to talk about some of the, like, biggest pain points that we identified. So first of all, designers start their rendering of UI components in something like Sigma or Sketch or Adobe X. And a lot of these tools do not have guardrails to help designers understand how to build components excessively, right? So if a designer creates a component or component library, a whole design system, and hands it off to developers, well, that problem is perpetuated all the way to the delivery of a user interface if it's not caught in some testing. Secondly, once a designer hands off a design to a developer, there's a lot of problems that happen just there. Well, first of all, there's access to the tools. An engineer can get a design in any number of formats, right? They can get designs in Adobe, they can get designs in Sigma, in Vision, Zeppelin, and they have to first get access to those tools. Now, if they are lucky enough to have permission to access those tools, they also have to know how to identify the red lines in the tools that are telling them exactly how many pixels it's supposed to be, what is the spacing, what's the curve, what's the bevel, what's the kerning of the font, what's this letter spacing. And if they don't know how to do that, they will guess. And I'm not blaming them, I get it. I'm a developer too, you're under tight deadlines, and you think what you're creating looks a lot like what the UI created. So you keep on moving. Additionally, you know, when designers hand off designs, oftentimes they are using a component library or using a component that has various states rendered. But unless the engineer knows how to identify that component in the design library, they may not know that the variants are defined for him. So we may not see the hover, the focus state, the stable state, and again, it's going to wind up guessing. So what happens in the end is you wind up with a user interface that's rendered as a component, and the component looks very different from what started by the UI designer. And that is important because it affects usability. So designers spend a lot of time making things consistent, things that line up to the visual eye, and this improves usability and consumability for the end user. Additionally, a lot of times the next step is skipped. So if you're lucky, there's a design review, right? So the designer has an opportunity to look at what was rendered by the developer and say, oh, this is off, this is off, this is off, and they will go through painstakingly, make a list of all the problems, sometimes take photos, sometimes show the as is and how it's supposed to be. They sometimes send them in text messages and emails and in teams. If you're more sophisticated in a team and that you have your design integrated, hopefully they're sending them in issues, right? They create a git issue, a JIRA ticket, or something to address this discrepancy. But the problem is these issues get tagged as cosmetic and low priority. And I understand teams have bigger fish to fry, right? They're like, this isn't going to stop the production train from going forward. And then the next step that should also happen after that is that you should be testing these components. You should be testing the whole UI for accessibility. Now, believe it or not, that doesn't happen a lot, right? Especially if you're working on products that are for the internal employees, right? People are like, that's not that important, we just need to get it out. But you should know that you are actually federally required, or a lot of us are federally required, to not only make accessible experiences for our customers, but also for our employees. So it's a big mistake to skip that step. And then if you do the testing and you identify a problem, well, you have to go all the way back to the design. And the designer has to be informed that, you know, at the end of this life cycle, we found a problem. And then of course, the end user is rendered an experience that looks different than what was intended, the usability is not as good, and there's lots of accessibility problems. So we looked at this and we thought, you know, is this just us? And it's not. These are common complexities. Every company around the world is struggling to build interfaces, right? And it's just getting more and more complicated. You have mobile, you have tablet, you have desktop, you have wearables, you have interfaces on cars, on refrigerators. It's getting more and more complicated. You also have light mode, you have dark mode, and you have accessibility considerations. There's a lot of moving parts there. In addition, designs are changing just like styles, right? And you can tell if an interface is old. You can see if it's from the 2000s or 1990. So you do need to keep these design systems current or they just look dated. Accessibility guidelines are also always changing. And it's hard to just understand them in the first place and then keep up with the changes. So it takes thousands of hours from designers and engineers to build these systems and we're not even building them right. And all of this work for that first stuff that's not generally proprietary, right? There's nothing proprietary about a dropdown menu or a button. Most of the stuff is very common and yet we're all doing it over and over and over again. So we thought, well, what if? So we said, well, what if we could create an atomically designed design system that is rooted in accessibility, meaning that we define the atoms and the molecules, the very core of your design system to be accessible and then that gets perpetuated throughout your design system and we make sure that things are applied in context to be accessible. What if a design system allows us to do things like apply the concepts of reuse, scale, continuous integration, continuous delivery to the way that we create design systems? What if we could automatically renew the components given the designer's input? So if we know that you have an 8-pixel grid system, these are your primary, secondary, tertiary colors, these are your fonts, this is the bevel that you're only going to use, why do we even have to go through that painful process? Couldn't we just automatically render those components for the team? What if we had design and development libraries, a design infigma and a React component library and a CSS library that were all aligned with each other? What if you changed one thing in one place, you could automatically have that change rendered in another? I mean, that would be really nice because I see design systems falling farther and farther out of sync. What if we could update the atomic elements and change the design system in a matter of minutes rather than months or sometimes years, right? What if you just had to change an atom and it got perpetuated throughout your entire design system, what if you changed the designer's library as well as the React and CSS component library? And what if we were able to not only meet the WCAG accessibility guidelines, but we were able to reimagine accessibility and create better interfaces for the people who have accessibility needs? What if users were able to adjust these settings themselves in order to say, look, I'm dyslexic and I'm colorblind, I'm just experience-forming? And what if we did all of this in open source? So we weren't all working alone trying to solve this problem. So let me introduce you to a concept that we came up with with all this what if. It's a concept called unifying design built on something we call film-themed builder. And the idea is that we build an atomic design system married with accessibility from the get-go. And then we use something called theme-builder, which is an engine that will take your input where you define your atoms. So you define all the most basic fundamental parts of your design system. So you design if you're building on an 8-grid system or a 10-pixel-grid system. You tell us what fonts you're using. You tell us what icons you're using. You tell us what you want in your minimum target area for your desktop to be. We know that it has to be 24, but it doesn't have to be higher than that. And we can automatically make the changes when it goes to mobile in the tablet. And then if we allowed you to layer on top of that different themes. So you could have different themes for different departments. You could have different themes for, like I said, for light mode and dark mode. We could also create accessibility themes. And I'll talk to you about what that means in a moment. But then what if we use this logic and theme-builder could create the un-output that allows you to suddenly have your own branded design library, your own branded React component library, and a brand in CSS library. Now we could do that in minutes. And I know it sounds crazy, but we really can. So first of all, I want to address the the topic that I talked about, atomic design. I don't know if all of you have heard that. That is not a concept that I came up with. It's a concept and a method developed by a guy named Brad Frost. He identified that there was a similarity between chemistry and the way we build design systems. Now the idea here is that you start with atoms, the most basic building blocks of design. As I mentioned, those are things like colors and fonts. And you start putting atoms together to build molecules. And molecules really start to render your most basic components, like a button. And then you put molecules together to create organisms, slightly more complex components. And then you start placing organisms and molecules and atoms together to create templates. And then you wire templates together to create digital experiences. Now this is an incredible way to organize your design systems. And I encourage that everyone does that. Now I just wanted to show you a rendering of what these things look like. As I mentioned, the atoms are things like colors. Here's an example of a molecule, a button. Here's an example of an organism, a card that is using a title, an icon, some body text and a button. And then you start putting those things together and we have a template that is using several different buttons, a title, maybe a search bar. And then it's rendering an experience. But what is missing from the atomic design language is the concept of accessibility. So again, accessibility means that people can do what they need to do in a similar amount of time, in a similar amount of effort, as someone who doesn't have accessibility needs. Now this is a pretty high standard for us to be able to achieve. And the golden standard that everybody follows is the web provided by the Web Accessibility Initiative, which provides us with strategies and standards on how we can make experiences accessible. Now many of us are required federally to create user experiences that are accessible. And if that's the case with your application, you are required to meet WCAG 2.1 AA accessibility standards or higher. If you're creating products for the government, that's even higher, it's WCAG 2.1 AAA. And that's even more complicated. But let me just say, it may or may not be a legal requirement for you, but it is absolutely just the right thing to do as well. So there's really four categories of disabilities that accessibility is trying to accommodate for. There's hearing, there's visual, there's motor, and there's cognitive. And there are over a billion people in the world who have accessibility needs. Now the biggest category there, represented by people who have disabilities, are cognitive. And it's actually the area where accessibility is doing the least amount of work to try and accommodate for. Additionally, we should think about accessibility because age is a big factor in accessibility. One in five people in industrial nations are over the age of 65. And as you grow old, if you're lucky enough to grow old, you will encounter these accessibility issues. My parents are 85 years old. They have problems with vision, motor, mobility, and cognitive. My parents are amazing, but it all happens to us as we grow older. And there's also temporary and situational disabilities. So if you just broke your arm, if you broke your leg, if you work inside all day and you're somewhere dark and you come out, you suddenly don't have the vision and the capacity to read things and have the contrast. Parents holding a toddler don't have the same accessibility that they normally have. So there are situational and temporary accessibility issues as well. Now a lot of people ask me, at least you're always talking about accessibility. Like why are you so passionate about it? Well, I was lucky enough to be raised by a mom who was very involved in working with people with disabilities when I was younger. She volunteered at the local elementary school and worked with kids with all kinds of disability issues. And then it was really great that I had a mom who understood accessibility issues in sixth grade. I was diagnosed with my own cognitive disability. So I was lucky enough to be diagnosed with dyslexia and I feel very fortunate that that happened. It was in the 70s and a lot of kids just fell through the system at that point. And I went to a school for dyslexics and it totally changed my life. It was totally amazing. And I think I found out there what I already had observed but had never formalized, which is that everybody with a disability has incredible ability to match it. And, um, sorry. And I was really delighted to see that my, the school that I went to, which is a school called Carroll School in Lincoln, Massachusetts, on their website and their UI, they had a navigation that said the dyslexic advantage. It was really cool to see that they acknowledged that there is truly an advantage to being dyslexic, a dyslexic person. So you see things differently, which is actually an advantage. You see things as stories, which is really interesting. They tend to be really good at proceeding 3D spaces. So you'll find a lot of architects are dyslexic, but they also have a really great capacity to see the bigger picture where a lot of people don't. So I think that's something we should all really think about is that we should be accommodating these people because it's not that hard, but we're also busy trying to do the minimum that we're not reimagining what we could be doing. All right. So let's take a look at the state of accessibility because, again, a lot of people think, I can't be that bad. Like, we're all trying really hard, but here is the state of accessibility. So of all the landing pages, and this is where everybody's putting the majority of their effort, like to make sure to make a great impression on you when you come to their company, 98.1% of companies are failing with at least one WCAG accessibility problem on their landing page, right? And the average person who is not passing the accessibility thing on their landing page is having almost 61 infections on the landing page alone. That's huge. That's problematic, right? So we're really not doing a good job. So, again, let's look at the atomic design through the lens of accessibility. So, you know, the designer may have put a button together and color in itself is not inaccessible, but when you start pairing them together to create components, it's when you can create problems. So this pretty button here in this hypothetical design language does not meet accessibility guidelines. It doesn't have the 3.1 to 1 contrast that needs against the background. The text on top of it doesn't have the required 5, 4.5 to 1 contrast on the button, and it's not meeting the required 44 pixels that's needed for tablet and mobile. So those are three infractions just on a button that now is going to be perpetuated throughout your user experience. You know, then we look at the organism there. It additionally has another problem because the icon doesn't meet the 3.1 contrast guidelines. The simple template, of course, has the problems that were perpetuated in the earlier things, but then they throw in a title, and the title doesn't meet accessibility guidelines. And then again, through the experience, we can see there's many problems. So this is how we get here, and this is how problems just perpetuate themselves through digital experiences. And accessibility and color are hard. A lot of people try to underplay how difficult this is. Now, I know of a company who is extremely dedicated to design their design system, and they hold accessibility to the highest regards, and, you know, they think they're doing a great job, but I can give you a couple examples of where they're falling short. So this is actually from their own design guidelines that I grabbed this, right? So here we have, you know, a blue button, and a blue button that was originally rendered in context of a white or a black background. But they placed it on a bunch of different gray backgrounds, and suddenly it doesn't meet the contrast requirement of 3.1 to 1. So this is no longer accessible. Here's another example, hotlinks. Hotlinks are complicated. So hotlinks need to have a contrast of 4.5 to 1 against their background. Here they pass. They have the 7.03, which is awesome. But if you're going to have a hotlink that's not underlined, it also needs to have a contrast to the text around it of 4.1 to 1, and it doesn't. So, again, this is a company that really thinks they've got it, but it's when you create a component and then you change the context of width on which that component is being rendered. Now, again, you're like, well, how often does that happen? Think about it. If you have a blue button and you put it in your header and it's got a white header, and then you put it farther down on your page, you have a long page, so you're going from white to off-white, and you put it on the off-white, and then there's a section with a beautiful gradient and you put the button on there, and then you put the button in something in the footer. Well, it probably failed accessibility guidelines in four out of the five places that you put that button. So that's just trying to show you guys how difficult it is, number one, to just build a component library that is compliant, and then to render a user interface that is continually compliant. So we had the idea of creating a theme builder that would take your brand input, apply the accessible requirements, and spit out atoms and molecules that then we could be rendered in an out-of-the-box system that we would create in Figma, and it would render an out-of-the-box system, design system in React, and when we layered your input on top of it, you would suddenly have a branded accessible React component library and a Figma library in a matter of minutes. And then we said, well, we should probably start differentiating what we're talking about in terms of atoms. So we started to break down the concept of system atoms and theme atoms. And our mind system atoms work fundamental things that we're going to stay consistent throughout your design library, but theme atoms could be altered in order to create slightly different experiences. So you would have your theme and you could have, you know, and then you would have light theme and dark theme. And I will tell you that trying to create an accessible dark theme is really, really complicated. And that sounds really silly, but creating them in light mode is hard enough. But in dark mode, your white text is now not pure white. It's a white with an opacity of 0.60. Your colors also have to be saturated by 50%. So they don't cause eye strain. Your colors can't get too light. They can't be too vibrant. And they have to pull it all together and still meet those accessibility guidelines and conscious guidelines really hard. All right, so here we sort of display the concept of system and theme being layered. So we start with the theme builder as the foundation. We layer on top of it your branded molecules and atoms. You can layer on top of it then your brand color theme. You have a desktop theme that we will generate and we will also generate a mobile and tablet theme. And those are differentiated because of things like minimum target radius. But we will do all the calculations for you. And then we have the idea that the end user can apply, you know, take control of the UI and apply a light theme or dark theme or apply something called an accessibility layer. And I will get into that. What is the accessibility layer? Well, we started to think, you know, there's a lot that we could do for people with disabilities that isn't being done, that if we use this concept of themes and layers, that we can actually do really easily. So, like, let's say you came in and you said, hey, I'm one of your end users and I am dyslexic. What can you do to me in this user interface that would be helpful? Well, we can actually use a dyslexic font throughout the entire interface that makes it easier for you to read the content that we have. We can increase the line height, which makes it more readable for you. And we can also increase the color contrast of the components throughout the experience. And we can do it with just a click of the button because we're just applying a layer of CSS logic on top of the logic that's already rendering the UI. And then we also thought about users who have motion sensitivity. So there are a lot of users who, you know, are triggered by motion or are distracted by motion and just can't complete their tasks. And you will notice that on your mobile apps there's more and more motion, which can be awesome, but it can also be dizzying. So we thought, well, what if we just put a little switch in there where they could say, I don't want motion. Just take it out of the experience for me. It's honestly not hard for us to technically do, but no one's thinking about it. And then color blindness. Now, Wicked Guideline was sort of developed to take color blindness into consideration. But when you apply, there's like four major types of color blindness that drastically alter the appearance of a user interface. And if you apply a simulation on top of your brand, on top of, you know, with a simulation on top of your brand, you will be stunned by what it looks like for these end users. And it's often not pleasant. And then all the accessibility guidelines that you work so hard to create in your components are blown up the window because the colors are different for them. And suddenly things don't contrast. And sometimes they vibrate, like the colors are awful. So we thought, well, what if we could apply logic that would create a pleasant experience for the people who have those color issues. And it would be per your own brand. So like we would as closely match a pleasant experience using color logic to create an output that's not jarenly different from your brand. But there's things like this that we could be doing that nobody's doing. All right. And then we also thought, you know, sub-brands. So if you live at work in a very large company, you may want to use color to differentiate the different areas of your site. And this is actually a really good approach for usability. It helps people ground themselves in where they are in a site without you sort of just having to use words. So we thought, well, if you had a sub-brand, all you would have to do is, you know, switch the theme. You still have one master design system, but you're just turning on and off different layers and themes. So you're not creating a different design system. You know, it's one design system that everybody is using. It's one source of truth just with different switches turned on and off. And then another thing that we thought of is, you know, we spend so much time building this design system to be double-A compliant. But what if tomorrow you had a client come to you and say, look, we're a government agency, and we love what you guys are doing. We would love to utilize your products, but you got to make it triple-A compliant. Well, for most companies, that would set them back, like six months at least, to go back and figure out how to do that. It would take so much time, but actually applying that logic with something like a theme builder that would make all the changes for you is actually pretty easy. It would be like you just copy your system, you change the setting, and we re-render your design system. So I mentioned in the beginning that there's this concept that what if we could keep them all in sync? And what if we had this idea of a tool chain to do that? So what we did is we looked at some technology that we've been using to create theme builder and to skin these experiences. And so what we did is we used Figma, and then we used a plugin for Figma called Figma Token Studio, formerly Figma Token. And what it does is it applies JSON elements to the design elements in your component library. And that is basically the logic that we used in order to render Figma completely based on the atomic elements that you defined. So in theme builder, you tell us all the atomic elements that you want, we spit out some JSON code, you load it into Figma tokens, and it takes our Figma library that looks like just our out-of-the-box Figma thing, and it totally transforms the entire library in like a minute to all of your theme, all of your atomic and molecular settings. So if you have a 8-pixel border on your button and you're using navy and orange and yellow, it will apply all of that. It will take, create 10 shades of each of those colors in light mode and in dark mode. It will calculate what color text you should have on top of that. It will slightly alter colors if it needs to if there's not an automatic white or black that meets that. We will create gradients that make sense for you. We will create all sorts of different effects that are often used in user interface and you don't even have to do the calculations, we just render it for you. So what happens if you want to make a change in your Figma design, what you do is you make a change, it gets updated in Figma tokens, and if in Figma tokens you push that code to GitHub, you can then push that code to GitHub and then it renders, it can be connected to a React component library that is rendered in Storybook or Chromatic. And what happens for the engineer who's using Chromatic, they get notified that there's been a change to the design system. Now of course you would never do this directly to production, you would do this in staging, but the engineer who's responsible for your design language get notified of the change and then he can review the change, he can test the change and then if it passed all the requirements and all the testing, he can push the change live. Now what just happened there is there wasn't a need for the designer to get the attention of the developers to prioritize these changes, the designer could just go in and change it, he could push those changes to get repo and then they're integrated into staging and they just need to be reviewed. That saves so much time and it saves so much headache and it also keeps your design assets in line with your CSS and your React component assets. The same thing can be true if an engineer changes something in Storybook. If an engineer goes and changes all the buttons to having a 24 year and 8 pixel ratio, I mean a bevel edge and then pushes that to get the designer who is responsible for the Figma file will get notified that there's been a change, they can review it and they can accept or deny it. So again, it's communication going both ways and it's eliminating a lot of pain points that are happening into that design to the development life cycle. Alright so I unfortunately don't have the time to run everybody through a demo of our theme builder but if anybody is interested, please come see me. We also have a GitHub repo with this theme builder product out there that everyone can take a look at. So yeah, and I'll show you guys, I'll share with the links with you guys later. But just to sort of level set on what the theme builder is doing, the theme builder is rendering all the colors that you put in there, you can actually put as many colors into the color palette there, but then you have to pick a primary, secondary, and tertiary color. For every color that you put in, it's going to create 10 shades going from light to dark and it's going to pair it with an on color and as you can see here, every one of those on colors, so the text on top of it meets a 4.5 to 1 contrast ratio that's required so we're doing a lot of the logic up front for you. Once you pick a primary, secondary, and tertiary color application, you then go into your molecules and figure out what color from that primary, secondary, and tertiary color you want to be your button color. We're going to limit it to the ones that pass the requirements that are required for a button, for example. Anyway, there's a lot of logic that we put into that, but it outputs the JSON that I was talking about that you upload to your Figma file and it outputs CSS that re-renders your React components. So if we really look at this concept and this idea of us all working together to create user interfaces in a smarter, more collaborative way, we can definitely accelerate the way that we innovate, because we're no longer just stuck in the implementation mode. We're implementing faster and smarter and now we can spend that time really innovating, applying design thinking to make sure we're building the right experience rather than just rushing any experience and getting it out the door. So again, here on the right you can QR code this if you like. This is our open source project for ThemeBuilder. It's not perfect right yet, but that's why you go to open source. You want to get everyone to help you build your vision. And then we also use the ThemeBuilder in a Finos Global Accessibility Hackathon that we're sponsoring right now. And it's really been an incredible experience. It's the largest hackathon that Finos has ever sponsored. We have over 200 people participating in the hackathon and we have over $30,000 in award money, which is probably why we have 200 people contributing to the hackathon. Looking ahead with ThemeBuilder you know, I think this could be really powerful. There's a lot of things, directions that we would like to take this. Accessibility is not just important in terms of creating web applications. You know, you're responsible for creating accessible experiences in all of the digital assets that you create. So it doesn't matter if it's PowerPoint or if it's emails. You should be creating a web accessible, I mean accessible experience in those tools as well. So what if you could take the logic and it could be integrated into things like PowerPoint other interfaces, tools like Aksure, maybe into Xcode. What if we allowed designers to simply take a picture of a mood board for example and we could automatically pull in the fonts that we identified and the colors. What if you could just take a picture of something beautiful and we could render a theme based on that. What if we could make accessibility bigger than it is right now and we could identify and anticipate temporary accessibility just by the use of your application. We could identify that you're using it differently and maybe we should change the experience. What if we could actually help you identify the fact that your vision is going and we could accommodate the experience as you evolve or evolve. I don't know what to do. As your needs change, we could accommodate the experience. Maybe we could even help you identify the fact that you need glasses. There's a lot of powerful things that accessibility can do. I think we're just getting started and thinking about the cognitive things that we could do for people who have accessibility needs. There's also the idea of mobility needs which I think shouldn't be ignored. There's applications that we use all the time that don't take mobility into consideration when you're using an application to find directions from A to B. What if you got directions and you had accessibility needs but the directions that they gave you on how to get from A to B meant that you had to go down a flight of stairs. There's a lot of things that we could do to improve experiences for our end users. Finally, I just wanted to end here. The other thing I did want to mention about our hackathon that sort of differentiates our hackathon from other hackathons is we actually did open it up to designers and users and developers. Basically, anyone could contribute to this open source project. You were allowed to submit code. You were allowed to present concepts in mural boards or mural boards. You could present them in Figma. You could present them with a storyline. We really didn't want to exclude anyone from helping us to elevate this concept. I definitely encourage all of you as you look at your own open source what your project benefit from design being involved. Design is a really big topic. There's accessibility designers. There's motion designers. There's interaction designers. There's UX, there's UI. Think about whether your project would benefit from design and if it would, what I would say is vocalize this need. Let people know that you would be accepting and embracing of designers joining you in your open source project. Invite and just go out there and attract designers. Invite them to join you. Maybe think about the tools that you're using in open source and encourage the inclusion of different tools in your open source project. Identify and reward designers. If there are designers contributing to what you're doing, make sure they're recognized because that doesn't exist in the open source community at the moment. If we're able to do this, I actually think the impact would be really profound. I think that we will streamline, delivery pipelines. We will provide, bring CI and CD into design systems and we will improve usability for all. We can also reimagine accessibility. So that's it for me today everybody. I thank you so much for your time. I think I'm a minute over and I don't like that.