GitLab UX Team, 1 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: UX Showcase - Work Items & Hierarchy

Description

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

A

Well, awesome: hey y'all, I'm alexis product designer in plan, so I'm gonna try to quickly talk through this. um It's something I started recently ideating on um and I want to go over this quickly, so we all have time to watch.

A

Austin and daniel's awesome async presentations, all right, so I am working on something called work item hierarchy and what I mean by that is basically the idea that um users want to decompose projects- and I know that's a weird word, but decompose projects or goals, and then they want to visualize and organize that breakdown in a hierarchy, and they want to do that in this way, because it it really helps teams estimate work more accurately, because the work is then smaller and well more well scoped.

A

um It also helps everyone see either how their work is contributing or cascading up to use nick's term as well, and how it's cascading towards these larger goals, which is really motivating to teams as they're working. They can see how their smaller items are contributing to something larger, um and it also helps teams plan and understand, of course, like who's going to work on what and when. So you can see some of the jobs to be done.

A

I'm looking at here, um we currently do allow users to break down goals using work items like um ethics and issues and a thing called sort of a sub epic or a child effect that they connect under epics. You can see some of that here. We also have items like requirements, test cases, incidents uh soon, tasks that holly will be talking through.

A

So these all allow users to create a sense of hierarchy while planning um some teams may want to use different types of objects or work items, or they might call them different things like. Maybe they call it a feature instead of an epic depends on the framework they use, but the general idea is that goals are kind of different sizes and they have different levels of hierarchy right. So some goals are large and they're more.

A

I guess stakeholder facing right, that's kind of like an epic. Some goals are smaller and they're more team facing, so that a team can understand what to work on and do that work kind of like an issue or again, maybe some users might call that a story or a task or a ticket, but again all kind of the same thing, uh just goals that you want to work on, so you know call it different things, but the idea is the same, so you can see here how we do that currently within gitlab.

A

This is how we allow users to create a sensor hierarchy in their work through things like epics and child epics or sub-ethics, and then issues and then in the future. Then like holly will present. Maybe things like tasks or incidents.

A

So that's our current state. We had here a lot of feedback, however, that users don't fully understand what the intended hierarchy within gitlab or the breakdown structure within gitlab is so, um and this is further impacted by a lot of things. Nick already mentioned, um like epic discoverability being hindered by them being in groups uh and the idea of groups and projects in general users, maybe not knowing they can nest epics.

A

Maybe users not understanding requirements or really knowing how to use them or where they are so a lot of that kind of stuff and um again I'm really excited by workspaces and some of the things we're ideating on there. I think that will also help with uh a lot of the work and plan, so thank you nick for setting that up, but for us uh the first step is really just addressing um making our hierarchy or our structure more apparent to users.

A

uh So you know educating users on what is possible. What the current status of their work items is uh within their groups and projects. uh You know where are things: how are they? How are they supposed to be nested? um Are they even on or not because users can turn things on and off like issues, so I did a lot of quick ideation here. um This was a fairly quick uh exercise. I guess- and um I really wanted to go through things like some of these things here.

A

uh Moving configuration out of settings kind of like I mentioned before, you can turn items off, uh usually within settings and it's a little inconsistent there. So you know what would it look like if we took some of these items outside of settings made it more contextual, you can configure things more contextually.

A

Could we educate users on the hierarchy? You know, how are we going to do that within the section? How do we enable customization of hierarchy, maybe or maybe customization of work items toggling them on and off disabling them within again the section?

A

How do we display relationships between these items uh getting into kind of like data modeling, which is confusing to me, as you can see, with this this little thing here, um like the one to many many to one one-to-one relationships of these items, uh requirements things like better integrating items like requirements into the hierarchy?

A

So how do we display items that are not within the hierarchy like, uh I guess, really requirements and test cases at the moment um and then kind of the idea of- and I want to talk with jackie and the growth team about this in the future, but displaying features that aren't available to users and educating them on these without it feeling too upselly and then also things like integrating feedback or like soliciting feedback within these uh features themselves.

A

So um I went through a lot of uh different directions here, but we only have about one point of engineering effort to dedicate to us for this milestone, so we obviously want to keep this change very, very, very small and um run enoughly if possible, so oops and next, because of that, I next want to continue validating uh this idea that we've come up with um and further exploring object objectives like uh what is the user's mental model around some of the labeling here, uh there's a lot of terms floating around kind of, like I mentioned earlier in planning.

A

So you know we have these safe framework. We have different agile planning methods, um there's features, there's uh the work, breakdown structure and the value breakdown structure, there's all sorts of stuff. So what do users expect to see here? How do we speak their language and kind of? How do we allow them to customize that language?

A

If we want to be flexible, I want to continue validating where users expect to access this information, or some of the information that might have historically lived in settings and kind of breaking that out uh continue validating the usability um educating users on again kind of what I mentioned before, like how do we upsell with that without upselling, like make it more about educating people on what's possible and then also the best way to ask or for feedback within this item itself and then there's a lot of future state kind of things.

A

We'd like to do that, I sort of touched on before, but things like customizing this hierarchy, customizing the work items themselves like I mentioned before. Maybe they don't want to call this an issue. They want to call it a story, or maybe they want the story or the issue to contain different kinds of attributes like how do we allow them to configure this, um and then this could also become sort of like a workflow rules and automation area.

A

um So you know maybe when it leaves the to-do column, there's a set of like rules that that triggers things like that and how do we allow users to customize that and um like some users actually want to break work items down in a visual way like this and kind of call the work breakdown structure so um investigating how we might allow them to do that as well kind of like those different views that users can view their work items so lots of stuff there that I want to continue working on and then also we want to integrate the learnings here into future.

A

I guess what I'm calling widgets, because we've been talking about widgets a lot lately and we're going to be working on how to best translate this hierarchy or the breakdown within work items like epics and issues themselves.

A

So the first step here could be just improving our current epic, true widget, and then next would be perhaps expanding this area, it's maybe a sort of widget to view and edit relationships really in dependencies like across all work items, and maybe even rolling, merge requests into that. So you can really see and map out um all the dependencies and relationships between all work items.

A

So that's a lot and uh that's not why that's why I have not deep dive dove into this at the moment, but we'll get there, um but yeah we'll get there in the future showcase. That was the surface thanks all for listening. um Hopefully I kept that short enough that we have time to watch the other presentations thanks. Is there any questions.

B

Thanks alexis, uh actually, it leaves us even more time for questions uh and comments. uh Jackie, do you want to make a connection real, quick here.

C

Hi I mean my comment is just you could read it um just you mentioned talking to us in growth about teaching customers about features without you know, being up silly or being obnoxious, and so kevin is actually our expert on this and we're working on a bunch of things. We have lots of ideas planned um and we would love to work with you on it. So it's out soon.

A

Awesome, I'm excited yeah, like I said we're just keeping this super duper small, but I'm really excited to work with kevin in the future.

B

Austin, what's your question yeah.

D

um Alexis I wanted to get your perspective uh as you're kind of walking through the hierarchy page as you kind of outlined it in the gitlab ui. What makes something a good candidate to go inside, gitlab versus just documenting it in our docs or maybe in pajamas or somewhere else,.

A

I think it's it's kind of the goal like the goal aspect I mentioned, so if you think about epics like stakeholder facing goals like I said before that um this is this large thing we want to work on and then smaller work items like issues are the actual piece of work that's being implemented.

A

I think, if you go even higher than that, where you're kind of collaborating, maybe on like a canvas or a strategy, I think or like documenting single source of truth, that you don't want to disappear at all, like that's kind of where I would imagine wiki or docs, and I know michael's been doing a lot of work here.

A

But, like honestly, that's so interesting to ask that, because I feel like that's something I really miss sometimes at get lab is the idea of a doc um and maybe starting at an even higher level than we're sometimes able to um and collaborating at that high level. So I think it's like you're not really working on something yet you're you're discussing collaborating on it at a really really high level. Does that make sense.

D

Yeah a little bit it did, I think, where I'm hung up is, I feel, like I've, built a mental model of the hierarchy of these objects and get lab in my head. So when I see it appear and they get live out, I'm like I feel like this is a documentation page that's appearing inside gitlab, but maybe I'm just not fully understanding the vision of like the uh way that teams might collaborate to maybe customize that hierarchy.

A

So you mean like the the hierarchy page itself, you would imagine yeah. So me too, honestly, I I kind of pushed back on this and I was like so why isn't this a docs page? And I think it should be right and we do have documentation here especially around?

A

How do I kind of translate the way I'm working into gitlab, for example right like so? Maybe users that use competitor products have a different way of working and we try to educate them on how to fit that into the hierarchy we sort of prescribed right. So we have a lot of things like that um and I think honestly um kind of, like I said for mvc here, to keep it really really small.

A

It is kind of really just education to start out with and then we're enriching it with um some of the future items I mentioned like making it more customizable and maybe editing the work items themselves so for mvc.

A

Yes, it is more of an educational kind of object here and a way to solicit feedback and really just help under help users understand like the status of the hierarchy and work items. Just for for nbc, but yeah good question, I kind of have the same question, but the vision is to make this uh a way to configure things like hierarchy items.

D

Sweet yeah, thanks for entertaining, I think I did like work with growth- would be great too, because I'm sure they also deal with that like attention of how much is too much in the product and trying to balance the documentation versus, like the user guidance, all good things. So, thanks again,.

A

Chris good thing, we got a lot of a lot of awesome writers, as we just saw in the last presentation to help us out with this so yeah. Thanks for your question,.

B

Thanks so much alexis and great questions uh and connections already um time for us to move on.