The Autism Learning Engine
One of the first major projects of my career, The Janssen Autism Learning Engine, is a clinical trial outcome tool that validates the efficiency of chemical compounds in the treatment of symptoms of children with autism. We designed the system with a team of neuroscientists that were the main source of requirements throughout the process. The system used biometric feedback from several sensors, qualitative data that was self reported by caregivers, and then merged them together to provide context and a deeper understanding of progress and episodes.
Because of the sensitive nature of this project, I am bound to omit many aspects of the process. It was a challenging project with many, many dedicated and passionate technologists and designers spending weekends getting the system ready for various stages of trials. Please reach out if you have any questions on that experience!
Proposed Site-Map V1
Based on existing paper forms, on the fact that we needed doctors, patients, and parents to have access, based on legal requirements, and initial interviews with our team of neuroscientists, we developed a gestural site map that would begin to make the project planning and scope easier to digest. The actual complexity of this system grew to enormous proportions once EMR systems, Microsoft HeathVault, biosensors, and many other tools were integrated.
Site Map V2
Further refining the starting point led to separating out some features into more clearly delineated parts of the information architecture. The requirements already began to grow and we started identifying key areas to begin our design explorations.
The journal V1 - A data collection tool
One of the first tools developed was "The Journal", a qualitative data recording tool that parents would use to record multiple type of events from either their point of view or the child's. The final system ended up using biometric sensor data to trigger these event recordings at the right time for parents. V1 was a basic and low-tech approach.
The journal V2 - way too many features
The reaction to a simple design was to immediately add a ton of features that were not validated as necessary. Most requirements during this phase of the process began with "Wouldn't it be cool". We started trying to validate all these features against our research and with various teams, but decided to throw everything in there to prove the point that we need to be more selective and have more scientific reasons why we need to add features. The overall reaction was that it's too busy, with which our design team concurred.
The journal V3 - Scaling back
With the business team now on the same page as far as removing unnecessary features, we were able to design a much more elegant solution that still maintained a certain level of complexity without overwhelming users.
The journal v4 - incorporating all requirements
Down the line, we refined many aspects of what we were actually tracking. Inevitably, a few more requirements came down to us, but the original design was able to accommodate them. We added every feature with avoiding information overload in mind, designing for dynamic repeatable actions, and for customizing the experience to different types of autism and symptoms.