Personalized Homepage

Overview

When you visit gitlab.com, the first thing you see matters. For years that first thing was a generic dashboard that did not know who you were or what you were working on. The Personalized Homepage changed that by consolidating to-do items, assigned issues, merge requests, review requests, and recently viewed content into one landing page tailored to each user.

The project went through a diary study before launch. Participants found the prototype so useful that some continued using it after the study ended. It rolled out to GitLab team members in 18.4 and to customers on GitLab.com in 18.5.

This one came to me in stages. I started as a coach, became a co-owner, and eventually took it all the way.

How I got here

When I came back from paternity leave, another designer was already doing great work on the homepage. I was happy to jump in and help. I coached her through the design iterations and we worked together toward a successful launch over the summer. She did strong work, and the initial rollout reflected that.

When she moved on from GitLab, I picked up where we left off. The transition was smooth because I already knew the project inside and out from our collaboration.

Running two projects

For several months I ran homepage iteration in parallel with Project Studio. Project Studio was a 12-week sprint across 10 workstreams. The homepage needed steady attention but not the same intensity. I prioritized the most impactful feedback items from the community, shipped what I could between Project Studio commitments, and kept both efforts moving.

It was a lot, but both projects made each other better. Both benefited from the same skills: reading user feedback carefully, identifying the highest-leverage fix, and shipping it as a merge request rather than a ticket.

Cranking it up

After Project Studio shipped, I shifted my full focus to the homepage. The feedback issue had been filling up with great ideas from the community and I finally had the space to dig in.

Over the following months I shipped a steady stream of improvements. The Quick Access widget gave users a Projects tab with their most important repositories. Activity filters let users scope their feed to what mattered. I fixed the greeting header to use full names and truncate properly on small screens. Project source filtering and configurable project limits gave power users the control they had been asking for.

Every change traced back to something a real person asked for. Read the feedback, find the smallest fix that makes a difference, ship it, repeat.

Results

The community response was overwhelmingly positive. The feedback issue became less a list of complaints and more a collaborative roadmap. Users were not asking to revert. They were asking for more: project access, GitLab Duo integration, customization options.

That is the best signal a product can send. When users stop asking you to fix what is broken and start asking you to extend what is working, the foundation is right.