Hello there! You've reached the portfolio-ish site of Ben Leduc-Mills. I like making, in many forms -- through music, woodworking, lasers, electronics, code, Lego, 3d printing, e-textiles, you name it. This website captures some of my career from interaction design, rapid prototyping & digital fabrication, open source hardware, software engineering, user research, and of course, AI.
Yes, I use AI everyday. For code, for design, and for research. No, I didn't use it for this website.
Workarounds: Uncovering the Invisible Ways Users Avoid your Product
A two-quarter study uncovering over 230 different ways that GitLab’s own users, and its own team members, quietly route around the product instead of using it, and what that says about where the user experience falls short.
Context & Contributions
After being at GitLab for a while, I kept noticing a similar pattern: someone at GitLab, or a customer, had built their own small tool, script, or bookmark folder to do something GitLab was already supposed to do. Enough of these turned up that I started wondering why (since I think like a researcher), then wondering why turned into a proposal, and the proposal turned into a self-initiated study.
A workaround, for the purposes of this study: a plan or method to circumvent a problem, without fully solving the problem itself. The example I opened with: I save every email I get from GitLab in Gmail, and use Gmail’s search to find the issue or merge request I actually want, because I can’t ever find it through the GitLab UI itself. Multiply that instinct by a couple hundred people and you get a real dataset.
PROJECT DETAILS
ROLE: SELF-INITIATED, SOLE RESEARCHER
PROJECT TYPE: EXPLORATORY / DESK RESEARCH STUDY
DURATION: TWO QUARTERS, FY25 (MAY 2024 – JAN 2025)Problem
A workaround is a product failure that never gets logged as one. Nobody files a bug report titled “I built my own tool because yours doesn’t work.” They just quietly stop using the feature and go build or find something else, and that failure disappears from view. Which means product and design were almost certainly missing an entire category of signal about where GitLab actually breaks down.
Hypothesis
A workaround represents an unmet need. If someone took the time to build or find their own separate solution for something GitLab is supposed to do, that’s evidence of a real degree of severity, or frustration, with the current solution. Collect enough of them, and you have a pre-validated list of pain points, sourced from people who cared enough to actually solve their own problem.
Methods & Process
Collecting
I gathered workarounds through an internal survey, direct interviews with team members, and a fair amount of desk research: mining GitLab issues, Slack, an internal tools repository, browser extension stores, and a GitHub search (filtered down to repos with at least 1,000 stars, 5 forks, and activity in the past year, since GitHub alone returns over 54,000 results for “GitLab”). I stopped actively looking once I’d collected around 230. After removing duplicates, I ended up with 214.
Categorizing
I sorted every workaround two ways: by the product area it touched, and by what form it actually took. Task management (locating, organizing, and prioritizing work items) was the single biggest category at 29, ahead of integrations and API interaction, monitoring, and security and compliance, several of which leaned heavily on things that could just be automated. By format, the majority, 87 of 214, were command-line tools, followed by browser plugins and web apps, which tells you something about who’s motivated enough to build a workaround in the first place: a technical audience willing to skip the GUI entirely to get what they need.
Mapped against the SDLC, they weren’t clustered in one weak spot, they were everywhere: GitDock and bookmarking tools for navigation, Reviewer Roulette and a GitLab utility bot in Create, fast-stats and inline pipeline failure screenshots in Verify, Terraform-based config management in Plan, access token audits and vulnerability automations in Secure, sequenced-approval workarounds in Release, and triage automation and adoption dashboards in Monitor.
Synthesizing
Rather than write up 230 individual findings, I reduced the whole set down to three cross-cutting themes: Usability, Automation, and Sharing is Caring.
Findings & Results
Three factors accounted for most of the workarounds: personalization (GitLab failing to surface what’s relevant to a specific user at the moment they need it), customization (functionality that flatly doesn’t exist yet), and simplicity (tasks that are harder than they need to be when a more direct solution exists).
The usability theme carried the clearest verbatim evidence. People built their own navigation because GitLab’s is project- and group-centric rather than user-centric: “What I’m going to do instead is have a folder full of GitLab bookmarks that are gonna help me navigate to the things I care most about.” One quote put the underlying complaint about as bluntly as it can be put: “At the core, it’s really overcoming the problem that basically all of the navigation in GitLab is project or group centric… It tries to be user-centric, it tries to show information that is important to you. It tries to really act as like the center of what you care about.” Missing shortcuts came up too: “the most annoying missing feature of GitLab is to not have keyboard shortcuts on boards. Like how would you move the 153rd item from this list to the top?” And so did search: at least four people we know of resort to Gmail or plain web search before GitLab’s own search, because it’s faster and more accurate, and in some cases the UI doesn’t even expose the filters that would make GitLab’s search useful in the first place.
The automation theme had a similar shape, just aimed at repetitive work instead of navigation: auto-created merge requests to keep branches in sync, auto-generated issues from vulnerability scans, automated compliance framework checks. One engineer’s description of the alternative stuck with me: “the use of compute to do this very simple task is heinous. Every single comment on an issue on that project fires up an entire CI/CD pipeline, runs a script, and then either it makes a comment or doesn’t. This is like such a silly use of compute, right? But it’s the only way we can automate it.”
The third theme, Sharing is Caring, was the one I didn’t fully expect going in: 63% of the 214 workarounds, well over half, were built by GitLab’s own team members, not customers. We’re already sitting on a lot of the solutions our own customers would want, we just haven’t shipped them. One director, showing me a tool, said it outright: “I feel like this is cheating because this isn’t in our product yet.” A senior manager went further, and this is the line that’s stuck with me since: “I don’t think they [internal workarounds] should exist. It is a missed opportunity for us to feel the pain that our users are feeling. Having this in place instead of forcing us to try out our own actual product solution makes us blind to these problems. We should build the correct solution for this into our product.”
I closed the report with three proposals, each mapped against GitLab’s own product pillars: get personal (bring personally relevant work front and center across the SDLC, building on things like the merge request homepage and reworked notifications already in flight), enable customization (let teams build native automations instead of reaching for a third-party tool), and productize our internal tooling (ship what we’ve already built for ourselves, since we’re the ones who felt the pain, and there’s a real monetization angle in doing so). The concrete recommendation underneath all three: a native way to chain and automate actions inside GitLab, which several existing but under-resourced efforts (AutoFlow, an events platform, CI events) were already circling without the backing to finish. My ask was to fund that backbone and stand up a working group once it existed. For the parts that don’t need a whole platform, I broke out a smaller set of workarounds specific enough that a single Staff+ engineer’s “paper cut” allowance, or a hackathon, could realistically knock out.
The whole point of a workaround is that it’s a visible, tangible artifact of how someone actually wanted the product to work. GitLab had 214 of them lying around, we just hadn’t been collecting them.
