The goal of this project was to replace McKesson's existing medication reconciliation product which, at the time, was an integrated part of a physician portal. The existing version was very difficult for practitioners to use and was often ignored in favor of paper-based reconciliation techniques.
Initially, a project workshop was held to familiarize team members with the domain, the practitioners, and the goals of medication reconciliation. An overview addressing the existing product and competitors, as well as the vision for the new product, was conducted. A UX workshop was also conducted at this time to discuss how the design would be "run", including an overview of the various design tasks and how team members would be involved at each stage of the process.
Due to the complexity of the domain, time was allocated at the beginning of the project for a longer than typical sprint 0. Design activities began with analysis of the existing and competitive products to understand the problems users were having and to explore features that would be useful in the new product. This led to a series of interaction and visual design concepts that addressed the immediate design problems and brought to light possible innovations to streamline the medication reconciliation task.
My goal was to involve users as early as possible in the design of this product, so once the initial concept designs were at an appropriate place a series of iterative design and formative usability testing sessions began. Each design iteration - lasting a week to a week and a half - included these activities:
In all, six design and test iterations were performed. The design moved from being very conceptual early on to more concrete and "real" as iterations proceeded. I also noticed that as the design became more concrete the testing participants spoke less about the design itself and more about the goals and "business" of medication reconciliation. By the point I felt the core interaction and visual design was solid, and so moved into a detail design phase to refine and document the design ( mr-ordering-ui-spec.pdf, 729 KB). Around this time I also conducted a summative usability test to gather data about, and address, any remaining design issues.
Following sprint 0 activities, the design work proceeded in a manner more typical to an agile project: The core product UI that had been documented up to that point was divided into logical pieces so it could be addressed during engineering sprints, design issues were addressed as they occurred, and new, non-core, features were designed, reviewed and documented for future sprints.