Brief
AIMS (Automated Immune Molecule Separator) software is designed to generate a robust workflow for the analysis of immune repertoires and identify discriminating features between distinct subsets of a given dataset.
The workflow is based on the analysis that Christopher Boughter (Founder) used to generate the data in his recently published article.
Goal
To enable fellow scientists with too little or no programming skills to access fast and reliable analysis for distinguishing distinct subsets of immune molecules.
The Challenge
I have joined Chris during the second version of the app, as a sole Design Consultant for the project. We were facing scarcity of time and resources. The complexity of the project forced us to ensure that the critical functionalities should be improved to get a fully working app in time for the MVP release.
Unique Solution
The app was more likely to crash rather than providing error codes at the very early stage of development. Therefore, we had to focus on not allowing the user to make mistakes that would have lead the program to crash.
Research
For the purpose of the user research, I have analysed the feedback gathered from the first app release, as well as interviewed the Scientific Consultant (SC) of the project. Since SC herself was the initial user that inspired Chris to design this software, I decided that she will be the first address to answer my questions about types of user’s problems and needs that AIMS was aiming to help with. I have identified 3 groups of users, depending on the level of experience, as well as the type of needs they represent. This will help approaching the app design from the perspective of each user, making sure that the interface helps to solve their specific problems.
User 1 is the main type of users and the one we decided to focus on. This type of users only starts to play with big data. They want a guidance and an easy interface but also some sort of custom options and settings. These users are still exploring. Therefore, some community or test dataset, and results section would be helpful. User 1 is more determined than user 3 but much less experienced than user 2. They are still testing different options in their research and do not know what the best for them is. Large sets of data are very time consuming to filter through. There is no automated process in place, and it is usually done manually using Microsoft Excel. This is very time consuming and limiting, as it allows only for a few features to compare the results with. User 1 will be using the AIMS app to create large database and analysis reports with guidance and explanation of all features.
User 2 is very proficient with these kinds of software and also quite likely to have advanced programming skills themselves. They will be accessing the AIMS app through coding directly.
User 3 is still a beginner. They don't quite know the potential of the software and use it more occasionally. They will eventually follow the User 1 path but might need more encouragement and guidance to start with.
Personas
Opportunities
Since User 1 is surrounded by various options. This means that each time they encounter a new software, they have to learn it from scratch. Plenty of bio-tech apps are very utilitarian and not user-friendly. Hence, the process of learning them is usually time consuming. The users need to weigh the pros and cons. They also assess whether learning a new software, which potentially might not produce the desired results, is actually worth their time.
This has created an opportunity for AIMS onboarding system. In this way users will be able to evaluate, right from the first screens, whether this is a right fit for them. If they decide to proceed, they will get the gist of the main features and familiarise themselves with navigation of the process.
Ideation
The main problem of the current app is that if the user tries doing something out of the app’s capacity, the software is likely to crash. We had to think of the solutions that would stop users from doing what they were not supposed to do. We investigated few options. A short-term solution was greying out fields and buttons that were not active until user completed all the required tasks. However, the issue with uploading files that didn’t match the selected format and causing the app to crash was still prevailing.
I have sketched the user flow and noticed that by swapping the few tasks around, we could minimise the risk of incompatible files being uploaded. The user would first need to specify the format of the files they are using and then upload that type of files. In doing so, the users’ attention would be drawn much earlier to the correct file type, and we would prevent them from uploading incorrect data.
The upload system would then automatically stop upload for the file that doesn't match the previously selected format, thereby preventing the app from crashing. If the user wishes so, they can go back to the previous step and re-upload the file of a correct type.
Onboarding
I have introduced an onboarding feature to capture the essence of what the software does. The idea behind this is to explain enough to the users so that they could navigate throughout the app more intuitively without having to follow the guidelines step by step.
This introduces users to the functions of the app and familiarise them with what they can gain from using it. Quirky illustrations will encourage users not to look at this software as a yet another utilitarian application.
File Upload System
Lack of ‘adding more input files’ feature on the ‘upload files’ screen was something preventing users from completing majority of tasks. We thus decided to pay our attention to solely the file upload system in the first place.
The app was more likely to crash rather than providing some error codes at the very early stage of development. Therefore, we had to focus on not allowing the user to make mistakes that would have lead the program to crash.
I have reverted the sequence of some of the screens to mitigate the risks for errors in the user’s flow. The app would first ask to specify the file format before users would proceed to the upload form. This also was going to bring the users attention to using correct files at an early stage before they invested their time going in the wrong direction. Also, to simplify the process, I have suggested a multiple file upload and using ‘drag & drop’ system, so that the user doesn't have to select individually each file one by one.
Brand Guidelines
A set of Brand Guidelines was created in line with the Informative and Friendly Tone of Voice of the software.
Due to the pressing deadline, we decided to launch the MVP version of the app while conducting user testing sessions alongside. The app is currently in development, and further testing sessions are due.
User Testing
Please rate on a scale 1 to 5, where 1 = not at all and 5 = very intuitive, overall, how intuitive did you find the app?
Please rate on a scale 1 to 5, where 1 = not at all and 5 = to a very large extent, to what extent you were comfortable to navigate in the app?
Please rate on a scale 1 to 5, where 1 = not at all and 5 = very useful, how useful did you find the app?
Please rate on a scale 1 to 5, where 1 = not at all and 5 = to a very large extent, to what extent you would be interested in using the finalised software in your research?
I didn’t want to entirely re-design the existing interface, because the challenge was to stay within the current aesthetics but focus on delivering the lean design solutions. As mentioned previously, the Klarify app ticks most of the boxes, and my intention was to make that experience even more functional and less effortful.
Users’ Feedback
• The ‘inclusion of data for PCA analysis’ should be on the same page as the plot, rather than go back 2 steps
• The next arrows' color is hard to distinguish from the rest of the graphics
• Basic indication of past-options-chosen on later tabs is needed. Because of the linear nature it's not practical to go back and check things
• A visual representation of the file contents after they're loaded, as a validation step, would be helpful
• When generating the PCA analysis, more descriptions might help. i.e., what exactly are the differences between the two plots
MVP
Multiple quality control features within the application were added, ensuring maximising the efficiency and clarity of each screen.
Iterations
Taken in consideration feedback from the testing sessions we came up with few iterations that would allow the user to adjust the PCA settings without having to go back few steps. The app is still following a linear process but enables quick adjustments at any stage of the analysis.
Reflections
Working on such a specific technical project is outstandingly inspiring but also cognitively quite challenging. It took me a while to understand the terminology and the specifics of the antibody development to be able to comprehend what the app is supposed to achieve. I often analyse and synthesise the things confidently, but this time the subject was so specific and scientifically advanced to grasp in such a short period of time. I decided to focus on only the functionality of each task rather than on trying to understand every single aspect of the molecule separation process. Given the time constraint, I realised that I didn’t have to understand everything, as long as I stayed in constant communication with the Developer and the Scientific Consultant. Each new idea was consulted and verified against the biochemical accuracy to make sure that this is still in line with the specifics of the process.
Constrains & Functionality
App was launched as MVP, but the initial user testing revealed a few features requiring important adjustments. There is a clear need for customisable settings and possibility for quick adjustments for the plots among others to allow for efficient workability of the app.
