Adding a feature to GitLab that provides a user-friendly report of time tracking.
I played the role of UX/UI designer and UX researcher to design this feature on GitLab. The timeline of the project spanned 4 weeks.
This project was selected based on my goal to contribute to open-source design. I found an issue on GitLab pertaining to time tracking that I wanted to focus on.
GitLab currently allows users to export a report of their issues, which includes the amount of spent and estimated time for each issue. But there is no method on the interface to view or filter categories for the report.
Design a report within the interface that users can view their time tracking report. The report should allow users to filter and group information relevant to the issues of a project. Users should be able to export this report from the interface as well.
Initial research consisted of secondary and primary research methods.
The research findings provided many insights, including the fact that teams want methods to streamline work processes. These insights were compiled to create the primary persona that will guide the next design steps.
Users seek a way to reduce additional steps in their workflow to track and report time.
A tree test was used to determine where time tracking would be on the GitLab interface. The existing GitLab navigation items were used to set up the tree test. The goal of the tree test was to use this existing taxonomy, instead of creating a new one.
Optimal Workshop was used to send out remote tests to 10 participants, with 1 participant abandoning the test. Due to resource constraints, more participants were not able to be recruited.
Based on the tree test findings, nesting the time tracking within Project Information made the most sense. The goal of the primary persona is to export time reports spent on specific projects during a specific date range. This decision aligns with the goals and needs of the primary persona.
The sketches explored ways users would interact with the filters and the visual hierarchy of the report data. There was a question of whether users should view their report in a calendar view or in a report summary format. These sketches led to the choice of using a calendar view, as it is more natural to navigate. For more detail, view the annotated sketches.
The full user flow of the prototype started from the group page to the time report that is nested within the project information. The prototype was prepared to test the changing of the date range.
The first version of the prototype underwent usability testing with remote, moderated interviews. A total of 3 participants were recruited to conduct the usability test. The objective of the test was to gather success rates of navigating to the report, changing date ranges, applying a filter, and exporting the report. Likert scales were also used to follow-up each task in order to rate the experiences.
The highlighted item is the dropdown that enables users to group the report by Assignee or Issues.
After gathering the usability test findings, an affinity diagram helped to prioritize the next steps based on available resources. Many of the patterns that needed improvement identified would require additional resources for research, as a result, were prioritized for later.
The immediate priority revisions are to improve the date picker and to label the dropdown menu that enables users to group the report.
Below are the before and after prototype of the project. To access the revised prototype, click here.
To reduce clutter, users view themselves as the assignee. This would be applied to the filter field. Users can edit the filter to add more assignees. Instead of just seeing the current week, users see the current and past week.
Users interact with the date range field in order to trigger a dropdown for date options. Since the report will show just the user as an assignee, there will be a filter applied by default to reflect this. The Group by dropdown has been relabeled to reflect the action, instead of the selection.
Consolidating the date options into a dropdown was a decision made from usability test insights and research calendar picker design patterns.
The challenging part of this project was empathizing with the various roles that time tracking would be designed for. Without the ideal resources to perform necessary research, I was left anticipating the needs of other users. I needed to learn to step back and utilize the research I did complete. Iteration and incremental improvements in the future is key to reaching a good product.