Research usefulness of text "This merge request will start a merge train when pipeline X succeeds"

This is an actionable insight from the UX Department: MRs experience async critique research (insight).

What

In the merge request widget, when using the merge trains feature, below the button Start merge train when pipeline succeeds it reads This merge request will start a merge train when pipeline X succeeds.

The button hasn't been clicked yet, so saying that it “will” seems incorrect. It also looks redundant to repeat the same information twice.

How

Look into the usefulness of that message and if it's possible to remove it or reword it.

User testing quick answer test

https://app.usertesting.com/dashboard#!/study/3587334/sessions

- Findings

https://app.usertesting.com/dashboard#!/study/3587334/metrics

- Conclusion

A common interpretation of the text is When the pipeline in progress succeeds, the merge train will Start/MR will be added to a train. This is the same as the message communicated through the button text as well.

added Category:Merge Trains UI text devopsverify grouppipeline execution merge request widget severity4 typebug + 1 deleted label

mentioned in issue ux-research#1073 (closed)

mentioned in issue create-stage#12768 (closed)

added to epic &4926 (closed)

marked this issue as related to ux-research#1073 (closed)

added sectionops label

mentioned in issue gitlab-org/quality/triage-reports#951 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1037 (closed)

added featureenhancement label and removed severity4 typebug labels

added typefeature label

mentioned in issue gitlab-org/quality/triage-reports#1100 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1207 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1270 (closed)

mentioned in issue gitlab-org/quality/triage-reports#1432 (closed)

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

@v_mishra As we are preparing for gitlab-com/www-gitlab-com#11204 (closed) where the rest of open issues from the MR async design critique will hopefully be handled, we want to ensure that all these open issues have clear design proposals. At first glance it seems like this is actually a bug where the message should not be visible in this state. However, it seems like the next state would be this:

I thus wonder if the design proposal should be to just completely get rid of this message, as it doesn't seem like it's correct in this state, and we already communicate this differently in the state where it would actually be correct. What do you think?

@mvanremmerden I get your point, message does seem redundant. If we could only retain the More information link in some way that'd be helpful. There should be some way for users to get to the documentation to understand what would starting a merge train really do.

@v_mishra That's a very interesting point indeed. I wonder if this should be one-time information that we could solve with e.g. a dismissable banner attached to the widget, like this.

That would allow us to ensure that each user has the chance to see this when they start learning about the feature, but keeps this space clean for users who are already aware of how it works.

@mvanremmerden putting the info in dismissible banner seems like a great idea The message could go like:

ℹ️ This action will start a merge train when pipeline X succeeds and add the merge request to it. More information.

(May be more refined).

---

Also, I just noticed this is labeled ~"group::continuous integration" . Looks like the problem is still being validated as per the point in the KR - [ ] Ensure that all 29 open issues are valid, have clear proposals, and are ready to be implemented.

I wanted to confirm if this is to be taken up by continuous integration team for implementation?

@v_mishra I like the general direction, but if we put the focus on trying to educate users about how merge trains work, I wonder if we need to put the focus more on explaining what this actually does behind the scenes. Maybe something closer to this sentence from the docs:

A merge train is a queued list of merge requests, each waiting to be merged into the target branch.

The audience here would really be first-time users who we need to educate about the concept once, so that in the future they (1) know the general concept and (2) know where to go for deeper information (our docs). Maybe @aqualls has an opinion about this as well, as she has been working on this widget for quite some time now.

I wanted to confirm if this is to be taken up by continuous integration team for implementation?

That's exactly what we are hoping for. We are currently trying to ensure that each of these issues is ready for implementation, so that when the quarter with the new OKRs start, each of the designers can put these issues in front of their PMs to be considered for the next milestones.

marked this issue as related to #325529 (closed)

We also have #325529 (closed) which could potentially negate the need for this issue.

@pedroms after discussing with @thaoyeager I figured that we couldn't get to the implementation of #325529 (closed) before Q3. I think we should provide an MVC solution in the meantime.

@v_mishra UI text is easier to iterate on, so that makes sense to me. In any case, will you have capacity to do solution validation for #325529 (closed)? Or did you also include that when you mentioned “implementation”?

@pedroms I missed mentioning that prior to implementation, we are targeting to wrap up the validation for this too cc: @jreporter

mentioned in issue #328543 (closed)

marked this issue as related to #328543 (closed)

mentioned in issue gitlab-com/Product#2445 (closed)

added needs weight label

added FY22Q2 label

mentioned in epic &5866

changed epic to &5866

assigned to @v_mishra

added workflowdesign label

removed [deprecated] Accepting merge requests label

mentioned in issue gitlab-com/www-gitlab-com#11676 (closed)

mentioned in issue ci-cd-ux#41 (closed)

added frontend label

mentioned in issue #332435 (closed)

changed the description

mentioned in issue #334131 (closed)

@jreporter @mvanremmerden @pedroms after conducting a quick answer test on UserTesting, it appears that a common interpretations of the message

• This merge request will start a merge train when pipeline X succeeds

is When the pipeline in progress succeeds, the merge train will Start/MR will be added to a train. This is also what we communicate through the button text Start merge train when pipeline succeeds.

The message doesn't clarify the reason for waiting on the running pipeline and users still have to click on the more information link to understand the need to wait on the running pipeline(because its a merge request pipeline).

I've created another issue to improve the messaging based on the insight from this issue: #334131 (closed)

@v_mishra Wonderful, thanks for the quick summary and taking action based on that feedback!

Great summary and illustration of iteration! I will look at adding that to a needs weight issue shortly @v_mishra

@jreporter as the purpose of this issue has been met I'm closing this.

closed

removed from epic &5866

unassigned @v_mishra

changed milestone to %14.1

removed needs weight label

marked this issue as related to #334131 (closed)

mentioned in merge request !71687 (merged)

removed 1 deleted label

added Actionable InsightExploration needed label

added closedcomplete label

mentioned in issue #459885 (closed)

mentioned in issue #436348 (closed)