On a sunny January morning, deep in the research phase for Mailchimp Developer, we sat down with a Mailchimp API user to learn more about his workflow. Mailchimp was having trouble creating a cohesive developer experience; it had two disparate programmatic products with varying levels of neglect and, as a result, developers’ confidence in Mailchimp had dwindled over the years. Mailchimp hired Postlight to help unify these products and rebuild trust with developers.
“Can you show us what you’re looking for when looking at developer documentation?” we asked the interviewee. The developer navigated the existing site in search of the API reference, he bounced from the main Mailchimp site into the resources section for marketers, then back to the developer section, and finally — after two minutes — he found the reference. A developer spent more than two minutes trying to locate the API reference!
This simple prompt resulted in a powerful short video that unlocked the work ahead for us. It helped us clearly articulate the problem, rally stakeholders, and guide the solution to an all-new developer experience.
Marketers versus Developers
Mailchimp’s primary audience is marketers; it is a marketing platform after all. Mailchimp Developer, however, was the company’s first product for developers — but it was not designed with developers in mind. We knew this from our earliest interviews with Mailchimp stakeholders — but it took talking to users to really figure out exactly where the developer experience broke down.
We also knew that asking a marketing company to shift its focus away from marketers would be a tall ask. To do this, we’d need to bring Mailchimp along every step of the way toward a decision. This meant sharing our findings early and often with Mailchimp stakeholders.
Our first order of business was to get to know the developer audience inside and out. What are their goals, motivations, and blockers to getting their work done? We interviewed developers, sent out surveys, and pored over market research and analytics. The synthesis of that work resulted in a clearly defined user persona. Our research also provided a list of factors that developers look for in a good experience and highlighted the ones that made it bad.
Once we were clear who the audience was, we mapped out a product strategy that clarified the problem and expanded on where the opportunities were. Here we took stock of user needs and aligned them with Mailchimp’s business goals. Presenting project opportunities backed by data from the research helped us build a strong argument for prioritizing a different user group.
Back to that fateful user interview. By watching a developer quickly scan for relevant words and visual indicators that are synonymous with developer documentation, we saw that crucial cues were missing in his scan. The majority of content on Mailchimp’s site served marketers. There was no visual distinction between the content for marketers and the content for developers, which caused confusion for developers.
This told us that visual expression of the developer site would play a big role in letting users know they were in the right place. It needed to look different, but how and in what way? We took inspiration from developers’ preferred mode of working, highly focused and in a dark-themed code editor.
To bring this vision to life, we built upon Mailchimp’s existing core branding by leveraging the grid system, using the same set of fonts, and reusing existing components. The signature Mailchimp Developer color, named Charred Kale, was derived from darkening the original teal color named Kale. By playing within the boundaries of the established brand design system, we were able to create a distinct look that existed harmoniously with the rest of the ecosystem.
Now, when a user navigates from the main Mailchimp experience to the Developer experience, there’s no confusion about where they are. The big shift in color, language, and layout of information immediately cues to the user that they are in a different part of the experience.
Dedicated navigation and search
Our user interview revealed an even larger problem with the existing framework: that having a global navigation that served many audiences will only continue to cause confusion. Because “resources” could be interpreted as content for marketers and developers, we knew that the information architecture needed to be reorganized to accommodate two products.
Developers mainly seek out documentation when they are problem-solving. Search is a feature they rely on heavily to find answers to their problems. The mindset is urgent. Mailchimp’s global search function hindered developers’ workflow. The global search returned results across all of Mailchimp’s content, and the results themselves shared many of the same vocabulary. Additionally, all results were not distinctly differentiated in its presentation.
To build our case for dedicated navigation and search, we first level-set by reminding everyone who the target audience is and what their motivations are. We referred back to the user interview video to show exactly how confusing the current flow was. Then, we showed models from other companies with similar navigation systems to demonstrate its efficacy. Finally, we followed up by presenting a clear and concise path forward.
Finding a seat at the table
Design decisions aren’t made in a vacuum — they are a constant conversation. In a setting like Postlight, it means collaborating with our internal cross-functional teams and client stakeholders. When conversations get off-track, we often refer back to our research to support our arguments and to help remind the team of our collective goals and bring everyone back on the same page.
The result of this work is a beautiful and functional developer experience that signals Mailchimp’s commitment to serving the developer audience. As a true testament to the foundation we built, Mailchimp continues to build upon and dedicate resources to the developer experience. And it all began with a user interview and a couple of inquisitive designers.