 All right, welcome. Welcome everybody to my presentation on navigating our design system. It's a bit more of a story around GitLab, so I'll go on in that. First, let me introduce myself and thank Open Source Design for hosting me and my colleague for our GitLab talks on Open Source Design. I'm a UX designer at GitLab, which means I'm responsible for both UI and UX design. A little bit of product comes in there as well. My main responsibilities within GitLab are focused on continuous integration and deployment on our Web IDE initiative and a dev operation stuff. So it's a little bit more technical, which is I think pretty suited for this conference. It is though not the part that I'm going to talk about in this meeting, it's just responsibilities. So first, a little bit up on what is GitLab, because maybe not as everybody's familiar with it. So who is familiar with GitLab? All right, nice. Okay, and who actually uses it? Actively, so all right. So I'm going to keep it real short because we're a lot to talk about. But in short, it began with a Git management system to let developers work online collaboratively. Eventually, it grew out to a single application for the whole development and operations life cycle of whatever you're developing. Be that an application, mobile app, whatever that may be, you can go from idea to production as fast as possible. That is the goal while everybody can collaborate, so to say. Some note, which is not always note to everybody. We're focused on enterprise, but we have a GitLab.com, which is our SaaS hosting similar to what GitLab is. But we're also very focused on instances. So you can run your own server with our software and nobody can get there, except for yourself and whoever you'd invite. All right, let's get some. So where and why? What is the journey? This talk will be about the journey, about how we arrived at our design system. Why did we do it and how we got there, so to say. GitLab is being built or is built on an iterative development philosophy, which means you ship small and fast, and as much as possible. Its faith is boring solutions. That sounds boring, should be boring, but it is important because boring solutions are already solved, like they proven themselves, which means that if you use a boring solution, you can skip ahead. Then you can focus on the important things, which I'll come to next. So, what is holistic design thing, right? We have iterative design philosophy or development philosophy, but if you're going to improve on your application in small tidbits, all around the application, it's going to grow into some monstrosity that was never intended in the first place. So, as symbiosis between different departments, so say UX, say products, say development, upper-level executives are needed in order to make your goal or reality, which your application or product, whatever you're building. So, for example, nice. Would be nice if it turns on. Okay, I have help. Yeah, it's all right. You have like. All right. All right. I should have thought about that. So, if we keep it short and really focused is product sets, protect vision, capacity, scope and customer needs, so to say, so that we're going into direction we want. But design and UX, which is what is called within our organization is what enables product and development to reach that goal and to steer that direction by if necessary. And then we're going to go to scaling design. So, to paint a picture of the UX team or design team within GitLab, where eight people, one of them is sitting here inside the room, which is one of our UX researchers. There's another one. But apart from that, we have five UX designers and one manager who's managing the whole team. And compare that to 238 people total in a complete company, which means there's a division or a balance between those teams that need to support each other. So, scaling design is needed. You need to be efficient. How can you be as efficient as possible and have as far reaching consequence because of your design decisions as you want? So, spreading design thinking. This is the pillar of why design is not always as efficient or as conclusive within an organization as you would have wanted to be. Like some departments aren't read into it or aren't being told what design stands for and what it's trying to achieve. So, spreading design thinking is vital in order to get to the point where we can introduce a design system which will eventually create the room or make design efficient throughout the entire application and company. So, what did we do? We started with a use case. It didn't explicitly happen that way, but I think if you look at it afterwards, it is that way. And our use case was navigation redesign. It's a revamp of the navigation which is felt throughout the application. Every department is working in GitLab inside our own application to manage both the project as well as the code up until environments and prediction and that is life for all our users. So, tackling navigation was felt throughout every department that it was. If we did a good job, it was a good thing. So, it meant that our thinking was correct. So, why do we need this? Why do we need design thinking across different departments? Why does development need to think about it? Why does product need to think about it? It means that they can think along and we can create room and resources, eventually allocate resources to set apart to build the design system we need in order to scale and design further and make our decisions focused on design decisions which have not yet been made. Don't repeat yourself, in other words. All right, so UX research, which is at a pivotal point within this goal in this journey, so to say. Why do, I mean, my colleague already did a talk on UX research usability testing this morning. It's funny, I'll reference it right there. It's, I believe, been recorded so you can watch it later on if you haven't catch it. But UX research pinpoints and solidifies and ultimately verifies the decisions we can make in design in order to know that we're on the right track. And we needed that to come to a good solution with our navigation. Let's see, so this is an old screenshot of our application, right after a little bit of change because many people may yet still be familiar with the sidebar. It has been reintroduced but at this point of the screenshot it had been changed to a dropdown and this led to all kinds of confusion and I wanna focus on three aspects. So we have the dropdown, we have the sort of like the breadcrumbs in the left upper corner and then we have the horizontal bar that describes some sort of contextual navigation. There's some intermingling and it created confusion that came at least that became very apparent. I mean, we have our thoughts and feelings but it became obvious through our usability testing so to say. So moving on to the new navigation, we see that we have our top bar which is purple. I'll get to that in a bit. The breadcrumbs have been separated and we have the sidebar, right? And this is like a clear division between contextual and global navigation, contextual navigation meaning that it is navigation only available on the current context. So simple, I can answer any questions at the end of the presentation because I need to skip a little bit along to get everything in. Let's see, it's worth mentioning that we implemented this feature with a feature switch. I mean, tackling the navigation of the entire application is quite a risk. You want enough testing and eventually also a lot of quantitative testing along with qualitative testing to make sure everything has been up to not only beta but like a stable setting for your change and implementation. So we had a feature switch which means which meant you had to go into preferences and turn it explicitly on in order to test it out. All the kid lab employees were of course doing that because it was from the start a big improvement. Let's see, so great success, we had a win. We had a successful proof of concept and design thinking was expanded within the company. But then, then it's only the start, right? We're not yet at the design system even. So let's see, there's so much more to do. Let's see at what is in the application. There's a lot of inconsistencies, conflicting messaging, more confusion which was becoming apparent outside of the, in the UX research. So we need to focus on those important design decisions. Scale design, spread design thinking but eventually scale design. I'm gonna move a little bit ahead. So UX, UX research is cost time. So the problem statement is how to let UX researchers or designers focus more on meaningful design decisions and essentially build on top of previous work, right? You don't wanna repeat yourself that is what scales design. So documentation, as many of you probably know, GitLab is a fully remote organization which means everything needs to be documented. Everybody's in different time zones and you don't wanna call up, you tell it earlier in the night and say, hey, how does this work, right? So you write it down and everybody can read it much faster. So the design system, what is a design system? Essentially, it's a documentation of your design decisions. So simple, isn't it? How far you can go along with that is of course up to you. Eventually it will make with, it will make your code-based dryer and it will make you focus in on individual elements, right? So you're beginning with buttons or fields, text fields, think of switches, checkboxes, the most simple, elementary things that are in a design system need to be thought out first because everything else builds on top of that. Along with that, and that's important. I'll continue on. Along with that is important that the documentation is along there with the visuals and the actual stuff to be used within either your tools or in your code base, which means that it needs to be, the why needs to be documented. Why did you came to this decision and why does it look like that, right? So why, how and what? Increase design thinking, resources, and where should you eventually start, right? It's such a daunting task. Design system is easily said and done, but where do you start? And that's actually simple because design systems from nature cut things up in small little pieces, which means you can pick a piece and begin there. Teams say why do we need it though, right? They're already functioning without one. Like, why do we care? We care because everything comes eventually consistent. It will increase efficiency in the end, but it needs an upfront investments, I would say, to reach that goal. We created a design thinking in order to make room for this decision in those teams. All right, where to begin? I know that we use Brent AI. There are a plethora of tools to use. Eventually, it all comes down to the problem. How can we work together as a design team? Design is mostly not a product, the product is, but in this case, the design system is the product. So how do we work together on a design system that we can use together? Brent AI solves that problem for us, but I think the time will be wise and we'll find out what the best tool eventually will be for you. And everybody has different needs, right? Let's see. So we're almost there. I'm gonna talk a little bit about this. Added molecules and organisms, how to cut down your design system. It's pretty simple. Addems is you can go further down. It's the smallest bit, right? So think of backgrounds, think of borders. Eventually, you'll go up to molecules, which are buttons. They make up a border, they make up a textile, and include a background in order to make up a button. And eventually, you can include that in the organism. Think of info cards, headers, all sorts of things. These are the most extensible, so to say, and the most different. So direct wins. We chose to start off with ourselves. Good change begins with yourself, so that means we could start with our own design tooling. How can we implement all those different styles and we could begin working with them immediately for the current sprint or release, whatever you're working with, to immediately make use of that. So direct win is always nice to have. We document it long. Essentially, you can boil down to many manual per element. How do you use this button? When is this text field used? Essentially, those are the questions you should ask and document the why, the how, the what, and especially what to do and what not to do. How to not use a style is pretty important to be included. So eventually, I'm almost here at the end. I know we're a little bit over time, but it needs to be flowing into other departments, right? With development, which is most important because that will get it into the application. They will be involved and will get the design elements into reproducible components that are inside the code base that will eventually be copied and reproduced all throughout the interface, making for a consistent interface in the end. All right, let's see. And document along, because otherwise it will be very hard to maintain. Along with every merge quest, see if we update the documentation because otherwise you're gonna have them out of sync, which is gonna nullify the use of your design system. Let's see. Should be going to the next. All right, initial releases soon. It will be on design.gitlab.com. It's not yet on, but it will be one of these days. I believe 10.05 or 10.05 release. It should be at, we're at the end of phase one, so it should be released soon. You can check it out later. I will say in a few weeks that you can check it out. So what can we take from home from this? What is important for you guys is essentially how bigger your organization or group becomes. The more important a design system becomes. You wanna scale your designs. You don't wanna repeat yourself. Everybody's talking to different people. There should be one single source of truth which everybody adheres to, so to say. Don't repeat yourself. Introduce more and better design thinking throughout the application. This is, I think, essential to get the room and resources allocated to get to this state of your design system. And UX research, get your data, solidify your arguments. You need your arguments to say to upper level executives, we need money in order to do this. In open source design, it may be different, but it still essentially adheres to the same logic. We need people, we need resources, we need development to become interested in, hey, this will deliver, this will get value. And translate the why. Why do we do this? Over and over and over again. And then I have some links. I'm at the end. Check them out. I will share the presentation after. And are there any questions? This is the link for the presentation. Thank you. Yes. I do have a question on your memes slide because using GitLab for years, I was kind of annoyed by the navigation jumping laptop laptop. How do you know if it was a success where it is now? So do you collect data, do you get feedback? So the question is, how do we rate success if our navigation redesign was successful, right? That does various things. Because we had a feature switch implemented, we saw throughout the organization that people preferred the new navigation over the old. I believe we also had research, yeah, three rounds of research in there. We got some quantitative research results out of analytics to prove it, that certain workflows were going faster, less clicks were needed. My colleague has better answers to that. So perhaps he can tell you later more after the meeting. Is there? All right. Design review process for auto designers, annotated auto designs, like in code review? So the question is, how do we review each other's work across design within GitLab? So there is, there are multiple things, I think. All our communication happens within issues, tickets, whatever you wanna call it within GitLab, which means development, designers, product managers are all involved in initial problem statement of a new feature or improvement. Within that process, the designer comes up with multiple mockups. Almost none of the time the first mockup is best. Requires some revisions. And often another designer is invited to say, hey, what is your second opinion on that? Apart from that, implementation goes on. UX needs to be reviewed by both product as well as UX in the eventual implementation within a merge request or approval request, whatever you wanna call it. And of course, if we are not sure enough about our decision, UX research comes into play to solidify which way is the best one to take. I think that concludes what we do about that. All right, thank you. Thank you.