Every single Graphite user passes through the PR page. But over time, we realized that one of our most important surfaces was also one of our most cluttered. “Customers were coming to the PR page and it was too overwhelming,” recalls lead designer Cameron Collis. The experience worked, but it lacked the clarity and focus we pride ourselves on. So, we decided to rebuild it from the ground up.
Since most of our users are familiar with GitHub’s PR page, we wanted to create something that felt instantly recognizable, yet distinctly Graphite. “The main goal was a tidier visual experience. We wanted to reduce visual clutter, noise, redundant labels, and any unnecessary decorative elements,” Cameron adds.
So, we set out on tightening what worked, simplifying what didn’t, and making the page feel faster, clearer, and more aligned with how developers actually review code. In this post, we’ll explore some of the design thinking that went into one of our largest iterations of the PR page to date.
Our design thinking
Beyond the visual overhaul, the original brief for the redesign included a few hard feature requirements—most notably floating comments and a rich text editor. These weren’t last-minute additions or experiments, they’d been on our minds for years. The PR page redesign finally gave us the space to build them the right way.
Eli Howey, one of the lead software engineers on the project, recalls how those constraints opened creative possibilities rather than limiting them. “That was a nice way to start the project,” he said. “It gave us more room to explore different ideas. It made us really focus on a new vision instead of being tied to some of the previous decisions.”
Newfound accessibility with a rich text editor
The decision to add rich text editing came from a simple observation: not everyone reviewing code is fluent in markdown. On GitHub, most text inputs, like comments and PR descriptions, are plain markdown fields. While that’s familiar to many engineers, it can be alienating to others. Designers, PMs, and less-technical collaborators often contribute to reviews, too, and syntax formatting shouldn’t be a barrier to participation.
By introducing a rich text editor, we’re making PR discussions feel more natural and inclusive. You can now format text, add emphasis, and structure your thoughts visually, without needing to remember markdown syntax. It’s a small detail that makes Graphite feel more human.
Keeping focus with floating comments
Floating comments, on the other hand, were a direct response to years of user feedback. “Reviewers tend to read files line by line, top to bottom. But when a long comment thread breaks up the diff view, it disrupts them. They lose their place or scroll up and down trying to reorient themselves,” Eli explains. Over time, that friction adds up.
Floating comments solve that problem elegantly. Instead of embedding long threads directly in the diff, comments now hover contextually beside the relevant code. They stay accessible without obstructing your view to keep you immersed in the review itself.
This was one of those changes that sounds simple but required deep rethinking of how the PR page was structured. It forced us to reimagine not just how comments look, but how they behave, for example, how they appear, anchor, and disappear as you read.
Challenges: Rethinking the stack
The stack—the sequence of PRs linked together—is a core part of the Graphite experience. It gives you context, helps you navigate related changes, and makes merging smoother. But figuring out where it should live on the redesigned page was surprisingly difficult.
Cameron recalls, “The stack is an interesting one. A lot of people felt like the natural place for it was in the middle of the page, since that’s where the actual PR content lives.” Others argued for a sidebar approach. “It felt intuitive,” Eli explains, “because moving through a stack is a bit like browsing, going back and forth between related things.”
So we tried it. We moved the stack to the left sidebar. And it didn’t work. Once we built it, we realized just how dense the information inside each PR card really was. Each item had to display multiple details: PR titles (often long ones), status indicators, comment counts, lines changed, and more. In the narrow sidebar, that content felt cramped. The visual hierarchy broke down, and the scrollable column introduced its own usability issues.
“The information and content that’s in the stack is really hard to work in,” Cameron says. “It just takes up too much space in a narrow sidebar.” And beyond layout, there was also a conceptual mismatch. Some stacks have multiple PRs; others have just one. For those simpler cases, dedicating an entire sidebar to the stack felt unnecessary.
Ultimately, we found that the horizontal layout we’d previously used was still the most flexible and readable way to represent stacks. It allowed for more breathing room, better scanning, and clearer visual relationships between PRs. So, in the end, the stack stayed where it belonged: anchored within the flow of the PR itself, not off to the side. It’s a small but important example of how we balanced ambition with pragmatism when evolving Graphite’s core experiences.
Building through iteration
We approached the redesign the same way we approach everything at Graphite: Through constant iteration and dogfooding. Every internal rollout became a mini stress test. We’d catch small visual issues or interaction bugs, adjust, and push again. We do this to ensure that users get the best version of Graphite by the time we roll out a new launch.
Those dozens of refinements compounded into a page that feels smoother, sturdier, and more intuitive with every click. The PR page is where developers spend most of their time in Graphite, and it deserves to feel effortless. As we continue testing, dogfooding, and refining, our goal remains simple: to make Graphite the fastest, most intuitive way to move code forward. “This redesign was all about bringing the code back into center focus,” Eli says. “And I think we’ve come up with something that does exactly that for users.”
