Amino Design System
January 22, 2018 | 5 minute read
Design Systems are often seen as a luxury in which only large teams with lots of time and resources can invest. The reality is that, much like any other investment, they pay larger dividends the sooner they're implemented. Amino is Transcriptic's Design System which I've led the development of since 2017. This is the story of how Amino, the first Design System for the life sciences, was brought to life.
đź‘‹ This project is from my time at Transcriptic. Before you get going, you might check out this quick primer on Transcriptic and Strateos.
A Quick Note
The Amino Design System is an effort I have been working on at Transcriptic/Strateos for several years. This page offers an overview of Amino's origins, and my process for bringing it to life. After exploring this page, I would encourage you to dive into the details of this effort in these case studies:
Why a Design System?
When I first joined Transcriptic, I was the only designer supporting more than two dozen engineers and scientists. It quickly became apparent to me that no matter how hard I tried, I would never be able to provide design support to every new feature. The timelines and product demands were simply too much to keep up with. Furthermore, I kept seeing the same UI regressions popping up over and over again: broken layouts, inconsistent interactions, CSS name collisions...
We needed a single source of design truth where I could describe and implement design intent, and distribute that intent to all of our software, automagically. In short, we needed a Design System.
The Pitch
Getting the buy-in to put time and resources towards a Design System at a rapidly moving startup is no trivial task. I began by framing my proposal with four goals.
Goals
1: Maximize Team Productivity
So much of design and engineering's time went into re-implementing UI experiences and re-solving small design challenges in our many views and applications. Furthermore, I did not have the capacity to provide detailed mocks for all new features – I needed to help the engineering team build new polished UIs without my input. There were clear productivity gains to be had by centralizing the common aspects our user interface design and engineering.
Two different tables in the same Strateos app, each with similar functionality, implemented in different ways.
2: Align Design Languages
The Transcriptic stack consists of four separate apps. Lacking a shared design language, their visual design, interaction patterns and affordances had begun to diverge – creating a jarring experience for users (namely Transcriptic employees) moving between them. Standardizing the design languages across all of our apps would dramatically improve the user experience.
Viewing an experiment as a customer and employee. There are some shared elements, but the two views have different layouts, hierarchy and interactions.
3. Cleanup A Fragmented User Experience
Even within individual Transcriptic apps, our user experience was clunky, and our visual design brittle. It felt like every day we needed to patch a UI regression introduced by a seemingly innocuous bug fix or feature release. Building our interface from centrally maintained components and styling utilities would greatly reduce the amount of time we spent patching UI regressions.
4. Reduce and Simplify UI Code
Lacking a well-maintained, centralized set of UI components and styling utilities, our codebase was bloated with duplicate code that was extremely vulnerable to unintentional CSS overrides and side-effects. Using carefully implemented and maintained React components and Sass mixins/variables would increase our development speed, and reduce the amount of styling side-effects introduced by new features.
Reception
My proposal to address these four goals was met warmly by our VP of Engineering. I got the green-light to spend a substantial amount of my time a design system.
The Plan
To begin, I drew on my experience working on the IBM Carbon Design System and developed four core principles to drive the development of the Design System.
Unity Across Experiences
All Transcriptic UIs should feel unified. Even though each of our many tools accomplish very different tasks, users should be able to move between them with familiarity. When we develop new tools for these users, they should be familiar and useable straight away - thanks to a unified UI/UX system.
Independence Through Structure
Each piece of Amino performs on its own. This is a UX and engineering ideal. For UX, design guidelines allow components to be endlessly arranged and composed. For engineering, components are usable right away in any React codebase, with no external dependencies.
Autonomy For Faster Development
The compose-ability and structure of Amino lets developers work autonomously, with minimal design input. Rules and guidelines are enforced with thorough documentation, development tools like linters, and utilities that abstract away design decisions.
Focus on a Core Audience
We do software and biology, and Amino is made by software developers and biologists, for software developers and biologists. Life Science is an assumed context when it comes to the needs and intents of our users - and as a result the components and layouts defined here build from that assumption.
The Process
Component Audit
To understand the full scope of the Transcriptic UI footprint, I walked through each of our apps and took screenshots of every unique aspect of the UI that I could find, such as visual components and layouts. I printed these screenshots out and cut them up into their constituent parts. Then, I performed some basic affinity mapping to understand into which groups the various components fell.
Grouping UI elements together by functionality allowed me to see where we had duplicated UI code.
From here, the next step was to consolidate this set of UI elements down into a Sketch Library of sharable components.
Project Management
To approach this broad task, I broke the work down into the following pieces:
1. UI Foundations
Define the design foundation of Amino, such as typography, colors and sizing.
2. Foundational Refactor
Build out coded implementations of the design foundation, and refactor our largest codebase to make use of the new foundation.
3. Component Consolidation
Consolidate the list of audited UI components down to a list of components that will be included in the Design System.
4. Component Design
Building on the design foundation, develop designs for the list of consolidated components.
5. Component Refactor and Migration
Following component design, migrate existing component UI code into a new single source.
6. Documentation Generation
Ensure that all the work done above is properly documented for our team, and the world.
Execution
To begin, I worked within a directory of our customer app - limiting its usefulness to that product. I worked quickly to lay down a design foundation, going after the low hanging fruit first such as colors and typography. I then moved onto fundamentals such as spacing and layout, and then finally on to React UI components.
After demonstrating the utility of a design system, I began the process of splitting the code out into a private NPM package. But this process demanded something I hadn't thought of yet... a name.
Naming
Every design system worth its salt is well branded. Having a proper name and visual identity for a design system helps build adoption and recognition of the system within an engineering organization. It's seen as an internal product – one that we're proud to use – instead of a collection of rules and regulations.
I decided on the name "Amino" – drawing on the concept of Amino Acids, which are the molecules that make up and define proteins. They are, in some ways, the building blocks of biology – much as Amino is intended to provide the building blocks of our life-sciences products.
Outcomes and Next Steps
The creation of Amino was the result of several substantial efforts – each of which are detailed in these separate posts:
Within Transcriptic, Amino has been a huge success. It’s currently used in several internal and external tools, and deployed in the labs of top biotech companies. It has drastically reduced the development time of new features, and has led to UI code that’s far more thoroughly tested, stable, and understandable.
Moving forward, the documentation for Amino needs to be built out substantially. Beyond documentation, there’s a need for more foundational components and tools to aid in layout and composition.