 Hi, everyone. My name is Amy. I work at Red Hat. I'm a UX design lead in the middleware portfolio at Red Hat. Yeah, and I'm Thomas. I work in Barcelona in the three-scale office. And there I'm the UX lead. And I'm also a manager of R-Time. And I give the work back to you, Amy. Okay, great. Yes, so we'll get going. So our talk is, it's about how we, how Thomas' team and our team has worked together over the last about year and a half to bring together the design of pattern of three-scale into a more cohesive UI using pattern fly the design system. So this talk really is for anyone who has tried to coordinate and sort of look and present a similar and consistent look. You know, sometimes it works out and sometimes it's kind of like, well, it's close. It's close. For us as user experience designers and developers, this is in a way kind of a holy grail. It's something that we've reached for for years. My former company, most UX designers who I talk with, who work for an enterprise in which applications are developed across the enterprise by different teams with different roles, different features, but yet still trying to look like they come from the same place in the same company. And obviously, we want to do that to make the user's experience one that is cohesive, coherent, that makes sense, and that is not jarring when one is switching from perhaps one system to another which is behind the scenes two separate products, but we want to make it look as though it's all one cohesive unit. And of course, that helps when sales teams go out to demo the software. It doesn't make a lot of sense when you're demoing and something pops up that looks just completely different from everything else in your set. So how do we do this? Well, first of all, we recognize what challenges there are. So first, in this challenging enterprise environment, and a few of these things I've already spoken to, many applications that exist already, knowing in a large organization what is going on outside of your group, what even inside your group is going on with different members of the team working on various projects. Teams have a variety of technology stacks and favorite tools that sometimes are religious in a way in terms of their adherence to tools. Legacy code, it's hard to change. It takes time and it's often not favored over new features by the business. So businesses will often, you know, if it ain't broke, don't fix it. And so they will not tend to favor, well, we need to align our UI, our front ends. We have geographically distributed teams, which is a challenge from a communications standpoint. And the teams themselves tend to want to focus on what makes their particular part of the project best in class. So how do we do it? We kind of have two areas that we look at. One is, from an external to the company standpoint, marketing, branding, storytelling that says, hey, this is an integrated solution, and using our product will allow you to work in this product and get your job done. But from an internal product design standpoint, we use what are called design systems and obviously communication amongst the teams. Now for Red Hat, which is an open source software product, open source projects, by their very nature, are community driven. They're highly innovative. And they rely on different technologies, whatever the community is working on. They're not necessarily bound by the need for a common look and feel or a common behavior. But when those projects are then productized as Red Hat products, we then have to grapple with how to make these look more, look and feel more the same or the more similar, particularly when actions are similar. So for Red Hat, it became very obvious that we needed a system, a design system to help us to take those kind of projects that are out there, community driven, and create a more common look and feel. So what is a design system? A design system at the highest level provides guideposts and tools for creating a consistent look and feel. They come with behavior guidelines and documentation. They include visual elements like fonts, icons, colors. They provide code elements, reusable HTML and style sheets and in some cases frameworks, JavaScript framework. And the design systems are really are living entities. They can evolve, they do evolve over time. And so as many of you have probably heard, if you attended any of the UX talks yesterday, our design system is pattern fly, pattern fly design system has been around for a few years. It is supported by a team of designers and developers. It is community based. It's open for reviews, feedback and contributions from the community. It contains tools that do make the design process easier and development easier, including a sketch symbol library, HTML and CSS sample code, demo code, ReactJS framework and artifacts. And the system is modular and has built-in accessibility. So I wanted to just take a step back and talk to you a little bit about some takeaways from a survey that I read that was done by Figma, which is a design system company. The survey was conducted last year, included about 500 participants. They wanted to see what kinds of themes were emerging and best practices around design systems. The practitioners who they interviewed came from a variety of industries, as you can see here represented by their company logos, from finance, education, retail, travel and others. They used a mix of open-ended and multiple choice questions and produced a document that I linked to at the end. And I wanted to just reference a couple of these outcomes because they helped to frame the rest of this talk. So the first big takeaway is that design systems are still in their infancy. The top chart that you're seeing describes the current state of design systems for the practitioners who responded. And the bottom chart represents an aspirational where we would like to be. If you look from left to right, the black is representative of stage one. It's an undocumented effort. The dark purple, stage two, is documented but encode only. The kind of orange mustard color is a dedicated design team and then the light lavender is a system that's publicly available. So the big takeaway here is from the top chart about 60% of respondents currently have undocumented or only documented in the code design systems. But if you look at the bottom chart, about 80% that orange and the light purple bar would like for their systems to be driven by a dedicated team and to have documentation and to be publicly available. So in the case of pattern fly, I think our system is in its second major public release and it features a dedicated design systems team and documentation to support the system. The next question was what stage did you start building a design system? And the key takeaway here is that design systems usually arrive after products are built, whether they're derived from the products or not. In our case with pattern fly, it wasn't so much a product or a project within Red Hat. It was more of a built off of the bootstrap framework. And so that was how pattern fly had its beginnings and for several years relied on bootstrap. In recent days or in the past year or so for pattern fly four, we've decoupled from bootstrap. So that is going to be helpful to us in terms of innovation, flexibility and not being tied to that, to their updates. This chart looks at what are the artifacts that are part of a design system and almost 90% of the respondents report using components and symbol libraries. About 83% report that their design systems include a style guide. And around half also mentioned content guidelines and design principles. One thing that's not represented on the chart but that's in this article is that several of the respondents wrote in answers about code artifacts. And that seems to be an area where people are really engaging to provide more to developers in terms of what they need to actually implement these design systems. So things like React and Mixins and token repositories and iOS and Android artifacts and such. So I'm happy to say that pattern fly is really pretty far along in all of these areas and is also concentrating on code availability with a React. JS kind of gold standard implementation as well as the HTML and CSS libraries. And this was the last takeaway from the survey that I thought would be interesting to this group. And the question is, does your company let people diverge from the design system? And it does seem intuitive to me that design systems must be flexible and be able to breathe and grow over time depending on how they're used. It really feels pretty obvious that a rigid adherence to an absolute design standard for the kind of software projects that we are engaged in will not allow us to grow and innovate. But at the same time, we have to balance that against how it is often challenging to work with teams where there's particular opinionated views based on individual preferences. And so we do rely at Red Hat on meeting this challenge by leaning on our research, our user research team, by using the pattern fly design system and obviously being willing to discuss and work together in teams and evolve the standards over time. And then of course, the design system alone can't give you what you need. The enterprise, when we talk about the enterprise, it's human at its core. So as I mentioned before, and this is an image showing us in a typical meeting, well, maybe not so typical, we have a special guest in that meeting. But we do spend a lot of time discussing and because we're geographically distributed, we use online systems that allow us to communicate and conference calls. And speaking about and talking about how to evolve products so that they will be more consistent. So that is, as I've described, existing products alone are challenging within Red Hat, but when a new company is acquired, the challenge becomes even greater. And this is where I'd like to invite up my colleague, Thomas, who is the UX Lead and Manager with Red Hat Three Scale API Management. And Three Scale was acquired by Red Hat in 2016. And Thomas is going to talk to you about some details and specific challenges that his team faced working together with us trying to integrate the Three Scale system with ours. Okay, thank you. So yeah, Red Hat Three Scale, before we were bought by Red Hat, Three Scale started in 2007, was founded. I joined the company in 2013 and Red Hat bought us in 2017. So we joined as the duckling duckling. I'm aware this is not really a duckling, but you know, this image was rights free. So I thought it was funny. And anyway, as ducklings always become beautiful swans, so it doesn't really matter. But yeah, so we started like our company was like pure sauce and give you a little bit of context. Like Three Scale is about API management. So it's like our customers have an API and their customers want to use their API. And we help them with everything around their API. So like a developer portal has money for your, for usage of your API and manage the keys for the applications, et cetera, et cetera. And traffic some context. So we were a sales only company. So our first year and a half after Red Hat bought us was spent making an on premises version of our software. So we could at least also be sold as part of the OpenShift package of the integration product. But still we were a little bit of the like the ugly duckling in the sense that we looked like this. Now we did our best there to integrate with Red Hat by just saying Three Scale by Red Hat. Very small. And basically it was it because we didn't have time for anything else at that moment in time until Amy saw that. Until basically the time was there. We had an on-prem product. It was working and like, you know, we got feedback from sales. And like every time they showed Three Scale, it was like the customers like, okay, that looks like a different, completely different product. How's that? So we needed to integrate more with the rest of the integration product, which looked more or less like, for example, Fuse. No, you could say it. I mean, it's white and black. So that's that's good. There's some blue. That's good. But there's some things missing like, so we have our navigation horizontal there at the top. And we have some black bar, but it's thinner. We don't have our product name at the top. We have it underneath it. Right. And so there were some other things like this was our sign in page at that moment. Very minimalistic. And this was the Fuse sign in page and not just Fuse, also the other integration products. And they all run within OpenShift, which also looked the same because it was also using Pedernfly. So we had to get our product onto the Pedernfly train with a limited number of people with a limited time frame. You know, we couldn't just put, I mean, the three scale application is it's many, many, many pages. We don't have an official design system. We have, I mean, our code is not like one big chaos. There is organization to it that there is no Pedernfly. There's no design system. So there are rules and there are things that we have like things like to do, remove this crap, but be aware that you have to remove all the Diff.write and similar shit, this kind of stuff. So, you know, we had to be careful there. So we were using Slim for the templating of the HTML. Well, that's not a problem by itself. On the JavaScript front, we were also a little bit all over the place because we tried different things over the years. So we have some normal JavaScript. We have some coffee script. We have some ES6. We even had some more things. Okay, so we looked at it again. We thought about some quick wins. We changed some colors. We thought, okay, the Pedernfly is using the full screen. So that's going to be like this. Okay, that was not much work to get that done. But then we still had this problem. Okay, how are we going to switch to what should we try to do? What's possible to do within a minimum amount of time to make people feel, to make our customers feel like they're using just yet another product of the integration portfolio. So we thought, okay, the most in your face things are the navigation and the sign-in screen. So that's what we focused on. But then a little step back. Before that, we were already thinking about our navigation. Like I told you before, we do API management. We started with customers that only had one API to manage. But there were more and more customers with lots of APIs to manage. And our navigation was problematic in the sense that if you go to your APIs, then you could click on an individual API. But then if you want to have the analytics of that API, you'd have to go to analytics and then find that same API. You can imagine that that kind of sucked. What we wanted was more of an API-driven navigation. So within an API space, you would be able to do everything related to that API. So we already had conversations about that in 2016. But we just didn't have time to do anything with it. At that moment, what we decided to do was combine that 105 vertical navigation with a pretty deep reorganization of our navigation. And that's what we did. And that's how we tried playing with that. The content is still not really there. But to have an idea of what that would look like, because we had also two layers of navigation within Panerfly that would be like this. And then we found out we have a problem. We don't have breadcrumbs, meaning that if you'd navigate to the telegram here, then that would disappear again. So the person being on that page would have no way of knowing where relative to the other pages he was in the system. At that time, we also knew that Panerfly 4 was going in a direction where there would also be vertical navigation, but the second layer would be underneath it, which would be better for us, because it would always be visible. We tried. We tried breadcrumbs, but that didn't work. That was too much work. We couldn't do it, so we closed it. We didn't merge it. And we went here. So we borrowed a little bit of Panerfly 4 having that navigation, that secondary layer underneath in the same vertical bar, always visible, so that's another diversion that we did. There is no, what's it called, hamburger. You could not remove it, because these are our breadcrumbs, basically. That was just pragmatic about implementing Panerfly. Okay, let me see. So that's what we did. And it worked out pretty well. And we changed our sign-in page to look also more in line with the other products. Some takeaways. So that's what we did. Like, start with the most in-your-face differences. I'll leave the rest for later. And the second one would be, you know, that's also another thing. I'm not sure if this is felt in every project that tries to adhere to a visual standard, but we used a visual alignment to also actually make other more structural improvements to the product. When we launched this, we could tell our customers, you know, we made it different, because this, this, and this, and this, and it's not just a different loop, but there's a reason to it behind it that helps in our, especially at the sales level for our customers to appreciate the changes. And, well, implementing spirit, not in letter. So, yeah, right, we should have had that hamburger icon. We should have had, if we do it by the letter, it's not correct. There are, it's not pixel-perfect, PanerFly 3 at this moment, it was not. But that was not our goal. Our goal was customers seeing one set of Red Hat products and feel good about that, right? Oh, sorry, I'm going too fast. So then we thought we were done. And, of course, then the PanerFly team came with PanerFly 4, so we could start all over again. No, then we had to find a way to get PanerFly 4 to work. And that's where I gave it back to Amy. Thank you. Right, so, of course, then the next version came along. And we, similar to how Thomas decided to, instead of just adding the PanerFly 3 UI elements on top of the design, instead of, he actually rethought the IA of his application and where things belonged. We also expanded our project, instead of just everybody moved to PanerFly 4, what we're really doing is expanding on not only 3 scale but other open-source projects that are part of the Red Hat Agile integration product line. And so that includes Sendesis, open-source upstream project, which is Fuse Online, allowing you to easily create integrations using camel routes. Epicurio, which is an API editor, 3 scale for API management, and Kafka and ActiveMQ for messaging. So our team since about February, I was looking at the document, we, the UXD team along with some of the front-end developers from these various projects and products have been meeting on a regular basis to talk about where are we now to sort of get a lay of the land, where is everyone in these projects in terms of PanerFly adoption and PanerFly 4 adoption in particular, and how can we all move in a similar direction around the same time and around the same time frame. And so that team has been meeting, it's a virtual team from across the organization, and we've basically laid out kind of a roadmap for moving ahead. We have successfully migrated all of those applications that I mentioned to using the PanerFly 4 designs for their Masthead, which is that header bar, the vertical navigation, the about page, and the log-on page. So as Thomas said, the in-your-face parts of the system are what we commonly refer to as application Chrome. So it's the kind of surrounding pieces. So this particularly helps with demos. The sales team and the product teams really like this because if someone's demoing and they're just flashing things up in front of users and switching between, the audience is not necessarily looking at all the details. So we figured if we do that first, we're kind of showing it's a good faith effort. We're moving in that direction. Now we're starting to dig into the content areas of the application. And so our next, the part that we're working on actually now is looking at lists, cards, and tables because what we noticed is that those three components are a good part, maybe almost 80% of what we show in those applications. At the same time, we're looking at some kind of best spoke or unique elements from the different applications to determine can these things be contributed back to pattern fly? Are there patterns that are existing that could be better used instead of those and so on? And then as we move forward, we plan to look into even additional content areas like toolbars, fonts. There was a big font change from pattern fly three to pattern fly four, buttons, forms, and other UI elements. I wanted to show you a couple of examples. You'll see the spirit of the closeness of these, if not the letter. So this is three scale API management right now, the main page, and this is Red Hat Fuse Online. As Thomas pointed out, there's no hamburger here. So we're not quite there yet, but we're moving in the same direction. The Red Hat logo is there. The Red Hat itself is there. The menuing system and the masthead. Same with API designer, which is part of Red Hat integration and it doesn't have a left nav. This is just the welcome empty state page. And then these are a couple of examples of the about screen for Fuse Online, Red Hat API designer, and AMQ console. I included a couple of links here at the end. If you're interested in learning more about pattern fly four open source design system, please visit that link. There's lots of great information there. You can contribute at that location, learn about contributing to the project. There's a link here to the Figma survey that I discussed earlier, and also a design systems publication if you're interested in learning more about design or design systems that is there on the list as well. So thank you very much, and Thomas and I would be happy to take questions at this time. Thank you. If anyone has questions, I'd like to ask that you raise your hand and try to move toward the aisles if possible so that we can just quickly get the mic to you. Just for clarification, one of the components you said was content guidelines. Can you elaborate on that? I'm a writer and content means one thing to me. I'm not sure it means something different to you. Yes. We do have content guidelines. We have a content management person on our staff, the UXD department who does a good bit of writing, and on the pattern fly site itself, which I'm not sure I can get to because of this crazy thing, but you can look it up. The content guidelines include writing for UIs, things like voice, consistent voice terminology, things to avoid, that sort of thing. They're pretty extensive. I think she did a great job. If you haven't seen those yet, if you go to patternfly.org to that last link that I included, which I guess I could try to do. Here it is. Writing voice and style guide. Feel free to explore those parts of the website. Thanks for the question. Any others? I have a question if we can allow that. You spoke a little bit about how code artifacts are an increasingly important part of design systems. People want to integrate more of that into their design systems but having a common JavaScript framework is important to that. I know that part of the transition from pattern fly 3 to pattern fly 4 was settling on a single design, a single JavaScript framework. I don't know if you could possibly speak more to the importance of that and how that ties in. Did you catch the... I'm not sure I cut all the details. How we settled on React. The question, sorry, it was how you settled on React and how you determined that having that one framework as opposed to a few different frameworks was important. Yeah, I'm not part of the pattern fly team, but I'd say that the core of pattern fly is not really React. It's a separate GitHub repository so you can only use the HTML, CSS. And then, yeah, I'm guessing that it's about, you want one effort to be really good and not three different efforts to be half-half. And then you can still discuss if React is the right choice and I'm sure there's people that would say yes and there's people that would say no and maybe five years from now when Facebook is no longer here. It will be all different, I don't know. Yeah, I mean, I agree with that and I don't know if there's someone here from the pattern fly team who could speak to it more than I can. My impression is that it came down to a matter of resources. We do have a design and development team dedicated to pattern fly, but again, there are only so many and the need is great. And I think there was a good bit of surveying done in the beginning, is that right, Rachel? A good bit of surveying done across not only our enterprise, but across the industry to kind of come to that agreement on React as being kind of the gold standard framework. But again, like Thomas said, there's the core library which contains all the HTML and CSS that is available to you. Okay, great. Thanks, everyone.