I've been examining GitHub's design for quite some time now. One thing that I still feel I don't fully understand, from a UX perspective, is the call to action of the project page? In other words, what is a user expected to do when they arrive at a project's page?

An example project

The most prominent element on the screen is the file tree. 6 buttons are have the same visual weight (Watch, Star, Fork, Clone in Desktop, Download Zip and the green Compare button). Does the "interface" actually want the user to do anything, or does it actually convey a "know what you're doing or don't touch anything" message?

  • I don't think GitHub expects a particular action from users on this page. It's a tool, they are not trying to "sell" or promote anything. It depends too much on who you are and why you are on this page.
    – Gabin
    Mar 24, 2014 at 11:13
  • But what is the rationale behind their layout? Gmail is also a tool, but it's layout calls for 2 primary actions: read emails and compose an email. Doesn't Github want its users to do any particular action more than others? Mar 24, 2014 at 11:20
  • 2
    I think they have too much different users with different goals. Some come to contribute, others to download, others to watch, ... So what could they prioritize ? Their average user is probably hard to define. However, it would be interesting to push users to do some particular actions like contributing.
    – Gabin
    Mar 24, 2014 at 11:27

3 Answers 3


GitHub hosts code repositories that make use of the Git version control system. Traditionally, Git is a command-line driven tool, so most users of github actually "interact" with it using the command-line.

The web-based "view" on a repository (from my experience as a user) primarily holds two use cases/advantages:

  • Read some documentation without having to "check out" (download using the command line tool) the repository, if I want to see what the current project is about. To facilitate this, they usually render the README file on the project home page (below the code directory listing).

  • Navigate the code and quickly look at code changes by browsing to specific files in the directory listing, and comparing the changes using their built-in functionality. This is mainly useful if I blindly updated some library/project to the latest version (some developers may update more frequently than others), and now things break, so I will have to somehow see what has changed (this is not always easy, especially if you don't know where to look, and the release notes aren't that clear). But at least you can navigate to different versions of files and compare.

There are some other handy features, like the issue tracker, or forking a project, but you wouldn't typically use those features on a daily basis.

Lastly, it is quite nice to see some usage statistics at a glance right on the project page, specifically related to project popularity (number of stars/forks/watchers) and project activity (date when each file was last changed). This is particularly useful when comparing two projects/libraries that provide similar functionality, before deciding to use one in your own project.

  • I'm not sure I understand you answer. * The Readme section is below the fold. Had it been the primary use of the page, it should have been at the top (for example, switch places with the file directory. * "Quickly look at code changes". The changes (history?) aren't visible from the getgo. You have to know where to look for them (or am I missing something?) Mar 24, 2014 at 12:42
  • 1
    You mention "The most prominent element on the screen is the file tree" - treat this the same as the list of email headers in GMail. The files (emails) invite clicking. This is my second use-case. I am "using the page" by scrolling and reading the README file (not visible on your screenshot). This is my first use-case. But all of this is secondary to the way people actually use GitHub (through the git command line utility). So the web view is all about browsing and reading and comparing (for me at least).
    – CJF
    Mar 24, 2014 at 12:48
  • The problem with README files is that you don't know how long they will be, where the typical code project is neatly structured into a reasonable number of directories that will fit "above the fold". In smaller projects, you will see the start of the README immediately, whereas in others you will just scroll down slightly to see it. I can only comment on my specific use of the site, and from my observations working with other developers in larger development teams.
    – CJF
    Mar 24, 2014 at 13:04
  • Regarding changes: There could be hundreds/thousands of many smaller changes scattered across many files that may be irrelevant to me, so it is good that I don't see them by default. Debugging (on my local machine) will lead me to a single "problematic" file (hopefully), and then I will browse the repository to find that file and compare the changes between versions. If it is a well-maintained/developed library, I would not have to do this often (the problem will be on my side, rather on the library's side).
    – CJF
    Mar 24, 2014 at 13:06

Since GIthub.com is interacted with primarily via Git on the command-line the CTAs are located within the sections that users go to for primary interaction.

Coincidentally, these are the only actions not available in git-the-command-line-tool —i.e. they are features specific to GitHub.com:


enter image description here

Pull Requests

enter image description here


page image


You have to look deeper into GitHub's intended audience. GitHub was built by developers for developers, a majority of whom use the repository to store their code for software development projects that they're working on. I would assume a majority of GiHub's user base are of the technical breed, in which case we would consider them "advanced" users.

GitHub is more of a utility/hosting app, with a few things that may need more prominence than others such as creating a pull request (i.e. the bright green button). Each user comes in and may need to do different things, so it is likely a choice by the designer's at GitHub to not put too much emphasis on any specific items. Any elements that do have emphasis on them are likely used more based on usage stats.

For example, on the screenshot you posted, the most apparent elements are the Language Statistics and the green, "Compare, Review or Create Pull Request" button. In this case, the language stats (amongst other things) provides the user a quick overview of how much dev work was put into it via the languages used and the Pull Request button is there for when the user needs it. Based on usage, the designers/devs likely learned that this feature was used more at this point in the workflow.

In terms of call to action, think about how designer's or photographers use Photoshop, it's a tool. There may not be an intended flow or CTA per se, it's just a "toolbox" with all the tools you need to get your job done. The different ways of using it varies user by user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.