2017–2021 · GitHub Coding
How GitHub made complex systems intuitive.
GitHub deployed Califa across repositories, pull requests, and Codespaces for four years. Git stayed exactly as complicated as it was. Working with it on GitHub got easier and faster.
- 4 yrs
- leading design across repositories, pull requests, and Codespaces
- 1 wk
- to specify and complete the Code button before its announcement
- 1.5 yrs
- from Suggested Changes to the first multi-line comment release
Every team uses pull requests differently.
Teams bring their own CI, branching, review culture, permissions, and merge gates. GitHub had to support all of it and still have an opinion about quality, speed, and what a developer should do next.
Califa worked from product principle to technical model to interaction detail. Depending on the problem, that produced a multi-year vision, a project that research killed before anyone built it, a new Git trailer, or a one-line arrow.
01
Product thinking
Defined pull requests around one job: integrate high-quality code. That principle gave security, CI, review, deployments, and every future feature a reason to exist in the same system.
PR vision · action items · code-at-scale strategy
02
Research
Tested the premise before polishing the request. WIP research disproved the original notification problem; partial-review work found a more useful need in simply tracking review progress.
WIP PRs · Draft PRs · partial reviews
03
Technical system design
Mapped branches, forks, revisions, force pushes, workspaces, permissions, and repository context until product and engineering could work from the same model.
Guest Branches · Review Points · Codespaces
04
Interaction design
Turned code review into tighter loops: propose a change inside a comment, apply it, comment across a range, and remember which files you already reviewed.
Suggested Changes · multi-line comments · file tracking
05
Microinteractions
Used the browser tab, a one-line arrow, recency color, precise labels, and small state changes to remove friction from workflows repeated millions of times.
Dynamic favicons · Git Blame · branch direction
06
Research infrastructure
Designed the machinery around research so teams could recruit a broader pool, track contact history, honor opt-outs, and learn without a researcher’s private Rolodex.
Participant system · Airtable pilot · operating docs
“Califa is without question the best strategic thinking design model I’ve tested.”
Start with what pull requests are for.
Pull requests exist to integrate high-quality code. Review, CI, security, deployments, and approvals should each make that outcome clearer or safer.
That framing turned a crowded feature surface into a product strategy. It also surfaced the same problems across years of work: developers didn’t know what needed their attention, important feedback got lost, large changes were hard to read, and the review model itself was ambiguous.
72 slides
24 minLet research change the request.
Research was allowed to make the project smaller, different, or unnecessary.
WIP PRs began with reports from two customers about premature notifications. Interviews showed that teams meant different things by “work in progress,” had already built notification habits, and did not consistently experience the stated problem. The team stopped. Soon after, Draft PRs addressed a different need: giving developers permission to share unfinished work without feeling self-conscious.
Partial reviews became Mark file as viewed.
Partial reviews tried to let specialists approve only the files they owned. The research found a more common need: helping people keep their place in a large change. Mark file as viewed shipped in July 2019, with interaction work on scrolling and perceived performance.
55 minDraw the system before drawing the screen.
Forks, force pushes, dependent changes, permissions, and review readiness are the product model. The interface sits on top of them.
Review Points modeled the rhythm, not just the status.
New pushes moved a ready pull request back into progress. An author explicitly published the next review point when the iteration was ready. Updates tracked every push, including force-push workflows, so the model could eventually support stacked diffs.
The staff ship failed: implementation drifted from the model, onboarding was missing, teams were reassigned, and the name confused people. The project was shelved.
25 min
55 slidesBuild on what developers already know.
The best interactions extended something developers already used: a Markdown comment, a line-range gesture, a commit trailer.
Suggested Changes turned feedback into code that an author could apply. The first version was a small Markdown extension. Batch and multi-line flows followed as the comment system caught up. GitLab adopted the same syntax and interaction pattern almost verbatim; the convention subsequently spread across the industry.
Sweat the change that takes one line.
At GitHub’s scale, a one-line change can remove friction from a workflow developers repeat all day.
CI state in the favicon
A hack-week project put build status in the browser tab, so developers did not have to keep reopening every pull request to see what changed.
An arrow instead of an ellipsis
Branch direction was easy to misread. A close-to-one-line change made the merge relationship explicit without introducing another explanation.
Recency that reads at a glance
Git Blame research showed that repository-relative color made old work look new. The scale was reframed around a meaningful time window.
9 min readLet developers choose where code opens.
Codespaces required more than designing a button. Califa worked across GitHub, VS Codespaces, and VS Code on workspace permanence, product UI, naming, pricing, and the relationship between a repository and the tools that could open it.
A week before Codespaces was announced at GitHub Satellite 2020, the Code button was specified and completed in response to a real platform concern: GitHub should not push every developer toward one paid Microsoft editor. The proposed Open with model included Desktop, Codespaces, ZIP, local editors, and custom tools. Its general structure shipped and kept evolving.
5 min
82 slidesDesign the system around the research.
Teams needed more than good questions for user interviews. They needed a responsible way to find the right developers, know who had already been contacted, and carry consent through the work.
Califa designed an inbound participant system, then led a cross-functional Airtable pilot with Legal, Procurement, Marketing, researchers, and designers. The model connected segmentation, projects, email, sessions, opt-outs, and usage history so research could scale beyond personal networks.
01
Participant
Profile, segment, consent
02
Project
Question, criteria, owner
03
Contact
Invitation, history, opt-out
04
Session
Notes, recording, finding
Privacy, procurement, participant history, and usage limits were designed into the model before the first interview.
What shipped, and what didn’t.
Launches, pivots, failed staff ships, and unbuilt visions, kept on the same record.
01
Shipped
Suggested Changes, multi-line comments, and file review tracking
Three releases shortened the loop between reading feedback, proposing code, and completing a review. Suggested Changes launched at GitHub Universe 2018, GitHub’s annual developer conference; its syntax was subsequently adopted across the industry, and multi-line suggestions followed once the underlying comment model could support them.
02
Shipped
Co-Authors, Codespaces, and the Code button
Native multi-author credit became a first-class convention, now used across the industry to share attribution with agents. Codespaces shipped after cross-company work on workspace models, UI, naming, and pricing. The Code button gave developers more than one useful destination.
03
Changed shape
WIP PRs and partial reviews
WIP research invalidated the original notification premise; the work later resurfaced as Draft PRs around a different human need. Partial approvals pivoted into the simpler, shipped Mark file as viewed behavior.
04
Held
Review Points, Guest Branches, and code at scale
These models showed real leverage and real adoption costs. Their staff-ship failures, product constraints, and unbuilt opportunities stay on the record.
The handoff was part of the design.
“Since I won’t be around to rant on Zoom, the following is a brain dump that will hopefully be valuable to you.”
The handoff document recorded principles, unresolved product problems, why specific models failed, which assumptions no longer held, and who was carrying the work forward. Four years of product judgment, in a form the next designer could use.
Ready to deploy?
Rollout takes about a coffee. He shows up and starts working.