Combined with the version control and the code collaboration features, Gitlab CI/CD provides a best in class solution for continuous integration and deployment in software development. Pipeline index is the landing page for GitLab CI/CD users. The page gets the second highest traffic(~500k per month) in the application and is situated at the centre of all the
primary jobs to be done associated with CI/CD activities in GitLab.
In the course of over a year, I worked with my team to conduct researches and develop strategies to help the GitLab CI/CD users `monitor their pipelines` and `debug their pipelines` faster, without disruption. The proposals generated included enhancing filtering options, improving identifiers, making changes to button layouts, etc..This is some text inside of a div block. We suddenly encountered an oddly challenging situation when we started to record that a of bunch of changes we shipped with positive intention to improve the usability of the page started to negatively impact its performance.
Screenshot of the pipeline index page from 10 releases ago(2022 May)👇

The challenge(s)
Over the time many changes were made to this page based on thoroughly validated problems supported by actionable insights, with an intention to improve the overall usability. However, the layout began to give in to the performance stress and started to break. This in return caused disruption for some of the most commonly executed workflows in the product.
The two challenges we were looking at were:
1. Ensuring stability of the page in the short term.
2. Working on our long term plan to lay down guidelines to avoid one such situation in the future not just for ourselves, but for the other teams as well.
Action plan
For the first challenge, we immediately started an
async discussion issue to understand what should be our immediate next step to make the page stable. Post discussion, we agreed that `creating more space` will help achieve a band-aid solution and will help us afford sometime to think of a systemic and sustainable solution to the problem. We went ahead to immediately
rearrange the table layout with minimal impact to the content and leaned on findings from the old researches to make informed decisions. Most changes from this effort were still behind a feature flag. Only the absolutely necessary ones were rolled out to all SaaS(GitLab.com).

For the second challenge, we kicked off :
1. A solution validation research to collectively present all the recent changes (that individually made sense) together with the new rearrangement to our users, and generate new insights that we could work with.
2. A discussion on what changes we should make to our table component or the general responsive layout guidelines so other group can learn from our case. I created
an issue to loop into the conversation other designers who dealt with a similar tabular layout within GitLab UX team.
3.
Set up tracking for individual actions on the page so we get to look at the usage data to understand what should stay on the page and what should go.
The discussion eventually led to me working with the foundations team to add
`Responsive first` section in our design system guidelines. This is some text inside of a div block.
This is how the final version(that can be seen on the product today) turned out. 👇

Principles and insights
We received quality responses from the solution validation research and were soon able to form actionable insights for further improvements to the layout before taking away the feature flag.
Triggerer of the pipeline should be prominently visible.
Combine pipeline names with unique identifiers.
Users come to the index page to compare pipeline performance.
Design for scannability, since the number of pipelines in the list can be a lot.
Performance issues
All the efforts apart, we continued to experience some minor performance issues with the page and eventually designed a team ritual around looking at the latest data in Lighthouse(tool) and observing patterns to understand the next best action we need to take. The epic outlining the process can be found
here.
Further UI Improvements
Being a highly used area in the product, there have always been very pressing priority items to look at in every milestone in the CI/CD team. This made it very challenging to reserve capacity to only work on visual design and improvements. This led me to volunteer for `Beautifying our UI` effort with a frontend engineer to work on the UI related improvements that we've not been able to get to due to conflicting priorities.
Beautifying our UI 16.1 issue. This is some text inside of a div block. here is a glimpse of how the table would look after the upcoming release(16.1). next up is fixing the link stylings based on the new
guidelines for meta links that I worked on with the foundations team again.
