GitLab UX Team, 1 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UX Showcase - IA @ GitLab

Description

Manage & Plan
UX Showcase - Dec. 1st, 2021

A

There we go go.

B

Ahead nick sure, hi everyone, my name, is nick post, I'm a designer in the the manage workspace stage and also the manage optimize stage, and today I want to talk a little bit about the information architecture of git lab, um because this has become sort of the focus of my attention most recently with joining the workspace group.

B

So, uh first off I'm going to talk a little bit about background of why information architecture is important and then talk a little bit about the the current architecture that that we have in gitlab and then what the manage workspace team is going to do. I don't think we have time for the conceptual model stuff at the end, so I'll record a separate video there. So I can share that people can watch at their own leisure, um so design at gitlab is is unique, and this is what attracted me to gitlab.

B

um There are some big challenges uh for design based on our organizational setup, and these are sort of like the the very large single application that we have the decentralized way that we have uh designers split among um cross-functional teams, as well as having open source contributions and then our iterative culture as well. All these make design challenging, but also interesting and uh potentially a superpower here at gitlab.

B

So uh we've seen some challenges with our system usability score.

B

Recently, it's been declining for the the past few quarters and uh some of the common themes that come up in user feedback are around uh complexity in the ui uh difficulty, with navigation and discoverability and also onboarding, and when I look at these different problems, I sort of reflect- and I think you know a lot of these- could start to be addressed with some information architecture, type thinking um in case people, don't know what information architecture is it's about, helping people to understand their surroundings and find what they're looking for both digitally and and physically as well.

B

So um when I think about the problem statement that we have here uh specifically for my group of managed workspace, I think how might we use information architecture to improve the user experience and positively impact our system usability score, hoping to fix things like this ui complexity, this navigation, this user onboarding, um whilst maintaining the unique gitlab way of designing um so maintaining the single application, maintaining the decentralized way that we do design and also maintaining the iteration that we we hold so dear within our values.

B

uh So when I think about this problem statement- and I first started in the workspace group- I didn't really know where to start. We've got such a big application. It's it's! It's quite difficult to sort of figure out where we break this down and and start working.

B

So it's a bit of a challenge, but first thing I wanted to do is actually check out our current uh um information architecture and understand it myself, and I I really like this quote uh from from chesterton about before going and breaking anything, it's useful to sort of understand why I was put up in the first place so before I actually go and do anything to our information architecture.

B

I want to understand the rationale as to why things were put up in the first place, the way they are and uh this I will try and communicate to you in the next five minutes and uh see if to see if anyone is uh the wiser for it. So projects are uh the sort of primary container that we have and projects host primarily a repository.

B

uh They can also be used to plan work and collaborate on code and continuously ship things with ci cd. So it's basically the combination of a repository plus the workflows associated with that repository uh groups came along a little bit later and what groups do is they manage related projects together and they also manage the broader workflows that span across these different projects?

B

So, for example, we have project screens, and we have group screens- and you know, uh there's some similarities here and there's also some differences, but if imagine sort of coming to these two interfaces as a user uh brand new to gitlab and thinking why? Why does uh get lab keep on swapping? And this is something that I definitely got confused with to start out with um so projects and groups.

B

They have both shared and distinct features, and um even when there is shared functionality, sometimes there's actually differences between what's available with regards to the information functionality, that's actually available so projects, for example, uniquely have repositories groups, for example, uniquely have epics and there's some shared things like labels and value streams and stuff like that.

B

So, for example, in group value stream analytics, we have the same feature shared between project vsa and group vsa, however, because of uh things needed to be built twice for the project level and the group level and the fact that their unique performance constraints around feasibility. This means that the way that this feature appears at these different levels actually um is sometimes quite divergent, another potentially confusing factor so for larger organizations.

B

One group is often not enough. Sometimes you need to have more nuanced organizational structures and we can use nested subgroups for this, um and you can have a group which contains projects. You could have a group which contains a subgroup which contains a project or you can have different variations, but ultimately this forms a sort of file tree type structure which we use today and there's some nuances here. But um what's interesting is you know?

B

You have separate project lists and a separate group list of of things that you can choose from, uh even though they actually technically exist within the same file tree uh now, groups uh alongside having their own features, they also cascade content, settings and access down to child subgroups and projects.

B

So you can manage lost lots of things at once, but this sometimes manifests in in inconsistent ways. An example of this would be milestones, so milestones uh can appear in the issue sidebar of a child project, but they don't actually appear in that project's milestone list. So the parent has these milestones. They show up in the issues of that project, but they don't show up in the milestone list of the projects, so um the way that this manifests is sometimes a little bit confusing.

B

uh With regards to what information is shown to the users alongside cascading information down groups, also aggregate content up. So uh this is useful because you can sort of aggregate across different projects and use that aggregation to understand things like analytics of how different projects are working, side by side and and and and so on and so forth. So an example of this is uh issues don't actually exist at the group level.

B

Instead, the group issue list contains uh issues that come from different projects below it and uh we also have alongside a project and group. We have something called an instance, and instance is actually only relevant to our self-managed customers and within the instance level. It has its own unique features such as admin, settings and hardware settings.

B

But the instance is the top level container that exists within gitlab and, as I said before, uh the instance is only really applicable to uh our self-managed customers, because our self uh software, as a service customers, basically uh sit on the gitlab.com instance, and this means that uh they technically are um sort of using this top level group in order to manage everything. That's going on so there's there's a a difference in the types of features that self-managed and sas customers have access to, and this is this is a big problem.

B

uh So, for example, sas customers are missing out on all the stuff that sits within the admin panel within within gitlab, and that's a lot of useful stuff that could definitely be applicable.

B

So to summarize, we have projects, we have groups, we have subgroups. We have the instance and containers tend to house their own features.

B

They tend to structure different teams and workflows, they tend to cascade content down to children and they tend to aggregate content up from their children, and there are a number of challenges associated with the current configuration of containers that we have currently, but I've rephrased it as principles.

B

In terms of what we need to do is we need to have greater efficiency with our containers in terms of removing uh the friction between them and potential for duplicate work, as I highlighted in value stream analytics before, we need to uh improve the consistency between these containers, specifically between self-managed and sas customers, but also between the features that are available between project group and instance.

B

uh We need to enable and control information flow across different containers, and we also need to enable greater performance across these containers as well. So we can have more sophisticated uh queries and features that that involve those queries.

B

uh So that is that uh for our different um for a different, our current ia setup- and I thought I'd- update the challenge statement here and include these ia principles that we're trying to solve for as well in order to in order to sort of include that within the broader problem.

B

So now it comes to manage workspace, we've sort of understood the challenge, the challenges that have come from our current ia and uh we need to sort of understand a little bit more about what the manage workspace doing.

B

Team is actually doing to try and address these, so uh the workspace group came about uh a couple of a couple of months ago, and uh it's responsible for rationalizing the data model for containers of resources within gitlab uh very, uh very technically focused uh definition there, but uh it's, I think, uh super accurate, and I think if you want a more designer, focused term I'd say this is probably very representative of what the workspace team is trying to do as well.

B

uh My screen's frozen there we go back to it. Okay, so the manage workspace is, is currently focused on three key initiatives: just checking the time 15. uh so uh yeah, these initiatives are namespaces workspace and ia tools. um First, initiative namespace is, is about basically merging projects and groups together in order to get this consistency and we're doing this using the technical term of namespace.

B

uh Second, is about uh giving parity between our sas and self-managed customers by creating this thing called workspace and then, finally, it's providing designers tools in order to think about our information, our architecture, so you guys can do this yourselves.

B

So uh I and the workspace team aren't going to be able to do all these different namespace and workspace uh initiatives by by ourselves we're going to actually need everyone in in in the product team to help with us or design team and uh and so on so uh yeah it's about providing similar tools in order to help everyone um think about these problems, so uh namespaces workspace, ia tools and uh here's three actions you can take right now is join the workspaces.

B

Ask me anything which is happening next week, um start to plan for upcoming changes with regards to namespaces and workspaces, and this is a great example of how communicated it and then read on further into this last chapter as well. uh Thank you very much for listening. I know I rushed through it, but uh this is designed to be uh uh able to be consumed and read at your own leisure and I'll I'll, also record a video about the conceptual model stuff at a later date as well. Thank you very much.

A

Great job nick uh and thank you so much um and for being uh as close to on time as possible. You're actually right on time any questions, uh or should we move on to the next one real, quick.

A

I don't see any questions in the agenda.

A

They can, of course, start to fill out as we move on it in for time's sake. If we need to which, I think is what we're going to do.