 Hey everybody, we've just approached the hour, so let's show you what your research has been working on recently. So I recently conducted a round of interviews where I asked users to share with me how they'd integrated GitLab into their workflow. So the aim of this research was to understand what GitLab features they used, how they use those features. So for example, were they using features as intended or had they created workarounds? How could we improve these features? And finally, I also wanted to know what features they weren't using in GitLab and why. And I was particularly interested in answering these questions in relation to dashboards and notifications. So things like real-time alerts, to-dos, emails. I spoke to five users. I was aware that a user's workflow might vary, dependent upon the type of company they work for, the size of team they work in, the job they have and so on. So I made sure to speak to a range of users. So I spoke to a development team leader, product manager, a sysadmin, people from small organisations where the development team consisted of two or three people, and large organisations which employed over 10,000 people. And I also wanted to make sure that each of GitLab's products were represented. So I spoke to users of .com, C8 and E8. And if you check out issue 22 of the UX Research Project, you can read a bit more about each of the users I spoke to. And generally, we just had a casual conversation about what their typical working day normally consists of. So the kind of tasks they do and who they speak to and so on. And whilst our conversation took place, they would often refer back to GitLab or the other tools they were using to clarify information. We actually had one user who was very open with us and he chose to screen share throughout the conversation and he showed us how he'd configured GitLab in terms of setting up projects and issues boards and things like that. And he also showed us reporting he'd set up outside of GitLab. So as a guideline, I asked users to set aside 45 minutes for a conversation, but there were some users who really wanted to provide as much feedback as they could to GitLab. They were very passionate about improving features. As the feedback that was coming in was really detailed, it was very constructive. And truly being honest, it's probably one of the most interesting research projects I've worked on whilst I've been at GitLab. So therefore, rather than kind of cutting users off, I just let them speak openly to me for as long as they wanted to. And just in some cases, that kind of doubled the time some users are speaking to for about an hour and a half. I've since edited these conversations down to the key points. And if you'd like to listen to the recordings, you can also find them in issue 22 UX Research Project. Because users were given the flexibility regarding what they spoke about and how long they spoke for, we didn't actually just receive feedback on dashboards and notifications. We also got feedback in relation to wikis, projects, issues, onboarding new users and merge requests. I think it would probably take me a couple of hours to go through all the feedback that I've gathered. So I just thought I'd share with you just a few things I personally found interesting. So user free. He had a dual role of a product manager in a CTO. And he's currently using GitLab.com. He created a project which just stores a wiki and issues, no cold is pushed to it. So instead of adding and maintaining a read me file for multiple projects, the wiki is used to document all information and includes topics such as how to manage tickets, how to run and install projects and his company's style guide. So basically he wanted his team who all worked remotely to have a central location for help documentation. And he felt the wiki was the best solution to this. In regards to issues, user free uses the issues board view, but he needs the ability to see issues assigned to his team across multiple projects. So rather than creating issues to accompany merge requests in their respective projects, he creates issues in a master project. So where no cold is pushed to. And he assigns each issue to a developer and when they are ready to merge cold, they cross reference the issue in the merge requests. So therefore, his issues are still kept up today. At the same time, you can still see what all his team are working on across all projects. User one is a development team lead. As part of his job, he maintains his company's GitLab installation and he embords new users to GitLab. He was currently using CE, but the time of our conversation, he was in talks with the sales teams Moota EE. And there's currently 330 people using GitLab at his company. And around a hundred of those people are non-technical non-developer users. And he explained how non-technical users typically just want to manage or follow issues. And that logging into GitLab is overwhelming for them. So to view an issues board, they have to visit a project and in doing so, they may be essentially exposed to code and that can be really outputting. And he's struggling to get them to adopt GitLab as they believe it's just a tool for technical people. So for this user, a greater amount of user roles and permissions would be really helpful. And finally, all users I spoke to mentioned dashboard in some shape or form. Users one and four explained how their managers need to see it against the current status of all projects. So when asked what kind of information their managers would like to see on a dashboard, answerings included like the total amount of issues within GitLab, the number of issues closed last week, the number of issues with a particular label. Generally managers just want an overview of how well their teams are performing in releases. So users refer to other tools such as Jenkins which has a dashboard that lists all projects and details information such as when the last release went for production and when and what the last merge request for production was. So both users emphasised how important it was to be able to see all this information on one screen. And one of the users actually commented that he would love to be able to display it on a television screen so it's visible at all times and anybody in his office could see it. So it's really clear to me from speaking to users that dashboards are incredibly important at a management level. The majority of user pain points discovered during the interviews related in some way to management and their dissatisfaction at being able to view and monitor progress across multiple projects at a high level within GitLab. So if management isn't happy with GitLab then it slows down the adoption of GitLab within a company and obviously there's a potential for that to have an impact on purchasing extra licenses upgrading from CE to EE, ditching legacy tools and so on. So I've shared all this feedback I've collected during the user interviews with the product team and the rest of the UX team so the next step is to work out what can be actioned and when. Does anyone have any questions? Nobody? Sarah, I have a question. What is the thing that stood out most to you? Were there any surprises in how people get used to GitLab? I think the thing that struck me is that despite the fact that everybody has very different workflows because it can vary like I say upon their job role and the type of company they work for and things issues boards were still very central to all of those kind of workflows even if they weren't using the GitLab issues board and they were perhaps using something like RedMind everything was still tied to an issue. So I do think there's a potential, like there's an issue that I've created that contains everything feedback-wise that I got on issues boards and I do think there's a lot of potential there to kind of develop issues boards and encourage more people to use them within GitLab. And if it were up to you and you take a guess what would be the single highest impact change that we could make right now based on the feedback that you got? I would say create a dashboard for managers because that's the thing that a lot of users really were upset about. Even people who work at quite a senior level were still reporting into somebody who just really wanted to see at a glance what was going on in terms of what the team was working on. So I think dashboards. And was there any trend to how people were organizing their projects? For instance, were they always using a single group and in that group multiple projects or they had many different groups? Did you investigate any of that? Yes, I did. Like I say, one user actually showed us how all these projects were structured. I found that people were using groups, not necessarily subgroups though. They seem to be not a lot of awareness about subgroups. Thanks. It's really great. It's really interesting. So thanks Sarah. That's really interesting. But this management dashboard. So these managers felt they couldn't check on activity across different projects. Would that be solved with a group feed or something like that? Or is it something new? And as Yop said, how would it look? Do we have an issue for that or something like that? Yes, we do. So I've created a dashboard issue 24 within the UX Research Project, which contains all the feedback. And there's actually a couple of examples within that. Because I asked users, could they have anything that they refer to that they kind of wanted? And one user looked at a dashboard and said, I've actually been trying to implement something similar to this in my spare time on GitLab. So there's a link there that actually contains everything that he kind of wants to see on a dashboard. So that's issue 22? 24. I linked it in the comments. Yeah, I see issue 24. But that doesn't read like a feature proposal to me. That's how I write all my research up. But I think I need to discuss it more with the product team. I don't think we really have a chance to get together to discuss how we move forward with things. But by all means, it can go into the C projects as a feature request. I see that Sarah is also in the call, Sarah. What are your thoughts? I was just typing it all out. So yeah, I think we need a better process for what to do with this information. It's something that Sarah and I talked about this morning and I mentioned in the product channel, I think that what we need to do is while this information is fresh, we need to meet with product decide what the next step is feature wise, get that issue going and move forward there before Sarah goes back and does any other research. I know that there's all a couple of dashboard proposals out there already. So maybe even take those and consolidate them into one issue. But I think that it's good stuff that we definitely need to have a bit of a better process for. Exactly right. This needs to be worked out into a feature proposal because right now it's like a list of requirements, not a feature proposal and there's other stuff like the smart project smart dashboard proposal from Tori. And I hear like a management dashboard, etc. But we need to we need to figure out what the what the best thing we can make is the smallest thing that will have them the most interest. But it's easiest to bills and most or rather than all to our other features. But that's that's the hard work that now has to happen and we need to do it while the research is still fresh in Sarah's mind. I agree. So we don't we can just do that right. Yeah, we're scheduling a meeting. We were just talking before this call about it. We're scheduling a meeting to discuss concrete work and who's going to take what because there's a lot of feedback. So should do something with all I don't necessarily agree with doing something with all the feedback. I do agree. We should we should make it actionable. Do something with all the feedback like either disregard it or build something out of it. I don't say that we should based on all the feedback. Yeah, that would be a bad job. Cool. Cool. That sounds really good everyone and thanks Sarah for presenting this. It's good to see it in terms of the issues being confidential at the moment. The reason why they are confidential is because the users that I spoke to and it's quite clear what companies they work for. And they didn't necessarily want to share complaints about the management and things with me in a public setting. So the issues are confidential. But if anyone wants access and can't get through, like Elsa, I can see that you need access. I'll make sure that you get that. Thank you. I'm just catching up on the chat. People just give me a second. Yeah, definitely Jamie, definitely. I'd love to speak to new gate labbers about dashboards or anything in general and their thoughts on gate lab and how they're finding it. Any more questions? Going once, going twice, three times. Thank you very much everyone enjoy the rest of your day. Thanks.