Our first step in building an effective application was identifying the proper User-Centered Design (UCD) approaches. We involved potential users in as many steps as possible from the brainstorming phase to the prototype.
Our Product Owner (PO) is the lean agile leader of the multidisciplinary team that produced this prototype, and represents our customer/industry surrogate, the accountable team leader with the vision of the solution and ability to ensure a timely release of a quality deliverable[(a)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx)[(b)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx). The PO led a self-organizing agile team empowered to define the product’s requirements, create and test the usability of the proposed design, develop and test the application, and create and run test cases to validate the solution against requirements.
Working in a time boxed and iterative cycle[(h)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx), we sought input from stakeholders and built the application using a test driven development (TDD) technique. This produced a high quality, working slice of the application that was subjected to usability testing and feedback. The results were fed back into the iterative process for further refinement.
UCD is the process of focusing on the end users’ perceptions and habits to map the web application experience, rather than the vision of a single creative source. This allowed the end user to steer all aspects of the development process – not just the interface or technologies. Our agile team used a process of participatory design alongside six specific types of UCD techniques (Personas, User Interviews, Workflow Determination, User Testing, Prototyping, and Accessibility Testing)[(d)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx).
We created user profiles by researching demographics, and posed a character based on those findings. We gave them relatable biographies and a humanized situation to comprehend their potential interaction with the app. Personas determined our interviewees: pharmacists, patients in pharmacy lines, journalists, and doctors.
We started with broad questions like “What do you expect from this application [that can query a drug database]?” These answers helped us understand the motives of potential users[(c)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx). The prototype interviews gave specific insight for the need to determine maximum non-toxic dosage of drug ingredients across a combination of prescription drugs. We then mapped our findings with flowcharts that demonstrate the direct way to achieve the user end-goal.
Testing was done with simple wireframe drawings to confirm that the workflows were correct. With the prototype testing, we quickly determined that our users primary interest in the FDA API was the potential ingredient overlaps between commonly prescribed drugs that could create a toxic combination[(g)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx). Tangential ideas were then relegated to a prioritized backlog. We tested usability and refined the functionality through interactive wireframes that allowed users to provide instant feedback on potential workflow inefficiencies.
While the comp was based on the final wireframe, the aesthetic details of the application in UCD were not allowed to detract from the product’s mission, which should be instantly recognizable with visual appeal second. Subsequently, developers received a style guide for the initial development[(e)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx). We tested to ensure that color contrasts, text size, and tabbing orders allowed access to users with color, visual or other impairments, and included a tailored checklist for use during development.
For efficiency, we relied on standard design patterns that users are familiar with in modern web-based applications and responsive web design to improve accessibility across a variety of common mobile Internet devices[(i)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx).
Our developers relied exclusively on open source and free technologies: the front end framework was built with Bootstrap, the SASS preprocessor ensured streamlined styling, the Rails application framework built on Ruby provided the architecture, and this front-end code was developed using the Brackets editor[(f)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx) to reduce development costs while improving the quality and security posture of the prototype.
We did an iteration of user testing with the application on multiple devices[(i)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx). After presenting the prototype in a casual user feedback session involving user walkthroughs, we found that the "Interaction Widget" application workflow needed rethinking. The preliminary wireframes on the wireframing software Axure did not indicate the size of the infographic, presenting issue with locating the interactive search input. To balance the interest-garnering infographic with the search, we minimized the space it used on the page and moved the search nearer to the results. The final portion of the quality check process tested the integrity of the customer-supplied documentation by installing and running the application solely using the installation documentation and instructions[(j)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx) provided to ensure a dependency free deliverable that can be deployed into a fresh environment[(k)](doc/Attachment E Approach Criteria Evidence Pool 1.xlsx).
(a-k) refers to criteria in Attachment E)