 All right, it's the top of the hour. I'm going to go ahead and get started. Welcome everyone to the first UX Functional Group Update of 2018. So just a quick look at the agenda. I'm going to go over a little bit of the year in review for 2017, talk about 2018 goals, go into challenges, everyone can contribute, and questions. So in 2017, we made a huge change to our navigation. And we did a redesign. It was a bit challenging because that redesign was based on really anecdotal evidence. We didn't have quantitative research going into that decision. And the decision was not received very well. So the changes that were made didn't address underlying information architecture problems. And really, the solution that we came up with only made the problem worse. But out of that, we were forced to take a step back and conduct several runs of research to really look at what the problem was and why the solution we came up with wasn't working. And in the end, it really gave us an opportunity to refine our process and really define how we can conduct proper research when necessary, while still shipping improvements every release. So research isn't always necessary. You don't always have to go in and do this epic amount of digging and interviewing and prototyping. But sometimes you do. And so understanding when that's necessary and when that needs to be done is huge. So in the end, it was a huge collaborative effort. The community was heavily involved in the research and decision-making process. And I think that we normally engaged them but made them feel empowered that they can contribute to GitLab. It also forced product management, front and back end, and UX to all pull together to make iterative improvements over three release cycles. So this obviously had a huge impact on UX research and how we were conducting UX research. I think one of the challenges that the team had was that prior to the navigation redesign and the changes that brought about, we were largely reactive, more being proactive. So by the time research was called for, the problem was already being fixed, the solution was in, it was being implemented. It wasn't efficient. It really put us at a disadvantage to properly measure results. And we had no data to measure against. So a solution was put in and there was no way to measure whether or not it was better other than qualitative data of I like it or I don't like it. And it was also some fear, I think, and rightly so that research could slow things down and keep us from iterating quickly. So there was a little bit of reticence to kind of jump in and really create a UX process. But we established a user research panel made up of real world users. So actual everyday GitLab users, people using projects, using it for projects, people using it for work. And we took the proactive step to start conducting research on major features to establish baseline metrics on usability, to really understand what were the major areas that had usability issues within GitLab. And then that way what we could do is start digging into those problems, coming up with solutions and actually measuring whether or not we made it better or we made it worse. So getting things wrong was really frustrating for users and caused a lot of extra work. Having this proper UX research process in this panel is ensuring that we are solving the right problems. So another big focus for us, particularly at the end of 2017, was UX standards. So a lack of defined usability standards really led to a lot of inconsistency and poor user experience across the application. Design didn't have a central pattern library to use as a starting point for each issue. So we relied on going into the app and seeing what was already there, maybe looking through some old designs to really get that starting point. And that's obviously a problem that leads to inconsistency in itself. So we did the action of recording all the existing usability standards, even though it was not yet implemented in the app. And so what that allowed us to do is establish a kind of single source of truth for the design team to use when designing. And one of the really nice side effects of that was gathering the solutions that we already had designed but weren't implemented, kind of highlighted how much we needed to do to get these into the app, brought them back around, reminded us of issues that maybe were six months old that didn't get scheduled and to go back and get those scheduled. So the result is much more efficiency and transparency. Documenting solutions to common usability issues allows us to work faster and to provide a more consistent user experience. It also empowers front-end and product management to make smaller UX decisions because we've already come up with those solutions. There's no need to go into back and forth between UX and product management on what the solution is. We've already created the solution and used it elsewhere. Let's reuse it here. So just a quick example of what we're talking about. These are all the different banners. So we've established the usage for these banners, when they should be used, when they shouldn't be used, how they need to be implemented, how they need to be styled. Kind of really the styling and that are the last things we consider when we look at this. We're really looking at how to create these reusable usability solutions. So these patterns will live in that master library and we can quickly grab them and use them when we need to work on an issue. So another piece of that is a UI repository. The existing UX guide has been really difficult to maintain and update. Things change every release. So every time there's a change, someone needs to remember to go back in and update that guide. And it just isn't very efficient. And it also was missing clear guidelines and code examples for front-end to follow. So while it was giving UX some idea and maybe product management some idea of the way things should look, it wasn't giving front-end any guide in terms of how to componentize it, how to implement it, what code to use. So this UI repository is really kind of the missing link between UX and front-end. It's a central location to view UI components and standards. And efforts that we're putting forth in defining our usability standards and our patterns is being reused to establish this UI repository of reusable scalable components. So it results in a lot of efficiency and collaboration. Really, we're working smarter, we're working drier, we're working alongside front-end to implement these solutions inside of the repository. The end goal really is to have this single source of truth for front-end to come in use when they're implementing issues. And this is just an example, kind of show you the difference. I think it's really easy to confuse or think that they're the same thing, this pattern library and this UI repository, but they are very different. The pattern library is for designers, it's for us. The UI repository is for everyone. It's for front-end product management and UX. And this is actually just a screenshot of Carbon Design Systems. We're still working on this into 2018, but this is the end goal for us is to have a place where front-end can just come and grab this code and go. So that brings me into 2018 goals. So obviously, we wanna complete this library and this UI repository. Most of the work on the pattern library is complete. We've recorded it all, we've implemented it in our sketch files. So the main focus now is getting all of that information into the UI repository. So again, we'll work in tandem with front-end to do that. They'll be using those patterns that we established to create their view components and the code for the components as they go forward with that effort. So another big focus for 2018 is gonna be accessibility and usability, particularly for non-technical users. So in practice, basic accessibility is a prerequisite for usability. So there's a lot of overlap between accessibility with other best practices, such as mobile design, device independence, multimodal interaction, just general usability. If you don't have good accessibility, you're probably gonna have problems with your usability. So we're gonna have the UX research team conduct a comprehensive accessibility evaluation to identify the major problem areas. While they're doing that, the rest of the team is gonna go through the backlog and prioritize the existing issues and really push for improvements, those improvements that we think are vital and important to product to get those scheduled every release. The plan is to use EPICS to help prioritize this. So I'm really excited to get to play around with EPICS and see how we can use that to work more efficiently. And the second part of this is really prioritizing that UX backlog and maintaining a roadmap. Roadmap, I think the backlog has kind of been where issues go to die, unfortunately. We create these solutions. We put the force to be implemented and then they just don't get scheduled for one reason or another. And there's a lot of factors that can win to that. So we wanna create a hit list of sorts for the areas with most usability problems. So we'll start by going through that backlog and identifying those target areas. And if there's research needed, we'll go ahead and do that. Otherwise we'll push to get those scheduled. There's a lot of UX writing issues that really could be scheduled pretty quickly and get into the app. So that's another area that we'll focus on is how to really get these solutions that are already there into the application. And so this really kind of ties into the challenge, this extensive backlog. It's large and we have to balance these fixes with other features that are on the roadmap. So as you can see, there are quite a few unscheduled solutions. There's 76 UX ready solutions. So they're already done, they're ready to go in, we just need to get them scheduled. UX debt and UI polish really represent the bulk of the current inconsistency sitting in the app today. A UX debt is often gonna be something that we did the first iteration and we planned on improving it in the next one and it just didn't happen for one reason or the other. So this is a challenge. It's something we're gonna be evaluating and looking at how we can improve this and stop this from happening moving forward. And so with that, did put together a very, very quick survey. I promise it's quick, it's two questions. I really want to know what GitLabbers think is the area of the app that needs the most work. Is it the merge request? Is that something that just irritates you every time you come in? Is it something on the issue boards? What is it that you think is the area that needs the most attention? Obviously we're gonna be going through the issues and prioritizing and looking at that and looking at what the most popular are. What we feel really represent the largest areas of usability problems. But I'm really curious to hear what you think. You use it every day, you're in there. It's how you do your job. So there's gotta be something that just gets you every time you're in there. So take a minute to fill it out and let us know. And thanks, Chris, appreciate that. So questions. Sorry if I ran through that. It's my first time. I'm trying to make sure I do it in the 15 minutes. I don't wanna waste anyone's time. Any thoughts, comments? Vice. Alrighty then. Well, thank you everyone so much. I really appreciate you coming out. And please fill out my survey. Let me know what you think. All right, see you in the team call. Bye everybody.