GitHub UX Teardown: Search to Source File in Five Screens

This capture starts on github.com with nobody signed in and ends five screens later inside a single TypeScript file. The route is the one a developer takes to read someone else's code: open search, type the repository name, pick the result, open src, open client.ts. The repository is openai/openai-node, the official JavaScript and TypeScript library for the OpenAI API, chosen because it is public, busy and readable without an account.

It was recorded on 7 September 2026 in a 1440×900 browser window, in US English.

Search, with the exact name typed in

Search lives in the header of the marketing homepage. Opening it dims the page behind and puts one field in a white panel at the top right, with the query openai/openai-node typed in and a clear button at its end. In the captured frame the panel offers a single line under the query, Search syntax tips, and no shortcut to the repository itself.

Submitting the query opens a full results page. It reports 4.8k results (150 ms) for a query that names one repository by owner and name. The left rail picks the type: Repositories 4.8k is selected, with counts beside the others: Issues 79.4k, Pull requests 382k, Discussions 3.2k, Users 0. Below that sit language filters and an Advanced group (Owner, Size, Number of followers).

The official repository is the first card. It shows the description, three topic pills, TypeScript, 11.2k stars and Updated 2 minutes ago. The next result is openai/openai-quickstart-node with 2.6k stars, then a string of third-party projects whose names happen to contain "openai" and "node".

The exact match is on top. The query is no longer in view. The header field has gone back to a grey Search placeholder with a / key badge, and the only trace of what was typed is the bold on "openai" and "node" inside the result names. A tip in the right column fills the gap: Press the / key to activate the search input again and adjust your query. Above that tip, the right column holds a Node.js topic card and a sponsorship promo.

Three latest-commit rows

The repository page opens on the Code tab. Under the branch picker (main, 137 branches, 377 tags) the first row of the file table is the most recent commit on main: author, message fix(test): reject HTTP errors in mock health checks (#2667), a short hash, 27 minutes ago, and a link to 2,322 Commits. Between the message and the hash is a small red ✕, GitHub's mark for a commit whose checks failed.

Every folder row below repeats the idea at smaller scale, with the last commit message that touched it and a relative date: examples 27 minutes ago, src 18 hours ago, .devcontainer last month. The right column adds the rest: the npm link, topics, license, 11.2k stars, 158 watching, 1.6k forks, Releases 369 with v7.10.0 marked Latest four days earlier, and Contributors 111.

Opening src gives the folder its own latest-commit row: fix(zod): retain the original tool parameter schema (#2662), 18 hours ago, with a green ✓. Opening client.ts gives the file one more: feat(api): add gpt-6-astra and related features (#2582), four days ago, also green.

The red ✕ is the first status a visitor sees, and it sits on a commit that, from its message, changed test code rather than the library. The row doesn't say it covers one commit on one branch. The green ones are one and two clicks further down.

The src folder, listed twice

Opening src changes the layout. A Files panel appears on the left with its own branch picker, a Go to file field and the whole repository as a tree, with src expanded and highlighted. The main column shows the breadcrumb openai-node / src / with a copy-path button, then the same folder as a table with Name, Last commit message and Last commit date columns and a .. row for going up.

The tree and the table list the same children: _vendor, auth, beta/realtime, core, helpers and so on down to the .ts files. beta/realtime is one row in both, which suggests a beta folder whose only child is realtime, collapsed so the reader doesn't click through an empty level.

The tree is for moving sideways, since any other folder is one click away without going back up. The table is for reading what changed. In this repository the table reads like a changelog because the maintainers write conventional commits with PR numbers (fix(auth):, feat(api):, chore:), and each linked number opens the change.

client.ts

The file view keeps the tree on the left, now scrolled so client.ts is highlighted, and brings back the repository header with the Code tab selected. Above the code are the breadcrumb, the file's latest-commit row and a toolbar: a Code / Blame switch, 2347 lines (2151 loc) · 87.7 KB, then Raw, copy, download, a pencil for editing, and a toggle for a side panel.

Line 1 of the file reads: // File generated from our OpenAPI spec by Castiron. See CONTRIBUTING.md for details.

The pencil sits about forty pixels above that line. It belongs to the standard file toolbar, and nothing in that toolbar reflects that this file is regenerated from a spec. The warning is left to the file's own first line, which is where this project put it. A visitor who clicks the pencil before reading line 1 would be editing code the next regeneration overwrites.

What this means for your product

If a status is scoped to a level of a hierarchy, label the scope where the status appears. GitHub's red ✕ describes one commit on one branch, and on a repository page it is easy to read it as a verdict on the whole project.

Keep the query visible on the results page. GitHub puts a tip about the / key in the right column where the search text could have stayed in the field.

Take it further

This teardown reads GitHub through the UX Clarity framework, the same one we apply in a Full UX Audit: at each step, can a visitor tell what a signal refers to and what a control will do? For how that scoring turns into prioritized fixes, read what a real UX audit looks like.

Capture notes: five screens from one session on 7 September 2026, signed out, 1440×900, US English, public repository only. Counts, commit messages, check marks and relative dates were true on the day and will have changed since. No account, sign-in, star, fork, edit or download action was taken, and the capture stops at the top of client.ts, before any edit flow. The homepage appears only behind the search panel; its landing was out of scope.

Sources: NN/g — Visibility of System Status · NN/g — Recognition vs Recall.

Want to know which of your status signals users are reading at the wrong scope? Apply for a Full UX Audit →