Redesigning the developer website

Earlier this week we launched the redesign of developer.foursquare.com, a project I’ve worked on for the past two months as part of my internship on the platform team.

Above: our redesigned developer site

On my first day, Akshay, our platform evangelist, told me that the redesign would be my primary project and I’d pretty much be the only one working on it. At first, this was really intimidating. As a junior at the University of Pennsylvania, I have only a handful of technical experiences under my belt compared to the years and years of expertise that everyone on the platform and engineering teams bring to the table.

My experience aside, I approached the redesign with one main priority: to understand the developer experience first, digging deep into what different users expect out of the site. From there, I was able to sort out the underlying organizational issues and content gaps in the site, and then examine the design and implementation themselves.

Our site analytics confirmed what we suspected: most people visiting the site came to view our endpoints, but it took two clicks on very content-heavy pages to get through to them from the main site. It was clear that important pages like these weren’t easily discoverable: Akshay consistently fielded questions that could be answered from reading our somewhat hidden tutorials and overview pages.

Above: Screenshot from our previous site. We’ve come a long way from when the platform was just getting established two years ago.

The problem boiled down to this: the developer site has a handful of different audiences. It’s not only home to thousands of developers, but also the business partners who want to build on our API and engineers who develop partner apps. Yet our previous design favored none: endpoint pages were entrenched deep in the site, our overview and samples were difficult to find, and our copy was often too technical for a non-engineer to understand.

Different technical sites treat the problem of multiple audiences in different ways. For instance, the Facebook API front page separates people into one of three buckets by project role: web developers, mobile developers, and in-app developers. Microsoft’s .NET product site splits audiences into four groups by profession. We approached this problem by segmenting our core groups by technical skill level, which seemed to be natural groups formed within our community already.

For newbies, we wanted to make getting started quick, non-intimidating, and simple. We divided our impossibly long “overview” pages into several shorter ones that were easier to digest. We also introduced a logical sequence to follow: starting with a prominent “Getting Started” button on the front page, then with a presentation of some of our most common use-cases and samples, and then a deeper dive into how to set up with OAuth 2.0 and the like. For those impatient and in a tl;dr mood, one could dive right in to our endpoints after the second step and use the working code templates.

For repeat visitors, we just wanted to make getting to the endpoints – the “meat” of the matter – easier to get to, so we surfaced a link to the endpoints and our API explorer feature right on the front page. We also consolidated all of our endpoints to one page and made them filterable by platform type – so someone developing apps for venue managers need only view all of the merchant-relevant endpoints at once, and so forth.

And for business decision makers, as well as those looking to read about some of the inspiring creations of our developer community from a more technical perspective, we created an apps showcase that highlights some of our favorite apps built on our API. Some are excellent illustrations of what our robust venues database can offer, some demonstrate the benefits of what foursquare as a service can offer to merchants, and some just show how cool it is to be connected to others by the mutual thread of location.

Above: Site mock-ups. Pages categorized by audience. Purple = everyone, red = regular visitors, green = newbies.

We put a lot of thought into this because what we put into improving the developer experience ultimately comes back and benefits both the developers and the 15,000,000-strong foursquare community. If you have any questions about the foursquare platform, definitely post them on the new StackOverflow forum or send them over to api@foursquare.com.

This 10-week internship taught me more than I’ve ever gotten out of school in the same amount of time. While I’m excited to continue my academic education back at Penn in the coming year, I can’t wait to see what the Platform team has planned next.

– Alice Lee, Platform Intern (@byalicelee)