OVERVIEW
The issue board is a software project management tool used to plan, organize, and visualize a workflow for a feature or product release. Our team explored the usability issues of the issue board and eventually narrowed the scope to helping product managers to understand current status of issues in a straightforward manner.
My Role
User Research,
UX Design
Team
1 Product Manager
2 UX Researchers
2 UX Designers
Client
GitLab Design Team
Design Timeline
4 months, Spring 2024
OUR CLIENT
GitLab is an AI-powered DevSecOps Platform. Their mission is to enable everyone to contribute and co-create the software that powers the world.
PROBLEM
As a vital tool for project management and collaboration, usability issues are hindering productivity for users.
The issue board is a flexible and customizable tool that aims to fit with different habits of users. Managers primarily use issue boards to assign tasks, ensure alignment with strategic vision and planning, assess team capacity, and track progress. However, some users are facing challenges navigating the interface, as well as creating and managing tasks efficiently. The GitLab Design Team presented us a general scope to tackle: explore what can be improved in terms of usability in GitLab issue boards.
SOLUTION PREVIEW
Our design solution is adding a “risk view” dashboard in the issue board to provide a clear picture for PMs about issues at risk.
Through user research, we realized the common theme that PMs are having difficulties getting a clear picture of overall progress.
Part 1: Understand & explore
USER RESEARCH
How do they use the issue board?
What are their current pain points?
INTERVIEW & INSIGHTS
Since the scope is broad, we decided to first understand the product and then conduct user interviews to understand their habits and pain points. During the time, the NDA between the team and GitLab hasn’t been approved, thus, we did guerrilla recruiting in various social media platforms. We conducted user recruitment through the following social media platforms: LinkedIn, Reddit, and Discord. We also created outreach templates for colleagues and Gitlab’s community newsletter as additional recruiting sources. Beyond utilizing warm contacts such as our LinkedIn networks, we also cold messaged 60 Reddit users. Research was conducted regarding how to optimize response rate by crafting each template’s content and tone.
We completed affinity mapping with the insights from 6 interviews; however, we were not able to get an accurate understanding.
The participants we found through guerrilla recruiting all have different roles including engineering manager, product manager, developer, tech lead. They all use the board differently; therefore, it was difficult for us to come to a conclusion or a direction based on these findings.
Part 2: Narrow down the scope
PERSONA
By narrowing our focus to product managers, we aimed to gain a deeper and more comprehensive understanding of their unique needs, pain points, and goals.
JOURNEY MAP
We identified “how might we…”s for each stage to discover potential opportunities in design.
We decided to focus on the most impactful persona, product managers, whose goals and expectations aligned directly with GitLab’s Jobs To Be Done (JTBD)
Past usability benchmarking demonstrated that task “view current status of work” has System Usability Scale sore of 77.
This score is significantly lower than other task ratings. Some key pain points were:
the current board lacks an easy, at-glance view of status
user did not notice summary metrics
users had to manually tally up issues and do mental math to summarize status
On top of this finding, we considered all of the functional PM JTBDs and focused on the following 4:
increase transparency of status for any party
increase visibility of blocked or stagnant tasks
decrease effort it takes to share or report on progress or status
decrease time it takes to spot and address any impediments
DEFINING NEW SCOPE
USER INTERVIEW
To understand how users identify at-risk issues and their pain points, we interviewed 7 PMs.
Even though all of the PMs have different ways of organizing their boards, we were able to discover common themes such as:
cluttered UI: labels are repetitive and disorganized
difficulty to track project status when team members don’t update their progress on boards
manual repetition in creating tasks
…
Among those themes, we discovered 2 major pain paints.
MAJOR PAIN POINTS
It’s hard for users to understand the current progress right away
The current layout does not provide a clear picture for PMs, thus they have to gather information from different places
The UI is overwhelming due to clusters of labels
The board contains too much information, which is difficult to navigate and find the useful information right away.
2.
There’s no jeopardy indicators
Health status, merge requests, and comments are important information PMs look for to track progress; however, they are difficult to discover.
PMs need to navigate to different pages and sections to seek for these information.
NEW PROBLEM STATEMENT
“As a product manager, it is difficult for me to understand current status of issues rights away on Issue Boards.”
For our next step in design, we will focus on:
JTBD
How can we make the new design align with PM’s goals and tasks?
Flexibility & Customization
How might the new design support different workflows and habits?
Crucial data
What information and data do PMs seek for to identify at-risk issues?
Part 3: Ideation
We brainstormed various potential solutions to improve the display of issue status and three stood out:
1 . Dashboard / Banner
display key information about at-risk issues
3. Timeline view
shows the progress of issues
These all have high integration feasibility with current issue boards. The team decided to proceed with “1. Dashboard / Banner” because this option can offer high flexibility and customization with different workflows.
2. Visual indicators
includes key information and highlights issues that need attention
BRAINSTORM
DRAFTS OF VARIATIONS
We came up with more variations in top banner and dashboards. One stood out…
Top Banners:
Sprint progress overlay
Dropdown top banner
Alert banner with stat cards
Dashboards:
Center pop-up
Full page
Side panel
Top Banners stood out because it stays in context, provides at-a-glance view, and utilizes existing metadata.
Spatial efficiency
Top banner allows the user to view and interact with their issue board because it does not open up a new page or block parts of the board.
Since people tend to scan from top to bottom, top placement banner allows users to have a quick glance at key information they need.
Quick overview
Technical feasibility
Utilizing existing metadata that is already available on GitLab issue boards (overdue, no assignee …) provides familiarity for users and developers.
CONCEPT TESTING
We tested two design concepts with 5 participants to determine which design better addresses the problem statement.
Concept 1: Top Banner + Filter
Top red banner shows the number of issues in jeopardy.
Clicking on “show me” displays a filtered board that only displays issues at risk.
Yellow banner under each issue card shows why the issue may be at risk.
The user can turn off the filter by clicking on “x”
Concept 2: Top Banner Risk View + Cards
top blue banner shows the number of issues at risk but also information cards of the specific reasons (overdue, blocked, unassigned, not on track, and no recent updates)
clicking on an information card will filter the board with issues in that category.
Yellow banner under each issue card shows why the issue may be at risk and includes an action button (edit due date, add assignee…) to help managers quickly resolve these issues.
KEY FINDINGS
5/5 participants preferred Concept 2
Cards allow users to quickly glance at how many, what, and why issues are at risk
The action button associated with the at risk issues allow users to take actions easily
However, based on the feedback, there are still aspects we need to re-consider. For example:
Action button - necessary or not?
Some users did not think the action buttons are useful because they need more information and decision making to make these changes.
Level of customization & configuration
Some users liked the idea of configuration and changing scopes for each information card. Some users said a few information cards are not that useful to them.
Poor discoverability of toggle
Most users did not notice the risk view toggle in the beginning.
Risk view with context or not?
Some users said it will be helpful to see at risk issues with all the other issues to understand the big picture and assign people accordingly.
DESIGN CHANGES
1: Popover to increase the discoverability of Risk View toggle
2: Display all issues to see at risk issues and other issues together
Some users indicated that it will be helpful to view all issues together with the at-risk issues. This helps them to understand the context better and allocate the at-risk issues accordingly.
3: Remove action buttons & change banner color
“Assigning assignees” is not PM’s job for some users. Moreover, some of them need more information and discussion before making a decision. Instead of including an action button, some users indicated a colored indication of severity would be great.
4: Configuration as side panel
Side panel gives the user the view of the board while customizing the risk conditions to provide more context and clarity.
USABILITY TESTING
RESULT
We asked 5 participants to complete 2 tasks. All of them felt confident in completing the tasks 🎉
We tested our new design with participants who do not work at GitLab but use GitLab issue boards. We asked participants to complete 2 tasks. After each task we asked them to rate their experience and confidence on a Likert Scale of 1-5.
Here is the flow of the tasks:
The result is promising, nevertheless, we still found further improvements in the design based on participants’ feedback.
Do look at metadata but not all
Depending on their own preference, habits, and team culture, PMs pay attention to different metadata.
Accessibility concerns
The gear icon buttons are currently inside clickable cards. Button inside a button is an anti-accessibility pattern.
Appreciate customization
PMs like that they can edit scopes and cards based on their own preferences.
Ambiguous definition
Some participants do not know the exact meaning of “no activity” or “not on track” because these phrases are context dependent. Some participants also find “no activity” irrelevant to them.
DESIGN CHANGES
1: Make gear icon button (configuration) universal
To avoid nested buttons (anti-accessibility)
The red and blue banners contributed to the overwhelming UI. Red also gives users anxiety. We decided on a grey banner for issues in risk view. Vertical red strip is added when users are viewing all issues and at-risk issues together.
2: Change issue board banner colors
3: Make configuration criteria for “no activity” more flexible.
We included more specific criteria such as “no comments” or “no merge request” since “no activity” card is context dependent. Users can also change logic connectors.
FINAL DESIGN
KEY FEATURES
1: Congregate important information
The Risk View filters out irrelevant issues and only display issues that require attention to the users. Users no longer need to manually scroll through every issue or apply several tags in the search bar. With banners indicating why each issue is at risk, users can easily identify at-risk issues.
2: Flexibility and control
Users can configure each card depending on their own preferences by clicking on the gear icon. Moreover, there are tooltips explaining the meaning of cards when users hover.
3: Less UI clutter
The dashboard and the banners in each issue card are grey with bold headings. This allows better visual hierarchy and creates a focused view without disturbance from colors.
FUTURE DIRECTIONS
If we have more time, we would…
Test final design
learn more about how users perceive the risk view and discover more use cases
fine tune customization for more board setups
Determine feasibility and scope
If we were to take this project further, it would be good to work with Plan Team PMs and developers to flesh out feasibility and scope
AI integration
incorporate AI to provide more personalized summaries and recommendations (eg. suggestion for configuration)
reduce repetition and manual work