GitLab Growth, 27 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UX Showcase 2020-05-27 — Growth

Description

Emily Sybrant — Users occupying seats in a GitLab.com subscription

A

Today, I wanted to talk about a project. We've been working on filming group about users occupying seats in in a in a good lab comm subscription.

A

So though, here's a little bit of information about the fulfillment team, a lot of people were involved in this, and this is actually an issue. That's been open for over a year, so there is a lot of really great information about it. A lot of our customers have weighed in on this one.

A

This one is, is a big customer need issue, so, let's dive in so the problem here is that while a group owner can see how many seats are being used in their subscription, there's actually no way for them to see who's using this seats so Jack coming into that a little deeper here is the subscription billing page. This is found in the product under the group navigation. So you can see here at the bottom. We have this little widget. That shows how many seats are in your subscription.

A

How many seats are currently in use, so that is information that we're surfacing to the customer, but a lot of times that doesn't necessarily match up with their expectation of how many seats they think they're using, and so we get a lot of questions around okay like who are the people using those six seats and it gets even more confusing when the person goes to the group members page and the numbers conflict.

A

So there's actually a really clear explanation for this. Anyone added to a subgroup or project underneath of that parent group is contributing to that number of seats currently in use, but obviously it's not showing up here on the group members page and that's really confusing to our users, because they're seeing this discrepancy and they're like. Why are you charging me for X number of users when I only see Y number of users so go sum in terms of like validation?

A

We didn't do any official user interviews around this, but, as I said, the issues been open for over a year has a ton of people that have weighed in both the support team and customers, and some really good quote. So. You know, as a customer I get lab comm. It's been very frustrating for me to get a bill for my renewal that 66% higher than I expect and then having get lab support.

A

Tell me that there's actually no good way for me to know why I'm being built for those five users and who they are just adds to the frustration and internally we do have some workarounds to be able to get to that number. But those workarounds aren't perfect and, depending on the complexity of the group subgroup project structure, they don't always work. So here's a quote from a support engineer that you know I, don't think we can expect customers to use our workaround or go through each shared group and count the members.

A

So it leaves the support team with the time-consuming, a job of proving billable members. In one scenario, we could only find 13 members, not 16, as the count displayed so we're in the position. You know as a company of saying, like we're billing you for 16, but even internally we can only find 13. So obviously this is this is a problem that is affecting both the customers and our internal team and something that we really need to solve.

A

So the job to be done here is when I'm reviewing the costs associated with my comp plan. I want to be able to audit the users occupied seats in my subscription, so that I can account for the cost and ensure that I'm not paying too much for my subscription.

A

So the first thing I want to talk a little bit about info is information architecture. So we have this sort of idea like we're going to list the users that are occupying the seats, but where does this live and the question that always comes up when we start talking about this? Is why don't we just use the group members page? Why can't we just put it on the group members page somewhere? You know, as I said before, like often the group members page, that number conflicts, so why couldn't we just make it make it equal?

A

So, in order to talk about that, I want to talk a little bit about permission, inheritance and how users occupy seats, so I always find the best way to do. That is an example. So I've created a little structure here, so the our group is Acme corporation I have a couple subgroups and a couple projects and I assure you.

A

It doesn't get any more clever than this, so the lab subscription we're going to go we're going to apply directly to Acme corporation, so the get lab gold subscription is apply to that parent group and then all sub groups and projects underneath of it get the gold features.

A

So when I add users into Acme corporation, because permission inheritance travels downward and get lab. That means that these two users, the purple and the green user, are a part of all sub groups and all projects below at the corporation. However, that's not true upwards. So if I add users like this orange user or this blue user into one of the sub groups, they travel down. The inheritance travels down into the project, but it doesn't travel up into the parent group.

A

So, if we're looking at these three users- the orange, the blue and the red that are in these, like nested sub groups and projects, it wouldn't be accurate to say that they are a member of the Acme corporation group because they don't have access to the Acme corporation group and all of the permissions that come with that, for example, like this, this red user over here would not have access to any of the sub groups or projects over here that they would have if they were a part of Acme corporation.

A

So, even though it might make sense to our users for this information to be surfaced on the group members page, it also opens up a whole can of worms when it comes to permissions.

A

How we talk about permissions and what those permissions mean in terms of inheritance, what we're really talking about when we're talking about these five users and getting a like list of these five users is we're talking about the organization, the Acme corporation organization, so that's tricky because we don't have the concept of an organization in get live comm today, eventually we'd like to and that's something that the manage team is working on with the spaces initiative. But in absence of that, this is something we need to solve today.

A

So we decided to locate this in the closest thing to an organization in get lab comm the subscription billing page. So going back to that place where you say seeing your seats currently in use, we added a little button that will link out to the list, so you can actually see that usage and see who is contributing to that number.

A

Eventually, we we see this as sort of a temporary location. Eventually, as we develop that organization concept in get lab comm, we want this to live somewhere within that organizational concept. But for now I think this is a pretty logical place for it to live and I think it will. It will help calm down a lot of those like Oh, like you know what. Why is it saying six versus five here?

A

So, let's dive a little bit into the list, so my p.m. worked with a lot of a lot of internal folks customers to come up with a list of like what are. What are those information points that we really need to be able to audit see usage? So what we came up with is name username email address highest memberships, so that will be the group or sub group or project where the user has been their highest permission and then their role within that within that group or project.

A

So initially, when I started working on this I was looking at different patterns that we have for displaying users and I I started with reusing the same user list pattern that we use on the members page.

A

So this is pretty much exactly what it looks like on the members page, but you know, as I was working on this I really felt like I. Don't know how clear this is. I think I can do better if I explore some different options here. So that's how I landed on a table pattern, and this was something that I really wanted to make sure that you know we were communicating with manage and making sure that they were on this kind of this kind of shift in how we're presenting users.

A

So we collaborated with them and ultimately, we determined the table. Pattern was a much better way of presenting this information. So a a big shout out to everyone. That's worked on the table component Nick post. A lot of other folks have worked on the sorting and like fleshing out the table component, so it was actually really easy for me to come in and use this component. So major shout out to everyone. That's worked on this so going back to the idea of MVC we're going to start with a very like pared down version of this.

A

So it'll really just be a list of users and email addresses, but over time we will start to add in some of that complexity around. Where is their highest membership? Let's link to it, let's be able to search or filter. So you know I can say, let's see all the Hat men's, let's see all the owners etc.

A

And then, in terms of further iteration, there was another theme as I was going through this issue, as I was looking at the customers that did wait and there was another theme that really started coming up for me and I was starting to see this trend. So here's another quote from a gitlab customer I want to determine both one.

A

Should this person have access to this repo group as well as two should this person be burning, one of my not inexpensive licenses, so I started thinking about like okay, so this list is going to give you a sense of like who is burning those licenses so to speak. But what, if I determine that one of those users shouldn't be?

A

What would the what would be the steps that I would have to take, and at least currently, if we're, if we're looking at, if we're looking at this iteration, you know I would have to go to the Acme corporation group and I have to remove them, and then, if they were in another nested subgroup or project I have to come back here, refresh see where else they were go they're remove them. It could be like a very manual and time-consuming process.

A

So another sort of job to be done came out of that of the first bid is the same. You know when I'm reviewing the cost associated with my plan. I want to be able to audit the users so that I can remove users who do not need access and should not be costing my organization money. So this is just a. This is just a quick mock-up. We're gonna refine this a little bit more as we as we dig into this specific issue.

A

This is a separate issue, but basically adding the idea that you can remove someone completely from your subscription, so remove them everywhere that they are. Of course, this is something that we're going to want to likely do some solution, validation on because it's potentially you could potentially lose access to certain things if they're an owner and they've created like certain groups or projects that they have ownership of.

A

So you know we want to, at the very least, make sure that you're really sure that you want to do this and really show the user. What the ramifications of that could be, but I think this has the potential to be really valuable for users who are trying to manage their subscription.

A

So the next steps, the MVC, is making this information available via API and then the simplified list in the UI, and then this is currently just for get lab. Comm we're going to be exploring similar functionality for self-managed, but it's gonna be a little bit different, because self-managed does have more of an organizational concept: okay, the instance itself, so that's something both self-managed and com. Customers have asked for this functionality, so this is something that will definitely be exploring for them as well.

A

So thank you. That's all I have.