Design / Aether

Case study 03

Aether

Robotics and data modeling for chemists. We designed the web app, without knowing any chemistry.

Role
Designer
Client
Aether, via Berkeley Innovation
When
Fall 2017
Worked with
Three other designers, and Aether’s CEO
Tools
Figma, InVision
Three screens of the Aether web app on a blue background: a grid of projects, an optimization page with a molecule diagram, a yield graph and a results table, and a project page with workspaces

01Problem

When a drug is manufactured, chemists reach a stage where they try to find the cheapest, highest-yielding mix of chemicals to make a specific final molecule. Today that testing and iterating takes months and a lot of hard decisions, with very little technology helping. Aether uses robotics and data modeling to shorten that timeline, make projects and data easier to manage, and save millions of dollars.

Goal: our team of four designers was asked to design the interface for Aether’s web app, where process chemists would use Aether’s service to find enzymes that shorten how long it takes to synthesize a molecule.

02User research

First we had to understand how Aether’s technology works. We met with our client several times to learn about chemistry, robotic testing and how machine learning applies to their use cases. There was a lot to learn, and we asked a lot of questions before we even started user research.

Then we realized we had no users to interview. Our client couldn’t give us any, and we had no easy way to reach our audience: PhDs in organic chemistry working as process chemists in the pharmaceutical industry. So we scraped LinkedIn for 300+ emails and asked for phone interviews.

The email I sent, with the recipient’s name blacked out: a UC Berkeley student introduces themself, explains the interest in process chemists and design software, and asks for a quick 20 minute meeting
The email I sent. Recipient’s name blacked out.

We interviewed process chemists to get a picture of their daily workflow and find pain points. None of us are chemists, so we were especially curious what data they’d expect to put into a service like this and get back out.

Page one of the discussion guide: a description of the client, the research goals, our assumptions about the chemists, and a table of research methods
Our discussion guide, page 1 of 3: goals, assumptions and methods.
Page two of the discussion guide: the rest of the methods table, then interview questions about the chemist’s background, workday and software, and about using enzymes
Page 2 of 3: the questions, with the ones to prioritize marked.
Page three of the discussion guide: questions that walk the chemist through our screening and optimization pages, and an earlier version of those questions
Page 3 of 3: walking them through our screening and optimization pages.

03Insights

We did phone interviews with several chemists and heard some quotes worth keeping:

  • “There is a lot of skepticism in predictive software. Chemists want to see the justification and decision-making process on how the predictions add up.”
  • “I usually keep track of data by writing it down in my notebooks.”
  • “I would want more information about how enzymes work in biocatalysis because it is not as accessible at the moment.”

Our key takeaways:

  • They’re skeptical of predictive software, and worried about the security of their work.
  • They mostly use physical notebooks or the Microsoft suite to track data.
  • They identify molecules visually more than by name.
  • They prefer a simple but technical layout, nothing cluttered or confusing.
  • They want a web app that can adapt to their company.

We also came away with a list of the data they wanted or expected to see:

  • Ratio
  • Conversion in mols
  • Yield
  • Iteration
  • Temperature
  • Solvent
  • Cofactor

04Ideation

We started with a general user flow, then split up to brainstorm rough wireframes on our own. After that we got back together with our client, talked through the ideas, kept what worked, dropped what didn’t, and got feedback on what to add.

Three photos: a chalkboard user flow from a list of drugs to a drug’s reactions to results, pages of rough pencil wireframes numbered one to seven, and a whiteboard of consolidated wireframes with open questions about web app versus desktop, sourcing and patents
The user flow on the chalkboard, our individual wireframes, and the consolidated version.

Our main goal was to let chemists compare the results of different tests easily, which led us to tabs. We also went back and forth on how to organize data and projects, from folders with tags to a cascading sidebar.

05Mid-fidelity

We took our sketches into Figma. We ended up with cards, with workspaces, screens and optimizations built into each project.

Six grayscale wireframes: a screening results page with a green, yellow and red table, an optimization page with a graph and table, lists of recently completed optimizations and screens, a projects grid, and a workspaces list
The consolidated mid-fi screens.

06Final screens

First, the style guide.

Fonts and colors: Raleway for headings and Libre Baskerville for body text, four shades of blue, and the rationale for choosing dark blues for trust and a sans-serif plus serif pairing
Fonts and colors. We went with darker blues to give a sense of trust and credibility, and paired a sans-serif and a serif to bridge modern tech and literature-based research.
Component styles: a green Create button for confirmation, a gray Cancel button for options, a dropdown menu, a three-dot menu button and the box shadow settings
Buttons, dropdowns and shadows.

In the high-fidelity screens we fleshed out each project with a dashboard and an activity log, plus a description and comments. We also added an organization space for common project groupings and for managing teams, aimed at a company’s administrators.

Sixteen final screens of the Aether app: the projects grid, create project and manage team dialogs, a project page with workspaces, the activity log and comments, the organization page, screening results, lists of screens and optimizations, settings, edit profile and an optimization page with a yield graph
The final screens.

07Next steps

The semester ended and our deliverables were due, so we didn’t get to user test. Aether plans to show a prototype built from our final designs at a process chemistry conference, and to run user testing themselves.

08Takeaways

Know what you don’t know

We had no chemistry background, so we asked our client what we needed to understand. It also meant working out the right questions to ask users.

It’s okay to go off-script if the information is relevant

Aether’s CEO joined some of our interviews to bridge our lack of technical knowledge. Now and then he followed up on something a chemist said, and it surfaced things we never would have found with our original discussion guide.