Blog Don't hide primary actions
Published on April 1, 2021
3 min read

Don't hide primary actions

In our testing, we found there was confusion in setting up subgroups with a wide range of research participants. We wanted to reduce confusion in setting up subgroups in GitLab.

Blog fallback hero

Organizing your projects into groups within GitLab should be a simple matter for new users. We conducted a Category Maturity Scorecard validation to see how we were correct to assume that it was easy to model your organization in GitLab so that teams could have clear boundaries between other groups. What we found during our initial testing, however, was far off from this assumption.


Looking at this organization chart, we assumed our test participants would have no trouble creating this structure in a test environment.

Sadly, this was not the case:

  • Five test participants could not complete the task in 30 minutes.
  • One confused the difference between Groups versus Projects but could (inaccurately) recreate the structure in GitLab in approximately 3 minutes.
  • Only one person was able to complete the task accurately in around 3 minutes.


The primary problem we found was that our participants could not find a way to create a subgroup. Success depended on creating subgroups, but the button to create a new subgroup was not easily discoverable. The participant would have to go into exploratory mode and click to see what was in the 'New project' dropdown to find it. This problem with button dropdowns and primary action discovery also occurred within the Comment button in Merge Requests.

Image of dropdown button

The second observation was that the user experience and logic of building an organizational system are not intuitive for new users.

Participants expected:

  • A more graphical user experience with interactive boxes and lines
  • A way to perform the task through the command line
  • A way to import the org structure from another system

Participants could not determine the difference between a group or a project or how they were related. There was no visual indicator of what the difference was or what features related to Groups or Projects.

Solution proposals

For an initial recommendation to address the confusion, we wanted to separate the primary dropdown button.

Image of 3 seperate buttons

Hiding features under dropdowns assumes the users understand they can access additional actions if they click the button's dropdown area. As well, two disparate interface actions shouldn't juxtapose if they have no direct relationship.

We assumed that we could split up this button into two for an MVC and have better results. After another round of testing, we were able to achieve far better results. Our test participants completed the task of creating the group and project structure quickly and found the task easy to complete.

This one simple trick

By breaking apart the 'New project' and 'New group' buttons, we could make the 'New group' action discoverable. After we made this change, participants had no trouble interpreting the scenario and executing the task within 5 minutes.

Next steps

Currently, we are looking at how we can improve sharing groups and features. We want to remove the barrier between groups and projects. We believe that this will help with some of the problems users have with sharing across groups, and they will be able to take advantage of features that provide them with a more connected set of groups. This change will also improve our information architecture by reducing the confusion around how objects are connected, making navigation and cross-team sharing easier in the future.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert