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.

context

I picked up branding and graphic design classes at Art Center in high school, and remember being completely enamored by how designers were using digital and physical mediums to create innovative modes of communication. A few years later, when I came face to face with obstacles in the current hospital system, I was shocked. There seemed to be a disconnect between the possibilities that inspired me and the solutions being used in industry norms. With modern technology, I could order food or even toilet paper at the press of a button, but couldn’t access important medical scans without an outdated disc reader. It was a flaw in a system where the user experience should have mattered most.

What's a Kleiner Perkins fellow?

I applied to be a Kleiner Perkins fellow to expand my knowledge of design in the health space. The Kleiner Perkins fellowship is a three-month summer opportunity in Silicon Valley in which selected fellows develop their technical or design skills and are mentored by an executive within a KP portfolio company. Once accepted as a potential fellow, Kleiner Perkins delivers his/her application to its portfolio companies. From there, interested companies have the option to contact desirable applicants. Applicants then interview with the company(s) and only when s/he are given an offer are they a KP fellow. The KP fellowship was named the #2 internship in the US by Vault.com.

I landed a design internship at Helix DNA and connected with new leaders in the health-tech space who envisioned a more accessible health care system. As a fellow, I had the opportunity to meet peers and industry trailblazers who were equally interested in designing products that catered to patients and the people who cared for them.

AT HELIX DNA

At Helix DNA, I was brought on to work through three primary tasks: a concept for a Helix DNA API, graphic design elements for the company's Careers page, and a standardized product digital display for the Helix DNA marketplace.

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.

design elements for the company's Careers page

THE TASK

Pretty self-explanatory one here! I was tasked with creating icons for Helix DNA's Careers page.

EXISTING STYLE guide

To begin, the design team acquainted me with the existing Helix DNA icon style guide. I noticed the minimalistic, simple aesthetic that occasionally drew from Helix's brand colors. Because Helix is in its early stage of brand identity, it was important that I created icons that supported its progress.

PROCESS

The web product manager envisioned icons that would add in a similar style to what already existed explaining "How it works." There were particular do's and don'ts: stay away from too human of silhouettes, stick to simplified illustrations, flat without being completely two-dimensional, etc. I drew from existing internet icons that users would easily recognize and translate. After a couple of meetings with the design team and a quick turnaround of three days, the icons were installed into the Careers page.

ADDITIONAL ICONOGRAPHY

After the Careers Page icons were warmly met, I was asked to make additional icons, including this one of "sleep" for MySleepInsights. Seeing the new icons juxtaposed with existing ones affirmed my design decisions.

CONCLUSION

It was really fun to flex a purely illustrative muscle in my design tool kit. I was proud to see the icons installed and functioning, especially blending in with the existing Helix identity.