Problem
Mailchimp, a leading email marketing platform with more than 12 million users, offers world class APIs, but their developer experience did not reflect the quality of the products. Two of their flagship products, the Mailchimp API and Mandrill, lived on separate domains, and lacked a common language. Other inconsistencies, like pricing structure, contributed to measurable customer attrition.
Postlight was asked to help bring the two products closer together, level up the developer experience, and rebuild customer trust through the unified experience.
Mailchimp Developer and Mandrill at the start of the project.
discovery procEss
My team started the engagement with a 2-day cross-company kickoff to understand the depth of the problem from Mailchimp’s perspective. Building on that shared foundation, I conducted qualitative research with developers, marketers, and stakeholders to validate some of the product requests.
During a user study, I asked a developer he would navigate the existing technical documentation. This is a sped up video of him clicking around and failing to find the API reference despite being on the developer landing page.
During a user study, I asked a developer how he would navigate the existing technical documentation. He struggled to find the API reference section, despite being on the developer landing page. I arrived at the realization that the page’s “marketing” style design was contributing to this poor user experience. It was a “lightbulb moment” for me and my team.
Product strategy
I established that developers would be the primary users, and that the experience must cater to their unique needs.
It had to be easy to learn about the API capabilities, while simultaneously encouraging collaboration between developers and marketers. In coordination with the initial research, I defined use cases, core workflows, developer personas, and high value user experience opportunities.
Top left: Defining our target audience.
Top right: Feature wishlist, what makes good developer docs versus a poor one.
Bottom left: Identifying user work modes.
Bottom right: Understanding our landscape
Building blocks
With a sitemap in hand, I enumerated all of the distinct features that each page would need. For example, Guides and API Reference would need code samples, while Release Notes would not. I also created a “user needs prioritization board” which answered important questions like “When our primary user is on the homepage, what is their most important task?” This allowed our team to stay on track, meet strategic goals and identify unique components which ultimately became the design system.
Top: List of features for each screen
Bottom: Prioritization of users' needs
visual direction
The existing Mailchimp visual language served as a building block for my explorations because, while /developer caters to a different audience, it still lived under the brand’s main dotcom umbrella. I saw an opportunity to visually differentiate the two spaces by introducing “dark mode” theme, paying tribute to the preferred working environment of developers everywhere. With the general direction approved, I refined the color palette and design elements to maintain a connection with Mailchimp’s existing style guide. The result was an experience that felt focused, quiet and mission-oriented.
In a sea of marketing content, the goal was to visually signal to developers that this content was for them.
Visual direction and early color explorations.
challenges and solutions
API Reference
An API is judged by the quality of its documentation - it must be easy to scan and use above all else. At first pass, the existing implementation was tidy and spacious, but upon closer examination, I uncovered several ways to improve the experience.
- Increase information density
By condensing line height, I was able to fit more information between scrolls - Enhance scan-ability
By reducing text-wrapping and column gaps, I made it easier to scan across rows - Introduce visual hierarchy
By creating a connection between parent and child properties, complex concepts were easier to communicate - Revamp way-finding
By making the sidebar navigation sticky, I made it easier for developers to know where they currently were, and how to jump to different sections.
New and improved version API reference vs. previous version
Previous API reference in mobile breakpoint
03.png)
Redesigned API reference maximizes available space
02.png)
Code snippets accompany related endpoints
01.png)
Expandable sections help to avoid navigation to a new page
design details
Search
During user research, I observed a pattern of behavior where developers will:
- Encounter a problem
- Search the documentation
- Find a solution, and then
- Leave the documentation and return to work
This meant that the existing search functionality, which blended results from developer content as well as other sections, made it difficult for developers to find what they were looking for.
I addressed this problem by introducing a dedicated /developer search experience, with search-as-you-type functionality to reveal results faster and save developers an extra click.
New search panels and previous search results page
design details
Dynamic Header Images
There were two problems I tried to solve with header images for Guides. Firstly, I needed to create distinct visuals to represent an API, this can be difficult given the abstract nature of the topic.
Secondly, when sharing a series of links to Slack or Twitter and the preview image is all the same, it can be hard to tell what’s what.
I created a binary code pattern, a cheeky nod to the world of code, which accompanied each guide. The team came up with an integrated system to dynamically generate a binary code pattern based on a keyword.
This resulted in a subtle but unique visual for each guide. And I’d be remiss if I didn’t call out the extra care our engineering team took to animate the pattern in, making it shimmer on load. ✨
Now when shared socially, the variation in the patterns help users differentiate between other links shared. Integrating this feature into the CMS also means that as new guides get published a new pattern can be generated quickly, this provides a sustainable way forward for asset creation.
Above: Header images in action
Below: Open Graph images in Slack and Twitter
Summary
This project kicked off in January 2020 and launched 7 months later. I delivered a product that was well-researched, thoughtful, and visually compelling. A completely reimagined experience that arrived on-time, despite significant headwinds from COVID19 and its accompanying challenges.
In less than 2 months post-launch, the developer portal was ranked top 10 pages directing traffic to Mailchimp's sign up form.
role & Team
Lead Product Designer
Responsibilities included research, product design strategy, design details, and mentor to junior designer on the team.
Design team also consisted of a design manager and junior product designer. Product manager, 3 engineers, 3 content strategists, and an account lead made up the rest of the team.
---
Project completed in 2020 at Postlight.
Role & Team
Lead Product Designer
Responsibilities included research, product design strategy, design details, and mentor to junior designer on the team.
Design team also consisted of a design manager and junior product designer. Product manager, 3 engineers, 3 content strategists, and an account lead made up the rest of the team.
---
Project completed in 2020 at Postlight.
%20-%20cropped.png)
