Skip to content
Snippets Groups Projects
New issue look: Off

General navigation tasks

    • Closed Issue created by Sarah O'Donnell @sarahod

    Videos

    User 1 - http://bit.ly/2mMbwiF

    User 2 - http://bit.ly/2ne2VZp

    User 3 - http://bit.ly/2ndRuAG

    User 4 - http://bit.ly/2mkMFXd

    User 5 - http://bit.ly/2mlCyRR

    User 6 - http://bit.ly/2nDRhb7

    Findings

    For each area, the findings are ordered by priority (higher > lower), based on the number of occurrences, current negative impact, and possible positive impact by addressing them.

    Project navigation

    1. It isn’t immediately obvious to users that there are two levels of project navigation. This is, in large, due to the fact that users have to click the primary level of project navigation, in order to view the second level of project navigation. Even when guided, some users still overlooked the second level of navigation, scrolling past it to see the main body of content on a page. UX READY: https://gitlab.com/gitlab-org/gitlab-ce/issues/22069

    2. Task 4 takes users directly into a project, exposing them to the project navigation. However, the project navigation isn’t memorable. Users who failed to visit the project navigation again during testing, never mentioned or attempted to try and find this level of navigation again. Therefore users weren’t only lost within the navigation, they had no concept of the different types/areas of navigation that GitLab has. ** https://gitlab.com/gitlab-org/gitlab-ce/issues/29878**

    3. We use the language ‘personal projects’ within the Profile area of GitLab. In the Project list we refer to personal projects as ‘Owned by me.’ To add further confusion, one user didn’t understand if ‘personal projects’ referred to projects in his personal space or whether it meant projects he had created in any group (a view which I don’t think we currently offer?). When he selected ‘Owned by me’, he stated that these were all the projects that he was the owner of, when in fact he was the owner of multiple projects residing within different groups. UX READY: https://gitlab.com/gitlab-org/gitlab-ce/issues/29790

    4. The user needs to go into a sorting dropdown to find projects ‘owned by me’. That is a filtering action, not a sorting action (as pointed out by @cperessini). UX READY: https://gitlab.com/gitlab-org/gitlab-ce/issues/29045

    5. As it wasn’t immediately obvious to users how to sort their personal projects / projects ‘owned by me’, some users proceeded to count the projects in their personal space. Should be fixed with https://gitlab.com/gitlab-org/gitlab-ce/issues/29045

    6. When users were directed to the latest comment on an issue thread from an email notification, all users had to scroll to see the status of an issue. No users referred to the history of comments on the issue. https://gitlab.com/gitlab-org/gitlab-ce/issues/17697

    7. When a closed issue has an open merge request, some users confused the status of the merge request with the status of the issue.

    8. The ‘Global’ notification menu found within projects was mistaken for project settings. Added a note about this here https://gitlab.com/gitlab-org/gitlab-ce/issues/29878

    9. One user mistook the + icon within projects as a way to add a ‘new member’ to a project. Whilst this user may be an edge case, it is worth noting his behaviour due to the new prominence of the + icon in the global navigation. https://gitlab.com/gitlab-org/gitlab-ce/issues/23603

    10. When the default project view is changed to ‘activity view’ and a user clicks into a project to see that the setting has been applied, they expect to see ‘Activity’ highlighted in the main navigation, not ‘Project’. It causes them to doubt their actions when ‘Activity’ isn’t opened by default. https://gitlab.com/gitlab-org/gitlab-ce/issues/29881

    11. The ‘Project settings’ page is overwhelming, it contains a long list of options and it’s hard for users to find what they are looking for. In addition, we also provide ‘Sharing and Permissions’ on the Settings page, subsequently some users thought they could add a new member to a project / see all members of a project from this page. https://gitlab.com/gitlab-org/gitlab-ce/issues/28451

    Group navigation

    1. When creating a new project within a group, users often thought they needed to be located within the group they were asked to add the project to, before they proceeded to click ‘New Project’. Combined with https://gitlab.com/gitlab-org/gitlab-ce/issues/23603

    2. When trying to find out who the members of a group are, there is inconsistency between project and group settings. To find a project’s members: Settings -> Members. To find a group’s members: just click Members. Subsequently some users initially went to Edit Group (group settings) in order to complete this task. https://gitlab.com/gitlab-org/gitlab-ce/issues/29893

    3. Users have to manually count the number of projects within a group. UX READY: https://gitlab.com/gitlab-org/gitlab-ce/issues/29798

    4. Similar to the 'Global' notification menu within projects. The ‘Global’ notification menu at a group level was also mistaken as a filter. Users do not read the text beyond the bold headings which means they do not understand its context. Combined issue with https://gitlab.com/gitlab-org/gitlab-ce/issues/29878

    5. It wasn’t always clear to users when they were navigating within a group as opposed to their full list of projects. https://gitlab.com/gitlab-org/gitlab-ce/issues/29879

    Sidebar

    1. There were two extremes of user behaviour when interacting with the sidebar: 1) Some users didn't instinctively interact with the sidebar as it isn’t open by default. For example, it took User 3 9 minutes to spot there was a menu available. Those that did find the sidebar easily, typically proceeded to treat it as their primary method of navigation during the testing. Subsequently, this meant they often failed tasks where the content couldn't be found within the sidebar. Combined with https://gitlab.com/gitlab-org/gitlab-ce/issues/29878

    2. Within the sidebar, users expect to see the number of projects and groups they are a member of. This would provide consistency as we already show the number of issues, merge requests, etc a user is assigned to.

    3. When users land on the Issues or Merge Requests page, they typically start interacting with the filters. It isn’t clear to them from the list alone which issues/merge requests are assigned to them and which have been created by them. The only filter which is pre-populated is ‘Assignee’. One user commented that he wanted the ‘Author’ filter to state ‘All’ as that’s what the list was showing him by default - issues/merge requests by all authors. https://gitlab.com/gitlab-org/gitlab-ce/issues/29882

    4. Users feel anything belonging to them ‘My issues’, ‘My merge requests’, etc should appear within their profile. Possibly because we show the user their ‘Groups’, ‘Contributed Projects’ and ‘Personal Projects’ within their profile. Subsequently, I do not think users initially realise the sidebar navigation is relevant to them, hence their reaction to amend the filters on the Issues / Merge Requests pages i.e. they believe 'Issues' within the sidebar shows them all issues regardless of project or assignee. This theory could be further supported by the fact that users think there is no other navigation available which shows them all issues (remember they have little comprehension of the project navigation). An example which supports this theory is: User 3 first checks out his profile to see 'groups I am a part of' and tries to compare it to 'Your groups' in the sidebar navigation, expecting to see a difference. Whilst I think users gradually understand that issues, merge requests, etc in the sidebar are relevant to them, I'm not sure whether they initially do. I think this may need more research. Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/29878 and https://gitlab.com/gitlab-org/gitlab-ce/issues/29882

    Global Navigation

    1. Users do not understand what the ‘Todos’ icon represents. It was mistaken for “unread messages” and “notifications”, not a task list which the user needs to action. This was further emphasized when one user remarked that once he had viewed an item, he expected it to automatically reduce his number of ‘Todos’. He didn’t understand why he needed to click ‘Done’. OPEN MR: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7827

    2. Users do not realise that the tanuki is interactive and will take them to their default dashboard when clicked. Multiple users adjusted their URL to return to their default dashboard. Combined with https://gitlab.com/gitlab-org/gitlab-ce/issues/29878

    3. When users click the arrow which appears at the end of the group / project breadcrumb, they expect to only see projects which belong to the group they are currently in. https://gitlab.com/gitlab-org/gitlab-ce/issues/29885

    4. The breadcrumb for the group / project you are in, only displays names and not paths. Yet when we ask a user to create a new project within a group, we ask them to specify the path. This causes confusion as the group / project name could be different to the path. https://gitlab.com/gitlab-org/gitlab-ce/issues/29886

    Search

    1. Users expect to be able to multi-select items from the menu that appears when the search bar is clicked in i.e. ‘Issues assigned to me’ AND ‘Merge requests assigned to me’ (rather than OR).

    2. Users expect to find help topics within the search bar. https://gitlab.com/gitlab-org/gitlab-ce/issues/29898

    3. It’s not easy to find the most basic of help topics such as ‘creating a new project’ within the help documentation. Users focus on the things / words they are thinking of, they’re not necessarily looking for ‘GitLab Basics’. Combined with https://gitlab.com/gitlab-org/gitlab-ce/issues/29898

    4. Multiple users discussed using Google to search for help due to the fact that it lands them directly on the query they are looking for. We do not offer search functionality from https://gitlab.com/help/ Judging by how users browsed this page and their initial reaction to it, they simply wouldn’t use this page outside of a testing environment. Combined with https://gitlab.com/gitlab-org/gitlab-ce/issues/29898

    Preferences

    1. Users got confused between their ‘Default Dashboard’ view and default ‘Project View’. https://gitlab.com/gitlab-org/gitlab-ce/issues/29887

    2. When updating default project view the notification ‘Preferences saved’ is at the top of the screen away from the CTA. The user clicked ‘Save changes’ multiple times, as he had to scroll up in order to see the notification. https://gitlab.com/gitlab-org/gitlab-ce/issues/29888

    Other (Todos)

    I feel further research of ‘Todos’ is required. However, I feel the below was evident from testing:

    1. Users do not realise that ‘To dos’ are personal to them. For example, User 2 thought it was what each team was working on.

    2. It isn’t immediately obvious to users that the ‘Todos’ page contains a mixture of issues, merge requests and @ mentions unless prompted.

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply