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.
Live SiteThe rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
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.
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.
View full design here:
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.
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.
