Pool 3 http://pool3demo.threewiresys.com/ The Three Wire Team began by reviewing the RFQ, Q&A documents, and OpenFDA website. Upon assessing the requirements, the team decided to use Agile Scrum as their SDLC methodology, “time boxing” the exercise to 36 hours, conducting four sprints, and holding stand ups every hour. Amanda was elected Product Owner for the project, and was charged with product quality and given ultimate responsibility for delivery. A full team was assembled, and representatives from each labor category were included in the Pool 3 development effort.
The team started with attempting to “solve a problem” based on the OpenFDA website and FDA issues in general. The approach for Pool 3 was to attempt to ascertain a problem from the data sets contained within OpenFDA, and to display complex information in a way that was aesthetically appealing. The team pulled various data sets, and began pouring over them. The team drew on their own experiences, and felt that an application that not only showed drug-drug interactions, but also side effects and gave a basic breakout of the drug would be useful. Various team members, their families, friends, and loved ones have been through difficult health experiences. One of the largest issues during some of the more severe incidents was continuity of care, particularly surrounding prescriptions. As such, the idea for the “MedFinder” app, helping patients understand their medications, was developed.
The objective of the application, it was decided, was to provide users with comprehensive information (using OpenFDA) on the medications they are taking, what the medications are for, what other medications they might interact with, and any potential side effects. The team started with user personas. Once again, many of these drew on real world experiences (note: none are actual individuals or experiences, they have all been fabricated to an extent). The team chose user personas of people who had chronic illnesses, and were struggling to understand all of the medications being prescribed. This was contrasted by personas where individuals are relatively healthy, have infrequent doctor’s visits, and are simply trying to maintain their health.
Once personas were created, the team used the human-centered design techniques of defining their audience, using best design practices, and building from user personas and user stories. These were combined with data driven design for the application, attempting to use the information displayed, as well as the needs of the user, to create an easy-to-use and informative application.
With such complex and vital data, and a broad array of potential user demographics, it was felt that the simpler the functionality, the better. With a broad array of users, the landing page and search bar were kept minimalistic. A 508 compliant skin was also develop to aid those with visual impairments.
The application was developed using Visual Studio 2015 sitting on a Linux environment. Jenkins, an open source build and deploy Continuous Integration tool was set up in conjunction with this stack. Docker was used as the containerization. The repository sits in BitBucket. This was all documented so that the set up could be used for any of the three apps.
While the application was developed, test cases were created from the user stories, mock-ups, and personas. Jenkins, an open source build and deploy application, was set up in an attempt to provide Continuous Integration support. The application was frequently deployed, test cases were run, and corrections were made. The team intended to keep the process as iterative as possible, and the feedback loop as short as possible.
Once a prototype version of the application was developed, user testing was conducted. Users were shown the prototype, and asked to search for medications they wanted more information on. The users gave feedback, primarily positive, but also way to refine search result displays. The design team members took this, and worked with the developers to implement it.
During the testing process, it was felt that refining some of the ways the information and interactions were displayed needed improvement. The design and usability team members began working to improve the layout. Once this was completed, user stories were created and the development team implemented the changed, built and deployed for further user and functionality testing.
During a team stand-up, the fact that people visiting the site might not fully understand what the drug is or what it does. With lack of continuity of care, and most drugs prescribed of the generic variety, it is easy for users to forget what the drug they’re taking is meant to do. As such, it was felt that adding information on the drug in some capacity would be helpful. The team broke off, did research, and came back together with a URL on drug information that could be manipulated to match the drug that the user has searched. This was then implemented and tested.
Once testing and review were done, the team took a quick vote to ensure agreement that they felt it was done. Once agreed, the application was given a final review by Amanda, Product Owner, who decided to publish the application in BitBucket.
At the end of application retrospective, the team felt that if they could change one thing about the application, it would be having the ability to somehow pull information about drugs into the application, instead of sending the users off to a third-party link. It was also felt that a more reliable source, such as the National Health Institute or Mayo Clinic, would have been a better source for this information. The team was unable to find ways to manipulate links for either of those site, and furthermore, there was seemingly no API that could easily display drug information.
We found the exercise of time boxing our work so severely (36 hours) to be very educational, we were able to reproduce the dynamics of a longer project must faster, fail faster, learn faster, it was a microcosm of a longer cycle, as a team we felt it made us sharper.