Visual Studio - Git Tooling

Making Git usable, safe, and fast inside Visual Studio

My role

Sr. UX Designer

Company

Microsoft

Project Duration

6 months

Highlights (TL;DR)

This project rethinks core Git workflows in Visual Studio to reduce friction and increase confidence, especially for developers newer to Git. We focused on surfacing state, adding guardrails, and preserving work without slowing down power users.

Problem
Powerful but opaque Git flows created slow commits, error-prone merges, and low confidence—especially for newer Git users.

Outcome:
A clearer, guardrail-first experience that surfaces state, guides next steps, and preserves work.

Overview

We served two primary audiences—daily Git power users and devs still building Git fluency—within the constraints of legacy UI tech, performance budgets, and accessibility requirements. The scope included Branch Management, Git Graph/history, Conflict Resolution, and Commit/Changes.

Users
Power users,
onboarding devs,
students

Constraints
Legacy tech, perf budgets, localization, keyboard parity, WCAG

Scope
Branch management
Git Graph
Conflict resolution Commit/Changes

Visual Studio Ecosystem/Architecture Diagram

Research and Discovery

We combined interviews, artifact audits, and task walkthroughs to locate failure points and confidence gaps. Findings shaped the design principles and prioritized where to invest first.

Participants

  • Internal developers

  • External developers

  • Developers across experience levels

“I want to do everything without leaving the keyboard.”

“I’m never sure what state I’m in before I commit.”

“Resolving conflicts feels risky—I can’t see enough context.”

Key Insights

Developers fear data loss more than extra clicks.

  • Git state is often invisible/ambiguous at crucial moments.

  • Conflict resolution needs diff context + clear actions in one place.

  • Power users require keyboard parity and batch actions.

Design Principles

Make Git legible: persistent status and clear next steps.

Never lose work
protective patterns and undo paths.

Meet devs where they are
keyboard-first, diff-friendly.

Explain without lecturing
inline, contextual, dismissible guidance.

Ideation & Prototyping

We prototyped multiple flows per surface, tested them with developers, and converged on designs that reduced decisions while improving visibility. Below are representative changes and outcomes.

Branch Management

We redesigned the Branch Selection panel for speed and full accessibility. Partnering with a blind developer, we validated keyboard flow, roles/labels, and screen-reader announcements so it works without sight and stays quick for power users.

  • Multi-branch selection > customized graph view: choose multiple branches and the Git Graph renders only those for a focused, noise-free view (previously “all branches” or a single branch via History).

  • Pin branches: keep frequently used branches pinned to the top of the list for instant access (keyboard and screen-reader friendly).

  • Inline search to filter long branch lists.

  • Status indicators showing local/remote change state at a glance.

  • Keyboard-first + screen reader support: logical focus order, visible focus, and aria-live updates on selection.

  • One Microsoft initiative consistency with Azure DevOps and Windows OS

Branch Selection

Branch Action Menu

Git Graph View

We made branch states scannable and added quick actions from nodes to minimize context switching.

  • At-a-glance branch health, authorship, and actionable nodes.

  • Selection persists without losing reading position.

“Put as much in view as possible”

Before

Final

“I need actions that are close to where my focus is”

“It is hard to tell how my commits effect the repository”

Phase 3

Validation & Iteration

During the validation process, we held weekly meetings with the engineering team to ensure technical feasibility and gathered their feedback on Git tools. These discussions provided valuable insights, allowing us to quickly improve before the next user studies.

In our weekly user studies, we conducted A/B tests with both simple and detailed prototypes to evaluate our concepts and identify any overlooked technical issues. We added new graph features such as handling large gaps in commit displays, allowing users to choose between topological and chronological order for commits, and collapsing commits for a cleaner view.

As we received positive feedback from user studies, we worked with the UI team to ensure our new graph was accessible and aligned with Microsoft branding. Their expertise helped us enhance visual accessibility. Initially, the contrast was a challenge for colorblind users, so we added outlines to branches for better separation. We also increased the size of branch heads to make distinguishing between different branch and commit states easier. Testing with colorblind users confirmed they could navigate the updated graph without problems.

Phase 4

Implementation

Before the project officially began, I was unexpectedly moved to a different product team to offer my design support and expertise. As a result of this transition, I unfortunately couldn't continue into Phase 4, which was crucial and involved addressing various issues related to technical feasibility, time constraints, and comprehensive quality assurance.

How did we do?

When we first embarked on this ambitious project in the year 2020, the Visual Studio Git Tooling was had by approximately 80,000 users across the globe. As of today, we are pleased to report that this impressive figure has grown significantly, now exceeding an astonishing 300,000 users worldwide.

Starting at
+80K users

Increased to
+300K users