Over the course of several months, I worked with various developers to create an MRI viewer application. This included managing a team of external developers, outlining goals and handling scheduling & budgeting, while also designing the whole user experience and interface of the viewer application.
Sole Designer, Project Manager
Stakeholder Interviews, Personas, Information Architecture, User Flows, Visual Design, Usability Testing, Project Management
Sketch, Gitlab
2020
https://www.youtube.com/watch?v=Hrd-0p6QCA0
MRI viewer applications allow radiologists to inspect images for suspicious areas, which helps them diagnose patients. There are many features on these viewers that serve many valuable purposes. However, for specialized radiologists (such as a neuroradiologist) who only need the viewer to accomplish a few specific tasks, these interfaces can be too noisy and complex. We wanted to design a viewer that not only helps our neuroradiologist user accomplish their tasks faster than they would in their own program, but also helps us collect segmentation data that can work towards improving our algorithms.
We knew that there would be two user segments: the everyday neuroradiologist and the annotator. The annotator works for us in order to help us improve our data sets. After interviewing two people from each user segment about their use of viewer programs, I drew up the following personas which I hoped would be enough to inform the feature list. It turned out that the needs of the users were aligned with the business requirements.
Though the interviews with the different users were valuable, it was not enough research for me to be able to clearly define the functionality of our viewer. So I looked at various other viewers and segmentation programs that I could find online. I inspected what kind of tools each of these programs had and how they worked, running my own usability tests of each program. The research showed:
The research led me to define the following problem statement:
From the research I was able to define which features our viewer should have and how they should function. Next, I needed to figure out how each feature would be accessed by the users and what the sequence of behaviours should be. This information would be important when describing the functionality of each feature for the developers. So I drew up the following user flow, whereby the rectangular items denote user behavior and the circular items denote the subsequent behaviour by the app.
With this user flow complete, I was able to thoroughly outline the functionality of features for the developers in Gitlab tickets:
Screenshot of Gitlab ticket descriptions first written out in Google Docs.
(View full design on youtube vid embedded above!)
Default screen for a static assessment.
Screen for a longitudinal assessment with an example overlay.
We tested the viewer with hallway testing methods, employing several colleagues to test out the viewer themselves in order to identify any bugs or features that weren’t working the way they should be. This was the most optimal testing method for us given time and resources.
In the meantime, we also added keyboard shortcuts as we found that radiologists preferred to use their keyboard to perform certain actions in their own viewer.
Shortcut overview menu accessed from the viewer.
After releasing the viewer application to be used by our users, we were happy to hear that the defined functionality was aligned with users’ expectations and did not need changing.
The biggest challenge with this project was managing a team of developers while ensuring I was delivering timely designs. This was an issue because the whole project, including the UX planning, began at the same time as when the developers were to start working. So I had to research, design and test (while ensuring the developers were meeting the deadlines) all at the same time throughout the whole project.
To mitigate this issue, we planned out the viewer development in three stages. After each stage there would be time for testing and making any necessary changes to that phase of development. I started the project by first outlining the functionality of the backend and drew up some rough sketches of certain screens or features so that the developers would have a good starting point. While they worked on implementing the backend, I properly defined the user flows and refined the UI, allowing me to thoroughly outline the rest of the features to be developed. Though we had to make changes to the functions throughout the project, they were easy to implement as they didn’t impact the backend, whose functionality was properly defined at the start.