GitHub Mobile: When intuition fails against data

The "lite" trap

We often fall into the trap of thinking mobile apps should be lite versions of github.com, stripping away complexity to fit the screen.

I argued that Forking, cloning a codebase to your own account, was a github.com task. It implies you're about to write code, edit files, and engage in deep work. Since the phone isn't an IDE, and, honestly, not great for larger coding tasks, I assumed the feature wasn't worth the product cost.

The signal in the noise

The requests didn't stop, and users were working around it by opening the github.com site on mobile Safari to reach the Fork button.

When users fight your tool to do a simple task, you're usually missing something fundamental.

When we dug deeper, people weren't forking to code right away, they were forking to create a future.

Intent vs. execution

Forking on GitHub Mobile wasn't about execution, but about claiming a project, a way to say, "I want to work on this later."

By blocking the feature, we were blocking their momentum. We were forcing them to remember the idea until they got to a laptop, or to star the repository and find it again later. Ideas often die in that gap.

Changing direction once the signal was clear

We shipped an intentionally plain version of the standard flow, adapted for touch and simplified where mobile needed it.

Adoption was immediate enough that users would find a repo away from their desk, fork it, and come back later when they were ready to work.

The pattern showed up clearly in the metrics. Most forks created on mobile didn't get a single push for hours or days, which made the use case clearer: claim now, work later.

What we learned

Forking a repo had become more than a niche feature. A lot of people used it, and still use it, to start working when they only had their phones, or to keep a copy of a project they liked when starring didn't feel like the right action.

The feature became less about doing the work on a phone, and more about capturing an idea the moment it happened.

Self-check

The self-check was my own bias, not Forking.

As designers, we often over-rationalize constraints. We say "mobile is for consumption" or "github.com is for creation". But users don't care about our categories.

They want to capture the idea before it fades. Product surfaces shouldn't be limited by our assumptions about which device is supposed to do which job.