How We Did It: Inside The Dwolla Developer Portal Redesign

This post was written by our VP of Product, Brent Baker.

Last week I mentioned that we are rolling out a complement to the latest version of the Dwolla API — a deeply integrated developer experience within the entire Dwolla website — and the relaunch of our developer portal is now live. Our new API is the foundation of a revised Dwolla narrative and we knew how important it was to bring the developer experience to the forefront. The developer portal relaunch effort spanned nearly four months and required a herculean effort led by our rockstar Director of UX, Melissa Cooper. Our UX, Design, and Developer Relations teams played major roles in this relaunch, and we’ll peel back the curtain in this post to share our process.

Step 0: Discovery

With a redesign project, it can be tempting to throw out everything and start fresh. But when you do this, a lot of insight can be lost. Don’t start with the new — establish a baseline of the known.

Our developer relations team constantly interacts with developers on the Dwolla platform, answering questions and gathering feedback. So we had plenty of information about what developers wanted, but our design team still had a lot of questions. Particularly, we wanted to speak with developers who were less familiar with Dwolla, especially those who weren’t actively reaching out. We developed our user research plan very early in our process, conducted in-person and remote interviews, then synthesized and shared our findings.

From this, we gained insight into the needs of less-experienced developers and the expectations of experienced developers. We observed friction points encountered by first-time visitors attempting to complete a lightweight integration from scratch. We also spotted similarities in the ways developers of all experience levels sought information.

In parallel to the user research, we performed an audit of content on our existing developer portal. The extensive audit allowed us to understand what content was applicable to the new version and how developers consumed existing content.

Our third piece of research was to look at best-in-class developer portals that have been rightly praised for their developer documentation like Twilio, Firebase, and Github. We familiarized ourselves with standards that have been set by the industry and reviewed around twenty portals to determine what resonates best with Dwolla’s brand and intent.

At the end of this research and discovery period, we sat down as a team to define the project and write a comprehensive project brief.

Step 1: Defining the “what” and the “how”

Next came the most important step of our journey — establishing our intention. This step provides criteria for decision-making when faced with competing objectives and hard prioritization calls. Clearly stating what we wanted to achieve and how we would achieve it was critical to the success of this project.

We waited until the conclusion of the discovery process to outline our intent. This was to ensure that it was informed, objective, and void of any personal agendas.

The intention for the developer portal redesign is to:

• Clearly communicate functionality and benefits
• Focus on simplicity in implementation
• Reduce inbound support

The experience goals — the “how” — were then formed:

• Ensure the developer portal is a core part of the Dwolla experience
• Improve navigation and findability
• Provide a clean, concise, elegant reading experience
• Bring it in-line with new brand standards
• Provide responsiveness
• Reduce the “busy work” required by developers to accomplish tasks

Step 2: Creating a Content Strategy

After establishing our goals, we knew where we were headed. Next, we’d need to apply our stated intention to our thick stack of existing developer content. This effort was lead by our head of content, the incredibly creative Christine Choi.

One of the biggest changes to the content was to modify its direction and tone. We started by building clarity around the core message and articulating the value and benefits of the end solution (what Dwolla does best: ACH transfers) via the means (API). And from our interviews with developers, we discovered their sheer indifference toward what was perceived as “just marketing language,” and that we should instead simply help them find the path, tool, or answer they want as quickly as possible.

Step 3: Solution design and validation

Solution design began in parallel with content strategy to assist in defining how it would all fit together. An information-heavy site coupled with a responsive design meant that we’d need to pay a lot of attention to the navigation, so that’s where we started.

Over the ensuing weeks while concepting various ideas, we worked together on virtual hangouts, workshopped in person, and developed countless iterations in Sketch. For this project, we were working across three time zones, and an ever-improving clickable prototype using Invision was invaluable for sharing work in progress and getting timely feedback.

Once we found our direction, we conducted a second round of developer interviews with internal and external developers familiar with Dwolla’s API and with developers experiencing Dwolla for the first time. We received valuable and actionable feedback which has been incorporated into the site you see today. Overall, we consistently heard:

• “Simple”, “straightforward”, “useful” and “reliable”
• Appreciation for the commitment to developer experience
• Familiarity and standards were valued
• Reducing “busy work” leads to moments of delight

We tested our concepts with visual design mocks. This meant we were able to get a read on the perceptions of the brand and product to its fullest. Jeremiah Wingett, our Lead Visual Designer, was pivotal to the details of our interaction nuances. He worked tirelessly to sweat the details in response to the smallest finding to produce what you see today.

Step 4: Modular web design

Our lead front end developer Troy Blank adopted a modular web design in the form of style tiles deployed via Bower. The terminology, “style tiles,” originally conceived by Samantha Warren, can be interpreted many different ways, but its value lies in the reusable elements within a website without actually being on the website. Modularity is key. Much like an IKEA catalog, this creates a toolbox of modules to use as a starting point for design. The advantages of such an approach are vast:

• Site elements are validated for responsiveness prior to adding to production
• Tiles are considered the source of truth; design inconsistencies are inherently discouraged
• The design is abstracted from the actual build

So design, content and styles were in place. Then we moved on assembly.

Step 5: Use a simple and efficient stack

Since the developer portal is entirely static content, with no need for an application backend, our developer relations team lead by Gordon Zheng, chose to use Jekyll as the foundation of the project. The goal was to keep it light and minimize complexity. Additional advantages included:

• Free and reliable hosting on GitHub Pages. No worries about infrastructure.
• Grunt automated build pipeline which handles most processes: previewing, linting/minifying, deployment, etc. with just a single command.
• With the style tiles in place, the team can focus on assembly.

How simple does this make things? The build and deploy process is finished in 48 seconds.

In addition to simplicity, collaboration is also critical to this initiative.

• Documentation written in author’s choice of Markdown or HTML
• All changes tracked as commits with git
• Entire site is open source and on GitHub. Readers encouraged to provide edits and feedback in the form of issues and pull requests.

Launch (but we are never done)

Overnight our site content just grew 10x in depth and we brought the developer to the forefront of our brand and site experience. As a I look back on this year, I love how this initiative rounds out an incredibly successful 2015. For those keeping score at home:

• Q1: Launched v2 of proprietary real-time payments platform (FiSync) with BBVA Compass
• Q2: Released SaaS pricing model and redesigned web experience
• Q3: Added white label processing to our platform
• Q4: Developer portal redesign

The introduction to this post was originally published on blog.dwolla.com on November 5, 2015.