Side Quests

Overview

Not every piece of work fits neatly into a project arc. Some of the most meaningful contributions are the ones you take on because nobody else did, because you noticed a gap and had the skill to close it, or because a small fix touches more users than a large feature ever will.

This is a collection of that kind of work. Individually each piece is modest. Together they say something about how I think about ownership, quality, and initiative.

Command palette quick actions

Power users at GitLab live at the keyboard. The command palette gives them a fast path to navigate the product without reaching for a mouse, but quick actions, the shortcuts that let you assign, label, or close a merge request in seconds, lived somewhere else entirely.

I built a proof of concept to bring MR quick actions into the command palette. Not a spec, not a proposal. A working implementation I authored and submitted as a merge request.

The POC demonstrated the interaction model: open the palette with Command+K, see contextually relevant quick actions for whatever you are looking at, execute without leaving the keyboard. The goal was to validate the concept with something real that engineers could react to rather than a mockup they had to imagine.

Building it myself compressed the feedback loop entirely. A merge request forces the hand of reviewers in a way that a design file does not. It is either right or it needs changes, and either outcome moves things forward.

iOS input zoom fix

Every form input on GitLab's mobile interface had a bug that had probably been there for years. iOS Safari and Chrome automatically zoom the page when a user focuses on an input field with a font size below 16px. The intention is accessibility, preventing text from being too small to read. The effect in GitLab was an unexpected page zoom that disrupted the experience every time a user tapped a form field on a phone.

The fix was straightforward once identified: set input font size to 1rem on mobile. One CSS change, two files, affecting every mobile user of every form in the product.

This is the kind of bug that is easy to walk past. It requires noticing, it requires caring enough to investigate the cause, and it requires submitting the fix rather than filing a ticket and hoping someone else picks it up. I noticed, investigated, and submitted.

Scaling UX coverage through automation

In 2021, community contributors submitting merge requests with UI changes had no reliable path to getting a UX review. The Danger bot, which assigns reviewers automatically based on what a merge request touches, did not include product designers in its rotation.

I added the product design team to the Danger bot reviewer roulette for merge requests labeled as community UX contributions. When a community member submits a change that affects the interface, a designer is now automatically suggested as a reviewer.

The result was scaling UX coverage without scaling headcount. Every qualifying community contribution gets a design eye on it. The system does the coordination work that would otherwise fall through the cracks.

Proactive ownership

Caring about the experiences every user touches means stepping into work that is not yours by any org chart definition.

When GitLab Duo launched in the Premium tier, the onboarding path for new customers was not set up to make GitLab Duo feel like a natural first step. I ran a one-week compressed design sprint to improve Learn GitLab as a workflow entry point for GitLab Duo, fitting it between my other commitments at the time.

The search and command palette experience had accumulated small inconsistencies across multiple milestones. Placeholder text that did not match context, keyboard interactions that were slightly off, filter behavior that was unpredictable. I refined these across several milestones without assignment or direction, because they were the kind of thing that erodes trust in the product quietly and compounds over time.

On shipping code

In FY26 I merged 64 code changes across GitLab's repositories including the core product, duo-ui, and Pajamas. That number will keep growing.

The instinct behind it is straightforward. When I can see that my effort will have an outsized impact and no one else has capacity to act on it, I act on it. A merge request moves faster than a ticket. It creates a concrete thing for engineers to react to. And it closes the gap between what I can see needs to happen and what actually gets done.

AI has made this significantly more accessible. What used to require a deep context switch and significant ramp-up time now happens as a natural extension of the design work. The bottleneck in getting design ideas into production is shifting. I intend to keep pushing on that.