it began with crowdsourcing ...
Concept
OpenCabinet is a tool for the public to find interactions between the medicine that they and their family are taking using data directly from the FDA.
Approach
Excella Consulting followed an agile development framework to build OpenCabinet in an iterative, incremental manner. The cross-functional team, comprised of analysts, designers, and developers, began with Sprint 0, followed by two-day sprints. The team met for a daily stand-up and ended with a quick review and retrospective.
The team consisted of the following:
- Product Manager
- Technical Architect
- User Researcher/Usability Tester
- Writer/Content Designer
- Visual Designer
- Front-End Web Developers
- Back-End Web Developers
- DevOps Engineer
- Business Analyst
The self-organized team not only fulfilled their individual roles in the design and development process, but also helped where needed to deliver a quality product. The Product Manager led the effort with a focus on the value delivered by the final product, enabling the team to respond quickly to changing priorities and address feedback from usability testing. Utilizing GitHub issues, the team created and groomed a backlog, discussed design decisions, and tracked bugs.
Sprint 0
First, the team used an internal Slack channel to crowdsource ideas for the application using OpenFDA's Label API. Then, the team reviewed the suggestions and discussed the feasibility of delivering a product in the given timeframe. Weighing both the design and development perspectives, the team converged on "my medicine cabinet" to allow customers to view all of their family's medications in one place and understand the risks and side effects.
During Sprint 0, the team accomplished four objectives:
- Explored users’ needs and reactions
- Determined the application's value
- Decided what technologies to use
- Established the development environment
Needs and Reactions
The User Researcher interviewed potential users to understand their needs. This research unveiled that users’ primary goal was to determine medical interactions, which caused the Product Manager to modify the initial concept to focus on this feature. The Content Designer created Personas to represent different user types, and included one in the Short-Form Creative Brief, which was read aloud each morning in stand-up. These tools informed the design and features included in the Minimum Viable Product (MVP).
Application's Value
The Business Analyst performed a Competitive Analysis, which revealed that many applications show medical interactions. The team decided they could differentiate themselves by designing and building an application that was simple, easy to use, and incorporated a pleasant user experience. A roadmap for future enhancements, indicated in the Product Tree, will further distinguish OpenCabinet from the current marketplace.
Technologies
The Technical Architect, Front-End, and Back-End Developers collaborated, researched, and evaluated tools to determine the best technologies to develop the prototype. With a focus on open source, rapid prototyping, and code quality, the team chose Ruby on Rails as the application framework.
Development Environment
With the core technology agreed upon, the DevOps Engineer set up a development environment leveraging Docker, Vagrant and Chef. By virtualizing the operating system and providing a living set of installation instructions, team members quickly got their environments up in a consistent manner with a prescribed set of required infrastructure. Combined with GitHub’s version control, the team set the base for intuitive versioning and consistent baselines for development. The team built a continuous integration and delivery pipeline to deploy a skeleton Rails application, which was deployed onto the PaaS provider, Heroku, to allow for scalability. Through the use of Travis, the chosen continuous integration server, code was continuously deployed after passing a series of quality assurance checks.
Against every pull request and push to the master branch, Travis automatically ran:
- RSpec for unit and integration tests
- Cucumber/Capybara for automated acceptance tests
- Teaspoon/Mocha for testing JavaScript
- Rubocop for static code analysis
- Brakeman/Code Climate for security static analysis
- Code Climate for code quality metrics
- SauceLabs for multiple browser testing
Travis was also tightly integrated with GitHub. Utilizing Travis, code reviewers assessed the status of pull request tests to ensure that along with a visual inspection of the code, all tests also passed. These tests and code reviews were incorporated into the team's Definition of Done to demonstrate that functional code was being deployed to production and that it provided added value to the product.
The final integration points secured the application and brought visibility to the health of the application. TLS certificates were acquired and set up to ensure user security. Slack, which served as the team’s collaboration forum, was configured to automatically notify the team of changes to the repository, and denoted key checkpoints in the continuous integration process. The GitHub repository housed Badges, which provided visibility to the code’s test coverage, quality, and build status. Monitoring tools, New Relic, Log Entries, Google Analytics, and Air Brake, captured and alerted key metrics and issues with the system.
The Front-End Web Developers established a lightweight framework that supported OpenCabinet's design patterns and Style Guide, and implemented tools that created structure, but were flexible to meet mobile-responsive design needs.
- For presentation, Sass, Bourbon, and Neat were used to lay the foundation
- For interaction, T3 was used as the JavaScript framework, and Teaspoon/Mocha was used for testing JavaScript code
- For post processing, SauceLabs ran acceptance tests against various browsers and AutoPrefixer ensured that vendor prefixes were added to CSS to do the same
- For usability testing, Flip implemented feature toggling to support A/B testing
Sprint 1 + 2
Design
Sprint 1 resulted in two artifacts created by the Visual Designer:
- A Style Guide ensuring visual consistency by providing guidance on how to use typography, color, and address visual elements.
- Initial prototype mock-ups for two different layouts. During usability testing, users unanimously preferred the “cabinet” option. This design is represented in the desktop and mobile versions of the final prototype.
During Sprint 2, user feedback was incorporated into a second version of mock-ups. The Usability Tester performed additional usability tests, which revealed that certain key elements (e.g. navigation and search) were not well received. The team created issues in GitHub addressing these pain points. The iterative development approach allowed developers to easily make changes to the application, even when subsequent rounds of usability testing demanded additional design changes.
Development
During Sprints 1 and 2, the development team developed the foundation of the application. Following a strategy of short-lived branches and continuous integration of small features into the master branch, the team began initial implementation of the API integrations. Caching was implemeted in order to keep API requests performant and limit requests. This set the framework to get features out quickly for usability testing when the designs were complete, which ultimately allowed for constant feedback and improvements of the product.
Sprint 3 + 4
Design
The team completed the MVP in Sprints 3 and 4, and began performing usability testing on a functioning application. With the new interactions in place, the team discovered that users were confused by how medicine selection worked. The interaction visualizations were then re-evaluated and the team created alternative options to test with users through a feature toggle.
By initially conducting usability testing with paper prototypes, the team learned what customers wanted early in the process, before investing time on development. From each round of testing, the Usability Tester discovered key insights that drove the next round of designs and development.
Following these human-centered design techniques ensured that:
- Design was based on an explicit understanding of users, obtained from crowdsourcing and user research.
- Users were involved throughout the design and development process, by allowing them to inform OpenCabinet's purpose, give feedback on design mock-ups, and interact with each version of the application.
- Design was driven and refined by user-centered evaluation through multiple rounds of usability testing.
- The process was iterative, with user feedback driving the next round of design and development activities.
Development
By using the Definition of Done created in Sprint 0, the team prioritized code quality by including unit, integration, and acceptance tests, and performing a code review before it was merged into master. These practices ensured that the application was stable for usability testing and allowed for constant refactoring and improvement of the code base without the fear of breaking core functionality. Even in a dynamic and fast-paced environment, the development team reacted to user feedback and implemented feature toggles, which allowed for re-mixing various views of the data to support further usability testing.
... and ended with "Ship It"