GitLab Progressive Delivery, 21 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Progressive Delivery UX/PM meeting 2020-07-21

Description

Meeting to improve alignment between Product Management and UX for progressive Delivery

A

um Yeah so first point: on the agenda's mind, this is just a quick for your information.

A

In the interviewing uh interview, notes of a b testing, I've started a slightly different structure of the interview notes because one of the interview interviews um word was participating and we're just all scribbling through each other. So I thought, like hey how we were originally doing it is. I know the notes like you created in excel um lori, so I kind of took the same approach and it it kind of works like it's pretty good. I I better.

A

I take better notes because of it inside dovetail and I rather take notes inside dovetail than in excel. I don't know, maybe it's just because it looks nicer, um I'm just not a big fan in excel taking notes just for calculations, it's perfect, but notes, I'm not fond, but hey. This is the best of both worlds and with a little css hacking, you can kind of expand your view and then everybody can take notes which, as much view space as they like.

A

So it's more of an informational thing that I already discussed in the 101 we had last week. I think or it I I wanted to discuss it in this- that I saw this one wasn't going through like it wasn't. That's such a dutch thing to say wasn't going through like that is not proper english.

A

I I'm I'm noticing more and more of these kind of things, but that's exactly how you would say it in dutch, um but yeah like uh there's, there's not much more to say just a free information so on to the next point.

B

Nadia on the mute button yeah, um so I just wanted to give a heads up around some of the thoughts that we are actually having, but immediately getting some like actually valuable feedback, so just as an fyi, but also wanted to hear your thoughts, we are uh in verify ci. We are thinking of like experimenting with creating additional label uh like saying um to uh how do you say to um highlight the issues that are requiring some uh developer experience?

B

um Let us say, support so developer. Experience is pretty much same thing as a uh as a user experience, but it's like prefer it's a it's an explicit um importance and explicit highlight on the developer persona.

B

So uh by uh creating those labels, uh we would be like highlighting the issues that would need uh ux support on functionalities like I know, yaml cli apis and you know templates, and you know like something that would not be necessarily user interface related or not with no will not be really typical user experience, but yeah would be more like a technical, featuring and uh maybe some thoughts here of the people. Do you think this is useful?

B

Do we need this kind of a separation, or we should instead rather be expecting from the user experience designer product designers to just like hey? This is a part of user experience, so why to even separate that, what do you think? Let me just see you write something.

A

I'll all vocalize my my thoughts here does this indicate perhaps a potential lack in granularity of her persona. So what I'm saying with this is like hey? Are we intending it like hey? This can be for the software developer persona, but this is one that is the beginning, like a beginner level persona. This is like a pro user like one which has five plus years experience in the field. I don't know something like that.

B

uh No, I wouldn't necessarily say that we intend, with this to um you, know like differentiate personas or like break them even more down. No, it's just for us for better structuring of the work, um maybe to indicate you know that hey if this label is on the issue, that means maybe ux or product designer needs to work closer with the engineering on this issue particular or collect some knowledge around. I don't know whatever topic, because it's a bit more technical that maybe we have the the the information today.

B

I don't know thinking more in that direction, but uh open to hear your thoughts.

B

Or all right, I see you also put a comment.

C

Yeah so in general, I like the idea- and I understand the rationale and the reason is because a lot of our developers are not going directly through the user interface and they may be going around. So I like the fact that we're talking about.

A

C

um That's an entry point for a lot of our users, um the the downside that I think is that I think there might be a little bit of a duplication because a lot of our users are developers.

C

So then, what's the difference between a developer experience and a user experience, because they're the same sometimes- um and I don't know- um is this including apis like? Is it if it's only around the yaml? I understand, but there's a lot of other like technical, mumbo jumbo that goes around it that I don't know if we're thinking about it. So api is an example, but also like kubernetes.

C

If we're going into the kubernetes configuration. Is that a developer experience is that, like I don't know, there's so many use cases that we can talk about? I don't know.

B

Yeah no, I agree with that. That's a similar pushback that I received from uh jason and the canyon. I think it's a valid thing. It's like um yeah, if we are working at the gitlab like uh most of our uh customers and users, are using those types of like technical features um but yeah so yeah.

B

This is why I'm asking like I don't see a big um yeah kind of like was uh got excited about this idea, but now, when I think more about that, I don't see really a big use case here and it seems like it's something directly clear to people. So I don't know. Maybe I just also need to bring it back to the ux managers and you accident ship and see what they think um maybe grow maybe grow. This idea a bit better.

C

I think anything that we can do, though, to in terms of improving in the yaml experience is great.

B

Yeah, because I don't know a real question to you, um how often do you think we involve user experience or product designers into a feature development like uh yaml templates, like uh cli experiences, like I don't know a configuration of apis or whatever like do. We include you exercising? Do you think that that's useful to do.

C

I don't know how to answer that.

D

C

Sometimes we we tag them, and sometimes we don't. It really depends how deep and technical this is like. um Definitely for anything, that's documentation. I don't tag dimitri at all, um but other things like like the autodevops connectivity of all the templates that we're doing for aws I've tagged the major. I don't think that he's I mean we can ask him because he don't want to call, but I don't think that he's been very active on those because there's not no additional, you know ui, but he's definitely in the loop.

A

I I am in a loop, um I would say most often I am involved in the conversation. If it means um there will be effects throughout the ui because of yaml changes or because of like hey, how is the user flow going to be? um You.

B

Said it's sorted, that's very important thing is that if that will affect ui.

A

Yeah so, for example, um sometimes a new keyboard is introduced in the yaml, and that is nice and all, but this might have an effect on the graph visualization. This might have an effect on like how it is displayed in the job view, or does it need additional feedback given to the users that something is active? I don't know things like that and if you ask me like hey, how can we catch those? Because this is more like if we go into depth on those issues?

A

I feel that the solution there would be- or at least the direction I would like to to take this in- is that if we focus on user stories in our you know, issue briefs we catch those. um You know those those uh those things earlier and we say hey is this a complete flow, we're shipping towards the user, or this is just like a feature we think the user needs, and then we don't think about the consequences now like.

A

If we think about the user story- and we see the user flow, make sense, then hey this actually does or does not need any uh changes to the ui, or perhaps also that conversation around the user flow makes sense to sometimes include the pro. You know the project designer um yeah, I would say that is more effective than a label. If you ask me on first glance but hey, that is, that is more of the direction of my thinking towards yeah.

B

I agree so actually this is kind of like see this is there. The problem comes that I'm trying to tackle, because so what? If you ask me, what the?

B

What is the problem I'm trying to solve with adding on this label, is to bring product designer into that kind of like um issue that are talking about this developer experience that are not necessarily touching the user interface, but they they have the influence or maybe even like when we are thinking about how to better, create the yaml template the yellow template um there have to be some. We cannot just like go and like like write a list of comments that would not.

B

That would make sense to a developer on a big picture, but we don't really like kind of like validate it from the user perspective side, meaning what will work best for them like what would be very usable like developer, friendly user friendly right, um so because we because I feel like in many cases, ux equals ui.

B

So if there is no ui ux is not.

C

B

C

That the issue.

D

B

D

And and you're not wrong, not yet it's it's the maturity level yeah. You start out throwing ux at things you can see and then at some point you level up the maturity and say it's not just stuff. I see it's it's everything I interact with it's from that first decision to talk to the sales person all the way through getting into the code using the api, all of things that have an interface but they're, just letters.

D

You know it's not there's no buttons or anything involved and it's the level of the maturity of the organization of the ux of the maturity of the organization. So we are moving there, but I would also argue we don't have enough bandwidth to stretch our poorer designers and our researchers even thinner to say you need to start looking at all this other stuff too. We really need to understand and scale our efforts.

D

So what I've experienced in other places is that without being able to scale which means just hire more warm bodies, you still stick to the ui piece. It's what the designers are usually used to it's easier to to design for it's easier to test and leaves that other realm for the in the more engineering minds of the company.

D

What I think we might be able to do is if we can pull the engineers into inviting some of us to some of their discussions like we don't have to come to all of them or like weigh in on an issue here or there. They may start to see hey this person isn't just drawing pretty pictures all day.

D

They are actually thinking through the process of how the user is supposed to go through these things and I'm responsible for the code, I'm responsible for making sure it works properly and presenting what needs to be presented, but they can bring their perspective as well. I think those are the conversations that need to happen, and I don't know if a label will help I mean I don't think it'll hurt. I just don't I don't know it's like.

D

We have to stop making those divisions between ux, meaning, ui and then devs, meaning dev, and we have to start partnering bringing them into the partner process just like we did with product management and uh yeah.

A

I totally agree when I look back at ci. um I often had this scenario.

A

Also because of availability- just as you said, like hey, there's so much to tackle- let's you know, but um a lot of the issues were sometimes so uh technically difficult to grasp as a concept, if only given you know like hey, this needs to go in in like two weeks like we're, gonna implement it right now, just come up with the solution right now. We need it now um like it.

A

It was very hard to sometimes dive into it in a proper way, and engineering was already leagues, leagues ahead in in terms of understanding and knowing what to talk like it felt sometimes very hard to like. Oh now, I should suddenly be subject matter expert to this thing like how can I like that is impossible, um so you know that conversation just sometimes need to start a lot earlier and be more inclusive towards both um yeah.

B

Like thanks for our thoughts, both, I think that's really good points. um I don't want to take too much time from this discussion. What I will do I'll probably will propose to like. I will revert my proposal with the label for now, just because I see so much well, not pushback, but nice feedback, uh probably I'll, just create an issue and move that discussions there. So we can hold off and like have a maybe a bit better weighted decision. What do we wanna? Do we wanna move that direction and what do we?

B

How do we wanna do it? So thanks a lot I'll uh I'll link the new issue in this in this one.

A

One suggestion uh nadia: what do you like about like, for example, the um the stage group labels and the category labels and the you know, there's a there's, a negative variant as well as the po as to the positive? If it's not this, then it's this so there's like there's this, this this space to be filled by a label. Always if it's not this label. Oh then it's the other. So there's there's not a indecisive action in between like there, there needs to be a label. That's what I'm saying.

B

I'm not sure if I got that.

A

Lori, can you phrase it better because I I thought you were understanding me. I hope hope that at least.

D

Yeah, so I think I think demetrius is saying that he he needs the label, because we need to start document like we need to start capturing these things because they're just happening and we're not we're talking too late. So if we start capturing them, it might help us to talk about them earlier. Is that right.

A

Yeah, like I I I do want to keep this short, but the thing that I'm perhaps thinking about is like if an issue doesn't have the label, how do we know that this issue has been has been considered for this label? Yes or no? So if there's a negative label like the opposite label, then we can assign that label and know that it has been considered, even though it does not align with what this this other issue or this other label needs.

C

What's the purpose of the label, though, what are we planning.

B

To do with it purpose of the label for me like where I'm coming from is uh to like indicate that um we need to think about, like that. We need to think about the user experience on the technical side. There, then. Maybe there is no direct or like this traditional ux involvement needed, but- um and that's the question like like again: do we have bandwidth for that? Do we want to do that, but it's like more hey hell, hey product designer, come and help me uh find a better experience for like this technical feature here.

B

Can I ask a question.

C

Why what in which world do you see an issue where we wouldn't want to pull in a product designer like? I think this applies for everything so like. Why do we need the slaving? Because.

B

Today we are not involving uh product designers there, because there is no ux label. That means that these issues are not getting ux attention, like maybe I'm wrong, but this is as simple as that, I would say in.

C

My mind dimitri should be on board for every issue that we're ever implementing.

C

I mean every issue that every feature that we're creating has to do with user experience. User experience is not only ui. It's everything that you do in the system.

B

So all right, what you're saying? Basically the label is not needed, like, uh like I mean.

C

Usually, we use the ux label in order to indicate that it needs some extra attention or mock-ups or something it needs extra work. It does I mean in my mind it doesn't mean hey, dimitri, don't look at it right.

A

I I do like the um because, like what I get out of is, I do like that, instead of just looking at ux issues as kind of like the lens or filter for a milestone that progress delivery should always consider all issues.

A

um I have one argument that goes hand in hand with that is that sometimes, I feel like issues that engineering takes up are just like randomly appearing within the engineering milestone, because, while they weren't planned like how does that work like.

C

A

Yeah like, for example, engineering managers might decide like. Oh. This now suddenly goes in 13.3 or 13.2, because that does happen right like I'm not, or am I wrong on that.

C

I don't think chase has a part in it. um I think the engineers what happens- and this is a process that we probably need to improve on- is that the engineers start something and then it explodes, and then they start splitting it up into smaller issues, and then they just automatically copy all the metadata from the original issue. So it automatically goes into that same milestone without giving it a thought. Maybe the priority of this is lower.

C

um So that's what I've seen happen. um I don't think anyone is like randomly pulling in issues from the backlog. It's just things that pop up and they just like continue with the same milestone and priority and everything.

A

Yeah because, like what I feel like that sometimes happens- and I I'm saying this without any evidence so much but just a feeling um is that the planning issue is not the funnel of issues going into a milestone from an engineering perspective.

A

They do not go through the the planning issue they just take on whatever like they. They they get assigned from engineering managers and they think is right.

C

It should be if, if it's not the case, then we should take this up with the managers.

A

And also like, adding in issues that they later on work like that is the thing right like it is a snapshot but difficult situation.

B

Yeah so anyway seems like we're already talking about this for quite some time I'll just like, uh because there is a discussion started I'll, try to move that in a separate issue, not with an intention to like necessarily create a label but to see if we need a solution there or not. Maybe we don't and all right hey. I see what you're saying you need to definitely see what you're saying, but yeah just want to collect the opinions and not for sake of creating issues, but hey I've started it.

B

So I feel like I cannot just like, like remove everybody's memory, so we'll move that discussion to an issue feel free to participate there and sorry for the fact that it took so much time. But it's not a really interesting thing for me.

A

C

Yeah, so I'm up next and I want to bring up spinnaker, so lori we've been kind of talking this about this asynchronously and I'm kind of stuck because I didn't really have time to invest in it, but I I kind of felt like we were getting lost in the asynchronous discussion, so I kind of want to just to share my thoughts and see how you can help me.

C

We already did a survey about spinnaker and I love the results that can be found where I in the document that I linked here and what I'm really interested in is in the last three questions. So the last three questions were open-ended questions, but they're not like there wasn't enough meat around them to like actually do anything about them. So that's what I want to investigate in this follow-up issue and and the three questions are: why did you choose spinnaker over gitlab?

C

um Which features do you need to have to to have in order to leave spinnaker and the ranking of the spinnaker features, um and that would really help me, though. The answer to those three questions would really help me with the roadmap and making like really good decisions. The thing I'm having a problem with was how to translate that into the discussion guide.

C

D

All right, why don't I take a stab at it? Where do you have a discussion guide started already somewhere yeah? I.

C

Look for the issues well, I started a discussion guide. I think I've even gave you permissions to it at some point I may.

D

Have even looked at it and I've forgotten very possible all right. Well, if you gave me permissions and it should show up in my shared files, so I'll go in and I'll look at it because I've got I've got some thoughts that maybe we can.

C

But I I've been really having a hard time like formulating that into questions.

D

Yeah- and it may I mean sometimes you just ask the question like: why did you choose that one over ours? What what was that process? Sometimes you might start out with. I know you use spinnaker. Why are you using it? You know what do you like? What do you don't like, and then you kind of hit into the harder question of? How did you come to be using it like how? How did that?

D

Why was that a thing where you are and who is in charge of making those decisions and like what was the argument made for it? So there are different ways that we can throw some words at it to ask the questions.

C

And there's also like some answers on this question.

D

Yeah I saw that.

C

That we can like it's that you can learn about like multiple kubernetes clusters, support that one came up multiple times. I just don't really know what that means, but people kept saying it. So it's probably important right and uh okay.

D

Yeah and I'll I'll do some magic I'll work. My ux research magic on the discussion guide today and see what I can come up for. You.

C

D

A

Cool, um I'm gonna push next point to the towards the next agenda, um but just to give a heads up, I think it's like there's some things currently in progress. They will be finishing up soon, at least some of them, um so I wanna. I want us to brainstorm a little bit as to like hey. Where do we want to focus on x in terms of validation track? Maybe you know maturity scorecard is the next thing, maybe something else. um So I want to have a conversation around that see how it aligns with product vision.

A

Those kind of things.

C

All right, I'm going to add another thing that I want to talk about next time, which is the north start metrics and how we can drive those. um Maybe the the next validation track needs to be around that.

A

Yeah that sounds good. Let's, uh let's have a you know a little bit of deep dive next meeting like dedicated meeting towards that. I think it's a very worthwhile discussion to have so. Thank you so much and then I'll stop the recording and see you.

A