THE PROBLEM

Helix DNA primarily functions through partnerships with outside companies, such as National Geographic and the Mayo Clinic. This strengthens the company's credibility as well as makes it as a collaborative provider of DNA technology. However, by nature, the relationship can often become confusing as partners navigate how to onboard and develop with Helix. What does a partner need to prepare? What should it understand to ship with Helix technology? How is communication with Helix maintained throughout the process?
‍

On the Helix end, partner managers had a difficult time gauging their client's understanding as they prepared to create apps within the Helix system. Their biggest fret was that the night before a client's deadline to ship, they'd find that multiple tasks had not been completed.

A TEMPORARY SOLUTION

As a temporary solution, partner managers created a dense digital ReadMe.io document outlining important information and directions. However, the content was all over the place and difficult to navigate as it hopped from link to link to link. It also did not provide a transparent way for partners to communicate where they were in the process, making meetings primarily about retroactively updating the opposite party as opposed to proactively addressing next steps.

A LONG-TERM SOLUTION

To combat these points of friction, Helix's team of product managers envisioned a Helix API that would organize the onboarding information and be a transparent platform for partner managers and partners to communicate. I worked primarily with product management intern Fiona Tang to design a successful concept around these goals. She and I first storyboarded potential use cases for the API from two principal perspectives: a partner engineer (primarily interested in the Helix language and code necessary to build a DNA app) and a partner developer (primarily interested in managerial information).

IDEATION

We made the ideal team. Fiona had spent two weeks before I had been brought on understanding partner relationships and the available documents. I was then tasked in translating those relationships and information into a user-friendly flow. The main challenge we saw was creating a platform that could juggle multiple departments: marketing, legal, development, partner, etc. Each was important to a successful product.

user flow

After reviewing all the ins and outs of Helix-partner relationships, we mapped a portal according to our two principal perspectives. Ideally, the portal would assist partners and developers by providing them information organized in two primary categories: documents and tools. These categories encompassed the gamut of information in the ReadMe.io and allowed for entrance pages that could introduce other capabilities when available.

DESIGN RESEARCH

In designing the platform, I researched what existing API platforms were popular and effective. By doing this, I could build a tool that would ultimately be unique to the Helix family but familiar to the landscape. Top contenders were the Uber API and the Stripe API. Reviews and online discussion remarked on their organization and engaging use of split windows for dual, correlative information.

Building off of these organic user reviews, Fiona and I began to arrange our requirements into UI features. We knew we wanted the categories to be placed on the left in its own menu bar, and be easily navigable however deep a user were to be in the layers of content. The design would also have to scalable for future, new information.

iteration 1.

The first iteration provided the following key architectural features: