On August 2017, the Genepeeks Board of Directors decided it was time for the company to pivot our business. The preconception screen alone was not enough for our company to survive. The idea of Genepeeks Software as a Service was born.
In order to make that shift we identified several things to change or improve.
- Automate our sequencing pipeline from data upload to analysis results
- Design and engineer the ability to upload sequencing data
- Redesign our analysis report, due to a change of audience, and some usability issues. This is what this article is about.
The previous analysis report looked like a black & white spreadsheet, with a proprietary terminology that only some internal scientists knew the meaning, like VGD score (Variant Gene Dysfunction Score), Genotype Likelihood, etc...
The report had been created for internal use only, and was serving the purpose of our preconception screen. So we needed to refocus the product for a different audience.
Before coming up with any solutions, I wanted to refine the problem(s) we might want to solve, and know more about our users, and their journeys. I formed a research group including 2 designers, 1 product manager, and 2 genetics counselors.
We remotely interviewed (using Zoom.us) seven people working in a genetics testing lab, and we put all our learnings / nuggets in our research system.
- 5 Medical geneticists
- 1 Bioinformatician
- 1 Lab technician / manager
What did we expect?
- To learn how they where discovering potential affecting variants
- To learn about their genetic testing lab journey, and the different actors
- To get feedback on the existing analysis report
What did we learn?
- That the different actors of a genetic testing journey had different tasks and need
- The existing report was confusing and users were not clear what to do with it
- To make the report more understandable and scientifically validated, geneticists needed
- explanations and clarity on how scoring was calculated
- a connection between genotype and phenotype
- how final results were determined
- links to external and trustworthy genetics databases
- more scientific publications to support this new approach
- We also learned what tools were used by geneticists during their journey
Mapping the journey was key to determine who would be using our platform, what feature they would need, and at which point in time during this journey.
Based on these findings we agreed to design for 4 types of users:
- Medical geneticist
- Geneticist (molecular biologist)
- Genetic counselor
The tasks/features we focused were:
- Automating our internal pipeline to improve our performance, and remove us from the analysis equation
- Setting up and launching an analysis - done by a bioinformatician
- Reading and curating the analysis report (scientific report) - done by a geneticist
- Interpreting the scientific analysis and creating a medical report - done by a genetics counselor (that last one was not part of our product design strategy, but might have been added later)
We focused on few different aspects for the redesign of the analysis report
- Cleaning up by removing unnecessary content that would make the report more complex to read, and interpret
- Reorganize the data in a more meaningful way
- Add phenotype information during the analysis setup and the report generation
- Better connect the report to other sections of the website
- Change the way we presented and visualized genotype information
- Add associated diseases information to each detected genes
We sketched lots of ideas and presented them to our scientific, clinical and engineering teams.
Based on the content of the existing report and the feedback we received, we came up with an information architecture where we wanted to dissociate subjects information, and gene results. Inside each detected gene we put summary information, clinical associations, and new important visualization based on the genotype.
During this phase we had lots of discussions about the right technology to use. Here is the output of a workshop between designers and front-end engineers where we evaluated the amount of work, if we wanted to use React.js.
Obviously each element of this report such as the subject information, the summary gene card, the genotype graph, etc... were subject to lots of different concepts that we evaluated internally, and externally.
We created several prototypes with different level of fidelity. Therefore, this step was very close to the next one (test). We needed to validate "as we go", plus we had to play with our research participants availabilities.
When we were at that stage, we started to be more concerned by colors, visual hierarchy, readability, functionality and interactions between components.
Some questions we needed to answer
- What's the behavior of the gene card when it goes from closed to open
- What happens if there are more than 10 genes detected. How will the user reduce that number?
- What happens if some of the variant score don't display any value?
- What happens if there are no associated disease?
- How to get back to this analysis report once you clicked on a subject details page?
- How the page is going to behave on a mobile device?
We tested as much as we could and whenever it was possible. Testing meant validating ideas, a sketches, wireframes, mockups, prototypes, or the final product... This is why this step is so connected to all the other ones.
What did we learn?
- The new report had distinct categories (high level gene information, variant information, genotype graph, and associated diseases) that helped geneticists quickly scan the information they were looking for.
- Previously the report would only expose the final score for each variant, without any explanation. Now by exposing the scoring tools used it allowed users to understand how this final score (VGD) was calculated.
- The ability
- Extra help appreciated! We added tool tips to help understand some of the terms the scientific team thought important to keep.
- The connections with external databases such as UCSC, ExAC, OMIM, and Genetics Home Reference, was found very useful, since those users always need to verify what they're looking at.