Errors could take place at three levels (1) starting an experiment, (2) running an experiment, and (3) ending an experiment. 

With an understanding of the problems, I defined key metrics to evaluate the success of our product. These are defined respective to the above problems:

I worked with scientists, study directors, and engineers and asked them to describe the process of running a drug trial. It was a messy and complex system, but after an hour of discussion, I was able to lead the team to create a simple map:

It’s great to interview experts, but it’s not enough. As a product designer, I also needed to look beyond what users said to see hidden needs and deeper goals. When one of my mentors was designing Pages at Apple, he spent weeks reading a book and then writing a book report. Designing for himself was an important part of building a product. When you rely on customers, you can only build according to their perspective of the world, which leads you to incrementally solve pieces of the problem, at the expense of the root problem. In order to deeply understand the problem, I also helped initiate new studies and run current studies.

The user map, combined with firsthand experience, allowed us to identify the key gaps and inefficiencies to be tackled.

The next step in the process was measuring each of these operations to evaluate how to prioritize each feature.

Next we also needed to define success.

Now that we had our roadmap in place and we knew the first feature on the roadmap, we began sketching and gradually producing mock-ups of higher fidelity.

For each of the major product features, I drafted hypotheses and took an iterative approach to design. Each wireframe was aimed at proving/disproving some hypothesis. Do scientists annotate their subjects in the sequence of xyz? Do they administer treatments in bulk or does each subject receive a different treatment?

For this sketch, my hypothesis was that scientists annotated one subject at a time.

When I interviewed scientists, I learned that they often applied the same annotation to dozens of subjects and having a means of selecting multiple subjects and annotating all of them at once would expedite operations.

For each feature, I sketched a rough prototype, performed user testing (described below), and as I grew more confident of each, I moved to more granular levels of design.

My job wasn’t done once the engineers started coding. During implementation, I kept track of how the project was going and made adjustments. There were three types of situations that came up during implementation:

1) Our front-end engineer was blocked because he was waiting for back-end endpoints. In this case, I needed to find other tasks for the engineer (usually through keeping an organized product backlog so that he could pull the next one), and in the meantime, work with our back-end engineer to get the work finished more promptly.

2) Sometimes, an implementation of a feature was harder than anticipated, and I needed to look for ways to change the feature to make it easier to implement. In our re-design process, this was especially true when a UI design feature didn’t play well with the database architecture. For example, in setting up a new experiment, the design allowed the user to freely enter data about lab materials and the company that was supplying the material at her own leisure. The database schema, however, required that the user first enter the supplier, and then choose from a list of materials. I worked with our lead engineer to make such features easier to implement.

3) Gather feedback and report bugs on early versions of the product. Sometimes a feature that made sense during the design phase did not work as well as expected in our early feedback sessions. For example, a cage rack view looked good when you had a few racks, but could be overwhelming when you had many racks.

In addition to dogfooding early versions, I also conducted usability studies and asked directors, scientists, and researchers to try out early prototypes of new features. I gave them a goal, e.g. "Create a new study," or "Assign 20 subjects to a new cage," and the participant would use the prototype to accomplish the goal. During these studies, I gathered success metrics and compared them to our benchmark from those using the old interface, which gave me information about how successful a new feature was. The final outcomes are documented below.

Inevitably, people will have different ideas for what ought to be first on the product roadmap. One person wanted an alert system, another wanted an automated QA system, and another was dissatisfied with the font choice. As the main liaison between engineering, quality assurance, marketing, sales, and business development, my job was to evaluate the incoming feature requests from each of these parties. It is important not to take all of these requests and go into a corner and prioritize them by yourself. Building a great product requires gathering all of the knowledge that is distributed in your teams’ heads.

Early on in the development process, several engineers were feeling demoralized that some features they had built did not line up with user needs during the testing phase. The main question here is: Could we have known what we have wanted to know without building it? If you could have known what you wanted to know, then there was no point in building that feature you're throwing away. If you couldn't have known those things, you weren't clear about whether a feature is for prototype or for production and setting those expectations for your engineers.

Expectations are key, especially in a rapidly moving environment where features are constantly being developed and thrown away, you must make it clear that the goal is not to build perfect things all the time. We are building things, taking feedback fast, and leaving a lot on the cutting room floor. 

During the design process, don't solely design in isolation with your users, but also talk with your engineers. Being a great designer requires you to be empathetic, not only to users or clients, but to your engineers as well. As a product designer, you are responsible for sharing designs early and often with engineers. That does not mean it has to be nicely packed and polished. It could be a rough prototype. Truly groundbreaking products are a combination of great design and technical breakthrough.