 Hi everyone. Thanks for joining today's webcast. We're excited to have you join us. Click housekeeping items before we get started. This webinar is recorded and we'll share the recording over emails to everyone who registered. We'll save questions for the end of the webcast, but please feel free to type in a Q&A whenever you have one. It's located to the left of your webcast console and can be hidden or pulled up using the button at the bottom. Okay, let's get started on today's webcast. My name is Emily. I'm a content marketer at GitLab and joining me today is Allison, our UX team lead, and Sarah, our UX researcher. I'll start with a quick introduction of GitLab, then Allison will explain how the UX team makes design decisions and prioritizes the many different streams of feedback they receive. Sarah will chat about our UX research efforts and share how you can help. Finally, we'll close the session with a Q&A or we'll be joined by additional UX team members who can answer all of your questions. GitLab is the integrated platform for the full software development lifecycle. It's built on top of Git, the leading version control system. Git allows developers to store a local copy of their source code, propose changes to it, and share those changes with others. We help you create great software by strengthening and integrating your source code management, code review, testing tools, and deployment process in one platform. A unified experience across the development lifecycle helps increase developer productivity by reducing the number of times your developers have to switch from one platform to the next. This ensures everyone on your team is more productive and more collaborative, providing the most efficient approach to software delivery. The UX team is integral to the product by designing the interface, responding to feedback, and helping fit new features into our understanding of the needs of all users. Ensuring that all members of your team, technical or not, can communicate and collaborate. Because of the expansive nature of our product, our UX team routinely tackles a series of unique creative challenges. While most other developer tools only focus on one aspect of the lifecycle, our UX team has worked to piece together all the tools we ship with GitLab in one package. If that weren't enough, this is the jigsaw that the UX team re-navigates for our release on the 22nd of every single month. Finally, they have to design for all technical levels and ensure that the product remains user-friendly for everyone from developers and PMs, admins, and managers. Even our marketing team uses GitLab to create materials like this. We understand how important UX is for the adoption of new software, and we want to make it as easy as possible for your team to start using GitLab right away. As your needs change while you're using GitLab, our UX team has their ear to the ground for each monthly release, and is eager to hear about your use case. For more on how they work, I'll hand it off to Allison, our UX team lead. Thanks so much, Emily. Hi, everyone. So to get started, I wanted to chat a little bit about how we make design decisions here at GitLab. And so at every stage, we have to carefully think through why decisions are made and for whom we're making all these decisions for. We do have a number of methods that help us do this, you know, all kinds of research and testing and surveys. We also work really closely with our internal developers, as well as carrying on a constant conversation with our wonderful community. One of our major challenges, as a lot of UX people might feel, is decoding what people say by finding what they might actually mean and why. Verbal feedback is super helpful, but sometimes it can be better for us to really watch user behavior or watch how they've set up their repos and projects. And so our research will really help us see where the objective challenges are. We work hard to dig beyond the surface level feedback. A lot of people have easy design fixes to propose, but when we look at these, we need to think about the impact of every single change on all our various user groups and also how these changes impact our larger goals or vision for the product. Easy design fixes sometimes are just kind of solving the symptom of a deeper problem. And so it can be very helpful for us to watch and ask questions and listen to make sure we actually understand the real problem that is coming to light. And so this can often lead to a win-win situation, as it can help us create even better solutions than originally proposed and it aligns better with our larger design system and principles. And so in addition to all this, we work with nearly every team at the company of GitLab and carefully triage all the issues and requests that come in. We incorporate the perspectives of our management team, support team, sales, and internal developers. And we do this every single month for our release on the 22nd. One of the things that makes us pretty unique is that we use our product day in, day out for our job. A UX designer or researcher who works in e-commerce, for example, might very well shop online regularly, but it's unlikely that they only shop in the store that they designed or that they spend their entire day in their own product. And so this gives us a very intimate understanding of how the software is used. It does empower us to also become users with opinions. But it forces us to be extra thoughtful about removing our own bias from our evaluation of the UX. We take it very seriously that we need to represent all opinions and not just our own. UX is about the calculated decisions and the logical analysis, not just anyone's idea about what they like best. So we naturally adopt a sort of split brain approach when using the software and observing the behavior. We have to emphasize both as users and as technical experts. We also work very closely with engineering and products. Being a remote startup, one of our rather unique challenges is building a shared vision and perspective for our user experience while we are scattered across the globe and across all the features of the product. We're working hard on this by documenting everything that we can in our UX guide, which you're free to read through and let us know what we're missing. But more and more of the industry is becoming remote. And so we're excited to be experimenting with different ways to stay connected and work through these kinds of problems together. And we believe what we can learn by doing this will be increasingly valuable to other companies. So we navigate our relationship with the product team by understanding that they are both users and builders, too. We also have to translate their feedback and their ideas for features using the same methods we use for ourselves and outside users. We're all part of the same conversation just as developers, but we need to bring in the different birth and perspectives to represent. Our center challenge is very common and well-known to all those in the UX field. And it's building something that satisfies and works for all kinds of people. So at GitLab, this means bringing something that's inherently technical and functionality that was originally designed for developers. It's a place where it works well for product managers and marketers and everyone who needs to use it. So one of the recent examples of this is around this feature of resolvable discussions. So this feature comes from a merge request and allows people to have active conversations about a piece of code with a back and forth until they come to an agreement. However, we realize that we could pull all this functionality outside of the realm of code when you edit plain text or even when you're having a conversation. There are particular moments when you have to push for an agreement. So moving this kind of functionality beyond code brings more value to more people, you know, such as people working in marketing or legal and makes everyone more productive. So in this way, we can help influence decisions about which features to work on next. So in general, we do a lot of listening, watching, and learning about how the project is working and how people want to use it. We also have to be very sensitive to all the different ways of working. We always need to balance all these different perspectives, the enterprise needs, the community needs, and our own values as a company. We're definitely opinionated and we have our GitLab workflow, which we use at GitLab as a company. But we do understand, though not everyone works the way we do, some of our company's values, for example, extreme transparency, need to be made optional for users and other companies. For example, when we think about how permissioning should work, things that we care about or don't care about is very different than other people care about. And so in addition to this, we also build things that we ourselves don't currently need. It's true that GitLab has grown credit a bit in the last year, and we now have 40 plus developers. But we know there are teams out there with hundreds to thousands of developers working towards a common goal, and we want to build GitLab to support them. And so there are many features that I geared towards helping manage these larger teams trying to achieve huge amounts of work. These are features such as merge request approvals, waiting of issues, time tracking, that we as a team in the company have no need of. And so we find it very important for us to keep building out these features, though, to fill out our idea to production vision and help large companies map their process to the GitLab workflow. Thus, I'm going to talk a little bit about how we balance feedback. So as I mentioned, we listen a lot and we make sure to keep up steady communication with a lot of people. And so we get a lot of feedback. And in order to keep up with all these monthly releases and figure out what to deliver in terms of the minimal changes, we need to prioritize and amplify some versus. So we adjust issues in a particular order. First and foremost, we really care a lot about our enterprise customers. Our support team is super vital to helping us understand what our customers need, how they're using the products, what challenges they're running into. The outside community is next in terms of who we love listening to. We love seeing how people work differently with a product. And that really kind of pulls us out of our bubble of our own work style and process. And finally, we love working with the developers on our team. They know the product inside and out. They're opinionated, passionate, and wonderful to work with. They're constantly balancing all the feedback as it comes in. And now I'm going to pass this off to Sarah. Hello, everyone. I'm Sarah, GitLab's first UX researcher. So what do we want to learn at GitLab and how are we learning it? Well, we've built and understanding of who I use without and how they work. We get a lot of great feedback from the community. That is really useful, but we want to make sure that we are capturing the voices of all our target users. We're developing personas that will allow us to relate to different types of users and subsequently predict their behavior. This is essential for our key challenge of creating a unified experience for teams big and small, so that they can stay focused on their goals. You can learn a bit more about this in my recent blog post for GitLab. The survey, which you should all take, has designed some of the similarities and differences between how users use GitLab, dependent on their organization size and role. It will also help us to confirm or disprove a couple of series I have, such as whether using GitLab initially for hobby projects increases the likelihood of using GitLab for work-related products with a later date. I'm also really interested in hearing from people who don't use GitLab or even Git, so I can understand why you make a say using a different form of source control or perhaps the challenges you are facing in convincing your organization to move to Git. What will this help the community decide on in the future? Well, it will help us to make sure our UX goals and vision align to what our users need. It will help us decide on both the large directions and small details that confirm using the experience and functionality in the right direction. We believe the results can be valuable across the company. UX looks very closely with the front end and back end teams to build GitLab, so helping them understand our users will help us work as a team towards a shared goal. The products and marketing for those products should also feel related. Whilst who we are selling GitLab to may differ from who is using the product daily, we have to understand both to build a compelling product that people want. UX research can bring a particular set of insights about our users and customers that can help across products, marketing, support, and sales. We absolutely will feel to help us out and take the survey. As a thank you for your feedback, once you have completed the survey, you can enter your email address to have a chance at winning a 200 aligns and gift card. If you are interested, there are also opportunities to participate in future research. Simply read your email address and prompts during the survey or you can drop me a line directly at www.siratgitlab.com. We can now move on to any questions you may have. Hi everyone, this is Dimitriux. One of the UX designers at GitLab. We'd love to get your questions. We're going to be getting them in, so we're trying to process them on which answer. If you have any particular questions on certain areas in the interface or on the application, we'd love to hear them. Coop with us for a second while we try to see which questions are interesting for everybody to hear. We'd love to have you. Sarah, maybe you can talk a little bit about the process you're going with personas and how many personas do you have to design for as one of the questions that is coming in. Yeah, great question. We don't actually know the number of personas that we have at the moment because we're still in discovery phase. In terms of like kind of discovering how to solve a need, we've obviously got the survey. We're also using some user testing with users, to these are people who perhaps get all very detailed answers in the survey who would like to follow up with. We can stick more into the kind of frustrations that we have to get live or how we're using it. We're also using whether analytics were possible and to support the formation of the personas. In terms of deciding what questions we'd like to ask, to be honest, it's been a bit of a blank slate because we don't actually have much user research on our kind of users at the moment. So it's finding out kind of what frustrates and the very kind of basic stuff, how are we using it? What frustrates and what can be improved? How can we help them out? It's good for us to understand that if you're perhaps not even using GitLab, why are you not using it? What is it about GitLab that you don't like or perhaps you're using a competitor product on? What do you prefer about that? So there's quite a number of questions on there for different types of people to try and discover the kind of well-survived users and also those people who may be potential users as well. Thanks, Sarah. Another question that's coming in is, does our UX team use the GitLab MergerCast workflow for collaboration on all binary assets? So the way that our UX team works, we work very heavily in issues and having conversations as issues come up showing explorations and iterations and exploring what solutions make sense to the problem brought up in the issue. Once we kind of have landed on a direction, then that gets pushed to code and MergerCast and we're a part of the process in terms of reviewing the changes that happen but we don't necessarily, we don't really use the MergerCast workflow for our binary assets. We do have the GitLab design repository and that's where we share all of our working files and as we collaborate and work together but that's more just a shared file repository. So I think the main thing I'd say would be no, we don't use the MergerCast workflow for collaboration on our binary assets but we are a part of the whole flow as we build the features. If I can often in answering that question, maybe interesting for people to know on how we use Git to enhance our GitLab design repository. As for example, we use Sketch preferably to use our or create our design assets and one of the options you can have is by using an incredible plugin for Sketch called Sketch Measure and what it exactly does is it exports your design specs into a, you can put it online and your developers can see into it and get exact measurements from your design files and how we did it in Git, we make use of the PCI and CD features from GitLab which is really nice to look into it and we automatically host those spec export files which is basically a website and host them up if you give them a certain file naming convention in order to produce a URL to give to your developers in order for them to see your design specs. It's a partly automatic process that enhances our GitLab design repo just to inform you on that. Alison, back over to you. Thanks, that was perfect. So the question just came in about how do we decide how to design for mobile versus desktop clients and what ways the user will interact with it and so this is definitely something we have had conversations about first and foremost we, with a lot of what we build, we do focus a lot on desktop experiences. This is just kind of to map how our customers and everyone is using it today. It's a very much, you know, when you're coding and sitting down and really deep in work, a lot of it happens on desktop but there are definitely things that are very important on mobile and we do very much care about mobile experiences. It's just finding the right features that make sense more on mobile to kind of optimize for and so a lot of, you know, understanding the status or monitoring progress or a quick response, you know, to questions, issues, discussions that come up, those kinds of experiences we think are very valuable on mobile and we want to continue to kind of improve and build upon them as much as we can so we definitely don't want to ignore mobile but we need to find the right balance because there's definitely things that you're not, I don't think you're going to do very commonly on mobile and if we can optimize the mobile experience for what matters then that can feel very, you know, quick, awesome and amazing on mobile and desktop can be, you know, feel focused for what desktop is good at. So, you know, it's kind of balancing some of these conversations when it comes to mobile and we do track how for gitlab.com we understand people who like how many mobile users and how many desktop users do come to gitlab.com and so I help them understand, you know, kind of what pages might be more used on mobile or desktop. And another question that is coming in is what has been the biggest challenge for the UX team when building the platform? I think, see, there's the good question is a lot going on. I think part of it is being able to keep up and with the awesome speed, you know, adding all the features we want at the speed that we can, addressing all this wide variety of feedback we're coming in, you know, what features are we building that's, you know, great and focused for our enterprise customers and what will be super helpful for the, for, you know, our awesome community and what is good for us as a team is it's balancing all the stuff coming in and building, you know, what is the right thing at that moment, how do we prioritize all the stuff coming in and keeping up with the speed that we want to keep up with in terms of getting features out there and pushing features out there. And so there's a lot of, you know, let's try this, let's try that. Sometimes we try something and it doesn't work out well and since we had to write so quickly, we can, you know, pull back and, and rethink the design. So it's really just kind of managing all this feedback that is coming in and figuring out the right direction to push from there. Yeah, I think it's part of the design direction that KitLabs shows that all the philosophies and that feedback after having it in is this much more accurate than presumptions you make as GitLab, as a designer or as someone who designs any, any function that is inside GitLab. You can only trust so much into your intuition and knowledge and if you implement it and see that, for example, you implemented 20 features and two of them are apparently not what they should be then you roll them back and you implemented 18 instead of just, for example, less if they're not perfect. I think it's part of the philosophy of getting ahead further and faster, implementing it, reverting and getting on. I see there is a question on the navigation of the, of the, of GitLab, it's a top navigation. I think it's an important aspect of the GitLab interface. Perhaps Alison, could you give a bit of insight in what is planned ahead of us? Because it is, of course, a thing that I... Thanks, Rinti. Yeah, it's something we get a lot of feedback about and we're very aware of and we're trying to kind of think through the right way to solve and approach it. We understand the current pain right now with the two levels of navigation and the feeling of having to kind of, you know, feeling that you have to click and then click it kind of feels, it could feel slow. So we've got a lot of feedback and are thinking through the right way to adjust that. We need to balance it with, if we, we need to balance, so GitLab, there's a lot to go, there's a lot of pages, a lot of features, a lot of, you know, a lot going on. And so like the information architecture navigation is very important for us to kind of structure and make sense and make sure that the flows and the steps you go through through the various pages of GitLab make sense and that we group the right elements together. And so that's constantly, you know, something we talk a lot about and it's constantly evolving. So we are looking at that. And so that's one aspect of what we're thinking about navigation is just making sure that our layout of pages makes sense. The other question that continues to kind of come up is some of the details of the interaction and Michael, you know, micro interactions of how you interact with the navigation. Some of the feelings is just, you know, how it might feel slow, potentially on GitLab.com. And so there's, there's work elements on that. There's always a balance of, you know, we've looked at different ways to show the secondary levels of navigation without the over-complicating the interface and we do plan to improve it. So stay tuned, we will have some improvements on that. But it's just, you know, making sure we're moving things in the right direction and we're thoughtful with navigation because it's something where if we change it, we want to make sure we change it to the right direction. It can be very disruptive and, you know, if we change it too much, it can be very confusing. And so we want to make sure we kind of move it in the right direction. And so we're working on that and finding ways to simplify both for people who aren't very technical and are using different sections of the UI versus people who are deeply, you know, technical and finding the right balance there. There's also the question about the icon overflow on the right mid and top. I think that's maybe referencing the setting icon, which we are actively working on incorporating with the rest of navigation. So we're making improvements and hope to keep improving and feel free. There's plenty of discussion on it on gilab.com. So any feedback and ideas we'd love to hear on that? And just to add to what Alison was saying, the second part of that question says, how do you approach investigating your menu effectiveness? Well, I think one of the ways in which we do this, we'd actually strip the design away from it and concentrate on the information architecture first. And we do this using card slots. So we'd ask people to group the content together, which is the always most related to one another. And we would also then follow that up with tree testing. So this allows us to test the information architecture without the design there to kind of lead users. And they would click through what is essentially called a tree. It's like a hierarchy of pages. And they click through these pages to then try and find that information highlighting when you think we found it. Once we've got a strong information architecture, we can then re-implement the design into this information architecture. And this may mean that we've missed more tweaks than the design still may implement the information architecture. But we would go through rounds of testing with users, asking them to find certain information, ensuring that we don't directly ask the UC wording that is in the navigation to ensure that they understand that the content that they're looking at is what we're looking for. Thanks. So there's a question about what is our process for designing new features? What, you know, when do we sketch ideas on paper and then present the mock-ups, the users get feedback? Or, you know, how do we ask users for requirements? You know, how many kind of round trips are there to users on ideas and shipping of features? And, for us, this is a constantly evolving process. We're still, you know, figuring out some of the best ways of working and still kind of figuring out the right, you know, users and people to talk to as we're forming our personas. So another shout out to survey is part of what's going to really help us understand who our users are and help us figure out who to reach out to. So another shout out to fill that out. But in terms of what our process is, it really varies. You know, a lot of it is in the issues on GitLab.com and there's just a lot of conversations, you know, people will post feedback, you know, users and customers will post feedback as issues and then we'll think through it and kind of explore or ask questions. And so there's ongoing conversation with people there. I think, yeah, it's kind of hard to answer if there's, you know, an explicit number of round trips to users from ideas and shipping. Something we want to get better at continuing to show earlier, rougher ideas to users to get feedback faster. But today we also shipped so fast that we'll push something out there and get feedback of, hey, this isn't working. And so that's, you know, even though we've pushed it out live, we're more than happy to kind of rethink and how we might need to improve upon it. I don't know if there's any other, Sarah, if you had anything else to add to that question? No, I think we pretty much covered it. Cool, cool. I just saw an interesting question about it was related to this and how we approach or reach our goals in designing as we are dog feeding our own application, actively using it ourselves, basically. And I think there are a lot of examples of this as our own developers use this, but we ourselves make a lot of the, for example, our design discussion goes on in issue discussions. And of course you become, if you get into the discussions and you use it, you will reach pain points or things that you think will work differently if they were designed otherwise. And I mean, there have been many discussions on, for example, the merge quest, which is really example or shining example of what we want to build out into a better product and a better UI feature. And it's a thing that is used by almost anyone who puts in a merge quest. It gives the status of either the pipeline or if you want to merge it. And there's been some clear feedback and discussion going on on this. And we hope to improve this in one of the upcoming releases. Perhaps Alison or Sarah, perhaps you know of another good example of a past feature that has been introduced by us by Duff feeding our own application. I mean, the merge request feature is a great example, I think, of that. I mean, a lot of, like, I think details come in too of, like, you know, wait if we, you know, go through a flow every day, you know, figuring out what's the right detail or step that we can improve upon without, you know, finding the right balance of being opinionated with, you know, the workflow that makes sense, well-being, flexible enough for, you know, the product to work across all kinds of teams and companies and ways of working. So it's just finding that right balance there. You know, for instance, one of the things is everyone, like, like, you know, big part rate is tracking, you know, managing work. Like, there's all these issues, how do you even start to triage or figure out, you know, and different people use labels differently or waiting differently or due dates differently, and to figuring out, you know, everyone has their thing that they really, you know, their system that works for them, works for the company, how to, like, triage and find the issues and prioritize them. And so that's something where I think it's continuing to kind of evolve and it's interesting to learn how different people do it. So there's also this question that came up about, are there any plans to display due dates on the issues in the issue board view? And, you know, it's a good question. There's been conversation about it. There's this balance we have because, you know, some people want due dates on the issue board view. Some people want wait on the issue board view. Some people want the task list there. And, you know, and I could keep going of all the things that people are like, oh, no, this is the one thing that, you know, would help. And so it's finding the right balance because the issue board view can only show so much. And so what is that view focus for? What is it great at? What level of detailed information is important there? And then, and so, you know, there's that balance of, okay, what opinion do we have of what makes sense for this feature and then what level flexibility? Because you don't want to, you know, there's obviously we could, you know, customize everything, but that starts to get overwhelming. And so, yes, we've had conversations. We're continuing kind of conversations of what makes sense for the board view, what information makes sense to help people make decisions. Right now, we're still kind of thinking about keeping it at the top level kind of, these are issues, like top level in terms of scope and priority of the issues, but it's something that there's ongoing conversation about. Oh, yeah, just to add to that, while Elson was talking, a shining example came up into my mind, which actually just been released, or you can watch it live at gitlab.com, which is the issue list search and filtering functionality. And it's been recently been upgraded to use a sort of uni search box. And that is, that has been done because the old search functionality wasn't flexible enough. It used too much space, both vertically as well as horizontally as it can be extended with more and more features. And I think this is a really good first step in making it extendable for the future and also more user-friendly in the process. I think a follow-up question to this is really a really good one. As our developers use our platform, do you involve them early in UX process? And then do they actively discuss the process and planning of new feature? And yes, this is the main point of our workflow in designing new features. UX people know a lot, but not everything. And developers have their own sights on how things should be or will be implemented if it costs much time. And also a good thing to think about is how it will impact back-end design. For example, feature UX design, people can think of or invent or design. It will perhaps be a little thing, but for example, for someone on the back-end, it will create an impossible thing to do and will be a really big effort. I think of an example in this effort would be we thought about creating a real-time markdown preview next to the comment editor. And this is an awesome feature and it would be really great to have this in. And we have looked at this feature for a long time. In the end, for now, we have to get to help back on it because it involves a lot of back-end changes to be made in order to be able to make it a thing that could be done. And we have to be careful not to create features that will impact performance too much, for example. And there are lots of other examples that are a good example. I mean, sometimes you've got a simple thing to implement in the 3D heart and sometimes you don't. Thanks, Vinicius. I'm just kind of looking for some more of the questions that came in. So there's a question, kind of, how many mobile device platforms do we test with and what does our mobile development testing look like? I believe right now is a little bit at hawk and part of it is kind of, you know, what we see that kind of comes in. You know, we get a lot of, you know, part of it is our community is awesome at finding things that we miss and we try to, you know, do our best to catch things. You know, we're trying to get better at this. We're trying to find ways where we can make sure we're viewing our, you know, these tools out there to let us view our experience on all kinds of, you know, devices and we're working on kind of building that up a bit more. So, yeah, right now I think it's a little at hawk, but it's something we're constantly working on improving and we're also very receptive to any feedback we hear about it on our issues. So there's a question about what tools we use for analytics. We actually use database monitoring on gitlab.com, but we're in a bit of a unique situation in the fact that most installations of gitlab are on premise. So we don't use tools like Google analytics and things like that. In addition to that, we also feel being a kind of open source community and very honest and transparent, but we don't want to track everything that people are doing. We don't want to feel like we're being big brothers, I suppose. At the same time, we still need to get a balance of user feedback. So there is definitely more of an emphasis, more on like qualitative research, so user testing and surveys and things to give us insight. I hope that answers your question. Perhaps in addition to that, I think at least of my particular set of knowledge, but I think we're actively looking into possibilities of using Prometheus and to getting more statistics and analytics in everything from the application, both inside as well as performance. I see here a question about if you actually is actively engaged in designing of the API and command line side of things on gitlab. I think we're less so at the moment. However, I know that, for example, my colleague, Pedro, is actively engaged in, for example, designing the chat ops functionality with MetaMOS. And it's an area we should or we are looking into it more and more. There's a question about our user testing process and what does it look like and do we test with current gitlab users or do we find users who have no experience with gitlab and how do we find these users? Jared, I don't know if you want to talk a little bit more to some of that. Yeah, sure. Well, we're still in the process of kind of building that user testing. So, at the moment, we're only in a very initial stages of doing testing with users. If you answer survey, there's the opportunity to sign up for as a research participant for gitlab. So, that's one way with quite a few users. And that will include users who are familiar with gitlab, but also those who don't use it. And so, it will give us the option to test with both. Other ways you can kind of find users to test them is like through social media, is a great option. Also, through email, blog posts, just like that. To be honest, we're very lucky that we do have a kind of very vocal community. So, there's always a lot of people out there that are willing to help us. And through the presentation, it's more finding the quieter voices sometimes and ensuring that their voices are heard too. Cool. And there's another question about our design process and just kind of how does it work and all. And there's a lot of kind of ways that our design process works. There's responding to issues that come up. So, if someone suggests either a problem they're having or an idea that they have, we start to kind of dig into that and understand why they're having that problem. So, we might have questions or we might, you know, explore it ourselves. We also, as a team, we'll create, when we have ideas, we'll, you know, create, as you see a common theme, is there's a lot with issues. So, we'll create an issue ourselves and we'll talk through, you know, what the idea is trying to solve. Sometimes, it's very important for us to take a step back and start with the goal through the context of the area, especially when we're thinking of kind of, you know, more, you know, larger features. And so, sometimes it's, like, let's make sure we're all on the same page in terms of goals and then we'll sit down and start to kind of explore, iterate, sketch, post, you know, start to kind of create some mocks and talk through what makes sense and what doesn't make sense and flows. You know, there's a lot of, just a lot of conversations we have and a lot of back and forth. Being, you know, part of why we use GitLab issues so heavily, I mean, first of all, using our own project helps us understand it. But also, because we're a distributed team, you know, we want everyone on the team to be a part of the conversation and everyone's working at different times for the time zones and everything. And so, you know, you put, you push an idea out there and you get people to be back on it. And so, we do, you know, we will have video calls and conversations and Slack and all where we do kind of have a real time back and forth, but we try to push and optimize for, you know, having the asynchronous conversations and ideation together. So, that's kind of a big part of our process. And it's also just kind of following the work as it comes from the initial kind of conception of it. You work on it, you ideate on it. And then, you know, the moment that there's, you know, a branch and some of it's been implemented, you know, we'll check it out ourselves and, you know, continue to kind of iterate and solve problems or questions that come up at that point from a UX perspective. So, I don't know if there's like a clear answer of what our design process is, but that's some of what gives, how it goes. I see a follow-up question that takes into that, which is like, what was the biggest issue of frustration of getting get led what it is today? I think it taps into what our design process is like. And as Alison said, we make use of the conversational development in GitLab, which tries to optimize for a synchronous conversation. And basically, the thing is, you try to involve all the important people for an idea, which is an issue is basically into the conversation as early as possible to see what kind of reach this idea has. And part of this thing is distilling an idea to its bare minimum, as when you implement the bare minimum of an idea, it will be better the next implementation of it. So, if you implement the idea and you use it actively, you can see, okay, now we have a clear way of what the next iteration of that idea should be, instead of implementing it all at once. I mean, you can develop an idea and this is sometimes a pain point. You want to do so much while keeping it to a bare essentials is the better way to go, as it will evolutionize into the right shape instead of what you assume to be the right space or shape. Just to notice, I think we have a little more than nine minutes less for this UX webcast. So, we'll just get your last questions in, if you have any. There's one that I just saw about what tools do we use to discuss UI sketches remotely. This is also kind of, we're constantly lobbying and learning how to do this. I mean, a lot of it is you know, we still mostly use GitLab issues to discuss and, you know, you can put sketches in there, you can put all kinds of comps in there and then talk about it. But some of it can be a bit challenging to, you know, to give feedback, to give a feedback, printed feedback that you want on the sketches. So, you know, we're still evolving on how we can improve some of our remote kind of brainstorm capabilities. We do, you know, meet weekly and that's sometimes when we need to just have a more kind of back and forth, let's talk through, you know, the big carry problem and kind of find a focus or goal on that. So, there's, and you know, you put stuff in fact, but we don't, there's not any specific tool outside of GitLab and, you know, we have our shared repository with sketch files and so we can just kind of use each other's sketch file to look at things. But a lot of us have seen that, posting images and issues and talking about it. There are various questions on the tools we use and our design tools. I think the design process has already been talked about. However, the design tools, I think it's been mostly being clear, but we mostly use GitLab itself and the issue design discussion or the issue discussion is the design discussion itself. We post images in there. As said previously, we'll make use of sketch measure, as is one of the things that we use to give spec exports of our designs we made in sketch to our developers in order for them to implement them. And for example, we are looking into ways of enhancing the discussion itself to better fit our design discussion. There are interesting examples of that, for example, getting better image functionality in there amongst other things. I see that there's a question about image comments. Yes, we're actively looking into that. And just as an example of that on our summit, we have had a great discussion on that and looking into ways and which way or which routes we will take to implement it to be useful not only for ourselves, but everyone that will use GitLab. And there's a question about how large our UX team is. So there are five UX designers, one UX researcher and then myself as team lead. And we work very fluidly. A designer might kind of be more involved with a feature for most of it if they can, focus and spend the time on it. But they can pull in other people of the team as they need help or have questions or just need another pair of eyes. A lot of features are kind of ship monthly. A lot of things, every month there's kind of a new iteration, new version, a new kind of thought in that area or on that feature. And so there are definitely some general areas that some of the designers focus on. But it's not anything strict or anything. There's a lot of fluid movement. Everyone's kind of a part of the conversations and everyone can jump in with ideas and thoughts. And so, yeah, there's some features. There might be a designer who's there the full time working through everything. I want to make sure that there's clear understanding of who's the right person to reach out to if you have questions as the developer works on it, who they can work closely with. But it constantly evolves as we need to evolve. A question that is a thing actually that came up apart from using Sketch is that we are looking into using Framer for the more advanced designs that actually need some... I forgot the word for it. However, for the advanced designs that are needing motion or animation, etc., there's also some optimization for this in the design workflow itself. And it can make some design discussions very clear as motion. It's hard to explain words only. Yeah, definitely like when we're thinking about flows or prototypes or what not wanting to kind of, you know, some times it's useful to move the design beyond static images and to really figure out how something feels or what the motion, what that can add or do track from the experience and what are the subtle interactions that matter. So, yeah. We have a few more minutes. Let's see our questions come in. Do we... So the question came in, do we ever have to settle AUX arguments and how or who is responsible for that? And what are the ultimate reasons to choose a design over another? So, I don't think there's been really heated arguments. I think for the most part we're able to talk things through. A lot of it is if you bring it back down to the core goals or context you're trying to solve and then you can have like very analytical conversation of what, you know, design works better for another, the pros and cons and base that in as much as you can in terms of user data or feedback that we have or our understanding of our users with personas to help us balance and make a decision. And so it, you know, is one decision map better for our overall long-term goals or decisions or visions for GitLab? What, you know, what makes things better for enterprises versus, you know, small teams and how we have to balance all that? So there's a lot of conversation like that and is just kind of having, you know, as much as you can bring, you know, our understanding of our customers and users into our decision making the better. And so that's, that's it. I mean, there's a level like when it, you know, comes down to it as the AUX, you know, as the AUX team and as the AUX team lead, we're responsible and it comes down to us to make the decision. But it's usually, you know, very much a, a kind of just analytical think through what works, what doesn't work, and how can you decide what, what makes one design make more sense than another. So I think we're just about at time that I want to thank everyone so much for taking the time to join us in this podcast today and for all the awesome, wonderful questions. Super helpful, great conversation. Let's see, one more, one more question just kind of flipped another one or what under the wire about any tips for leading the UX team. But yeah, overall it's just, I mean, it's been so helpful that I, it's just been such a great team. So it's been easy. But just awesome, making sure that there's, you know, a clear kind of shared vision or direction as a team. And so part of what I've been trying to do is really, you know, when decisions are made by the team to document what I can in the UX guide to kind of weigh in and make sure we all understand what our, you know, goals is or print our principles are as a team. So if everyone has the same base that they're coming from, then they're all able to, everyone's able to kind of work as a team, even if we, you know, are all working at different times in different places on the globe, we have that same shared direction that we're pushing towards. And so that's kind of, you know, making sure we all come from the same place. Anyway, I think we do have to call it. So thank you everyone for, for taking the time to join us today and for asking all those great questions.