Helix API

2018     |    Kleiner Perkins Design Fellow
Helix DNA is a Silicon Valley DNA company dedicated to making DNA learning accessible and actionable for everyone. During my Kleiner Perkins Design Fellowship, I joined their Product Design team and one of the projects I took on involved creating an internal API interface that could help connect Helix services with customers for a seamless partnership.

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.

MAPPING WEB ARCHITECTURE

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:

• A clean, white aesthetic following the Helix DNA style guidelines
• A menu bar at the top with all Helix offerings
• A dropdown toggle between developer and engineer in the left side menu bar
• A left side menu bar with collapsible folders containing documents
• Navigational breadcrumbs in the subheader
• A section scroll on the right side within documents that snaps to where the user is reading
• An interactive task list that would communicate milestones between partners and Helix partner managers

user FEEDBACK

We presented this iteration to the Helix design team, partner managers, and engineering managers. We received high praise for the hi-fidelity prototype we were able to build in two weeks time. Partner managers were excited to see the ReadMe.io information organized into an accessible and appealing platform. The information was intuitively navigable and clearly digestible. They were also impressed that the product aesthetically felt well within the Helix product family.

However, we received pushback from one of the engineer managers. He expressed that the design didn't feel like an engineering API. Although it successfully catered towards partners, it didn't completely appeal to the sort of interfaces engineers were accustomed to.

We also learned that the multiple nav bars were confusing. What would go in the top section? How is "Docs" different from the collapsed folders? Is code "Docs" as well? How would the user know to toggle between partner and engineer viewports?

iteration 2.

The second iteration provided the following key architectural features and changes:

• A darker aesthetic still abiding by the Helix DNA style guidelines, but appealing to an edgier engineer audience. A white reading space was maintained for clarity and accessibility concerns
• A condensed left side menu bar, getting rid of the top nav
• Left side menu bar now has a Home page for holistic updates and directions
• Navigational breadcrumbs integrated into the left side menu bar
• Kept the section scroll on the right side within documents that snaps to where the user is reading
• Kept theinteractive task list that would communicate milestones between partners and Helix partner managers
• A survey at the bottom of the page
indicating helpfulness from the user

user FEEDBACK

We presented this second iteration to the Helix design team, partner managers, and engineering managers. The engineering managers were happily surprised and thoroughly satisfied with the aesthetic modifications, remarking that it "felt more like a portal we're used to."

We presented this concept to the entire Helix DNA company at the end of the summer and were met with positive feedback. Employees across teams approached us with questions of scope. They saw our concept as a possible solution to many of their key problems as well.

CONCLUSion

Because it catered to multiple stakeholders and managed a wealth of content, this project presented aesthetic and architectural challenges that positively grew my experience with user experience and interface design. It taught me to be even more sensitive to user preferences and to be thorough in mapping platform entrances and exits.

It also gave me the opportunity to execute information presentation. So much of health-tech has to do with the clear presentation of complex ideas and directions, and I felt that designing this tool gave me practice. Industry norms of medical histories and health-tech tools are muddled and not user friendly. I know this is just one API in an internet world, but I would love for developers to continue partnering with Helix DNA and looking for ways to bridge the gap between medical care and people care.