Developers content
Duration: 1 quarter
Problem to solve:
“How might we help diverse kinds of Developers discover our API products and lead their teams in adopting them?”
Format: responsive web
Status: shipped
The problem to solve
LinkedIn wanted to revamp its website devoted to developers and APIs. API revenue was far below that of competitors, and there appeared to be an opportunity to change this.
When I joined, the site had long been dormant due to security concerns. Very few new customers were being let in, and existing customers were managed via manual sales interaction. The website showed three product cards on its front page, a fraction of the actual LinkedIn API offering.
At the same time, the website linked out to so many external sites that tried to tie into its navigation, that to traverse the content meant navigating a half dozen different headers.
Alignment: user research
To understand how companies adopted APIs, I asked for a foundational user research project alongside a user research specialist. The resulting report showed that the adoption of APIs typically followed a typical pattern that I illustrated in the comic strip to the right.
The pattern goes as follows:
Adoption was usually initiated by a product owner or an end-user such as a marketer. They found the Developers website by reading a case study featuring APIs. This advocate would stay on until the API was adopted and would then often measure its impact.
Technical partners were brought on later in the process, but they would expect to see both non-technical and technical material on the Developers website. The advocate and their tech lead would go on to become the chief users of the Developers website
We found that the API adoption process often involved 12+ people, and was driven by users reading and sharing content, such as onboarding studies, technical documentation, and legal terms.
Product principles
Based on the research report, my user research partner and I wrote product principles together:
Cross-functional stakeholders should easily be able to find the information that directly pertains to them. For example, text about the value of an API should be shown with links to the right technical docs, so that product and technical people can read the same text and get what they need.
Cross-functional stakeholders should easily be able to understand the end-value of the API and convey it to others. For example, we could showcase studies from real companies to highlight the value without sounding like an ad.
Cross-functional stakeholders should easily be able to have visibility into each others’ tasks and progress. For example, we could show lists of links of content for the product, technical and legal partners.
Information architecture
I studied competitors to decide on an appropriate way to organize our content. A useful insight was to see that our website was a storefront, but functioned more like a department store than a boutique.
Given the complexity of our offering, I decided the simplest way to organize them would be by the line of business: marketing, sales, learning, etc.
Once we had a taxonomy, the rest of the information architecture worked. The user flow was straightforward and familiar -I often compared it to that of a good cooking website.
Proposed website IA
Page design
We had a much bigger hurdle once I arrived at page design, particularly the home page and the product detail pages. Most of the problem was in the product offering itself: once I showed designs to my project partners, missing information and misalignment revealed itself.
To keep the project going, I designed fairly speculative pages with dummy text for some time, hoping to break the deadlock. The group was finally ready to align once a temporary PM was assigned to the project, and the page design was quickly finalized.
I also discovered that designing a content-heavy landing page was not something that I or my team necessarily had the expertise for: most of us had not designed a page like this in many years, and in the design reviews the rust was apparent.
Final screens
Home page, product catalog, product detail pages and content pages
Build
Once the design and copy was finalized and approved, we set about having the site built. This stage provided a small shock. Since these were static pages, my engineering team handed the build off to an agency who only had limited ability to customize the CMS they would be working on. As a result, the agency would only be able to approximate the designs we provided them.
What I learned:
The results of this project were met with internal fanfare, and were highlighted in a “Product Top 5” email that went out to 11,000 company employees.
A design-led project without a PM turned out risky for me as a professional. I had stuck with the project when it ran into requirements misalignment and found myself associated internally with a non-linear process that alarmed some people.
I’m very glad I took on the project and drove it to its conclusion, despite its hurdles. My commitment came from the fact that we had solid user research for this site, but had chosen not to deliver on those insights. That to me was unacceptable.
While I was unable to shed the many external sites that the service relied on, I was able to stitch the content together with a consistent business and product taxonomy.
Once the new pages were in place, they set the stage for many future efforts that could build on rich content pages, and a sound taxonomy.