Project Description
The interpretation space is a tool for clinicians and researchers to use to keep a record of which genetic variants are most likely to be pathogenic or benign with respect to their current case. Here, clinicians and researchers are able to write notes, view and invoke ACMG rules according to the standard guidelines or their own custom ones, can generate an auto-classification, and record their final variant classifications. Paired with the CGAP annotation space, the interpretation space allows clinicians to use the annotation data for samples, genes, and variants to build, record, and justify their variant classifications for future reference.
How I contributed:
I was involved in both the design and development stages of CGAP's interpretation space. Our graphic designer created the mockups, in communication with me, and the clinicians on our user test team, and then I built the interface in React. In order to develop the algorithm for auto-classifying variants, I read numerous papers regarding the ACMG Guidelines, and worked closely with clinicians on the Brigham Genomic Medicine team to ensure the results were accurate, even when users customized the strength of rules to suit their own internal adjustments. We went through several iterations of the note-taking interface, as we discovered new user needs and sticking points, which I detailed in a short presentation viewable here.
What challenged me:
The biggest setback we faced on this project was actually a really tiny UX detail that we overlooked in the planning phases. Originally, we planned for the same button (with dropdown) to be used to handle various ways of saving (to the case or the knowledge base, for instance, which basically just allow different levels of access to the note):
In a clinical workflow, the primary concern is always accuracy; our testers were very worried about the possibility of people saving a draft, having the "approve for case" version of the button activate, and then accidentally approving the note before it was ready. This concern was even greater when "approving for case", since updating the same button meant users could slip and add something to the global knowledge base. At this point in the process, there was no easy way to revert either of these sorts of changes, and we didn't have the time to add those "undo" features before release, so instead adjusted the plan quite a bit.
In the end, we decided on a two-button workflow: one button for saving drafts, and one for moving back to the case. And then the entirety of the note approving and sharing functionality was moved to a dedicated interface, where it would be harder to make these sorts of mistakes, and easier to remedy them should they happen.
What I learned:
This is a really great example of the value of including interactive prototypes in the design phase after the creation of static mockups, but before the coding phase. Small interaction details like this can be easily missed when you don't actually get to "feel" what it is like to click between different parts of an interface.