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.
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.
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).
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.
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.
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 and the . 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.
The first iteration provided the following key architectural features:
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?
The second iteration provided the following key architectural features and changes:
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.
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.