Healthy Mothers, Healthy Babies Coalition of Georgia (HMHBGA) is a coalition of organizations and individuals (partners) operating programs to serve mothers and babies throughout Georgia.
Our team did work in two phases. Phase 1 consisted of a database, a web-based app to query the database, and a web-based add/edit/delete app to update the database. The Maternal & Infant (M&I) Map was a web-based query app which provided decision support for advocates seeking better recognition and additional funding for programs, and supported browsing and searching programs on a map. In Phase 1, only the sole administrator was authorized to use the app to add or change information in the database. This required the administrator to manually gather information from providers and enter the data.
For Phase 2, I designed a web-based app to allow remote partners to enter program information directly into the app. The key feature of Phase 2 was to implement a workflow so that, prior to information being available for inquiry or viewing, the administrator would review, edit as necessary, and approve the information.
Planning & Communication
We wrote the Phase 1 software as an open-source contribution and stored it on GitHub, in hopes that future project teams would further enhance the software for HMHB, and also recognizing that this code base might be useable by other organizations. Problem: Code can be easily stored on GitHub, but how to encapsulate 15 weeks of design concepts in a way that future project teams could understand our expected direction of Phase 2 - or how the current Phase 1 could be implemented?
My Solution: I wrote one document to describe Phase 1 (as implemented), and a separate document to described the design of Phase 2 (as approved by HMHB management). I thought this would be easier for future teams to understand, whether implementing or enhancing Phase 1, or implementing Phase 2. Each document is published on the GitHub wiki for the project. Click on the thumbnail below to see the entire document for the existing Phase 1.
Following several early discussions, I wanted to confirm our shared understanding of scope, specifically the roles of key stakeholders and the scenarios we should support. To support this discussion, I drafted a “Stakeholders and Scenarios” document, which the project team reviewed with the HMHB administrator to confirm that we had sufficient shared understanding and expectations. Click on the thumbnail below to see the entire Stakeholders and Scenarios document.
The HMHB Executive Director told us that the partners distributed throughout Georgia tend to have small staffs which are focused on delivering health services, and she did not want us to contact them directly to gather their input on Phase 2 workflow or user interactions. Problem: How could we learn about partners, estimate volumes of programs, and how they geographically define their service area?
My Solution: I designed a survey to gather information, which the Executive Director agreed to forward to partners. The results provided us enough information to estimate storage and plan logical database structure required for Phase 1.Click on the thumbnail below to link to the survey.
I like to start design with a conceptual workflow, to further verify the responsibilities of each stakeholder and the scope of the system (following the "Stakeholders and Scenarios" document discussed above).
Shown below is a pencil sketch, created during a discussion among the key users and Phase 1 developers. This diagram covers the steps to add a new program or (provider) organization.
Next, I created wireframes and design mockups. The pencil sketch wireframe (left) was reviewed with key users and Phase 1 developers and generated good discussion, including the team decision to follow Google Material Design standards.
Problem: I wasn’t confident I could freehand sketch a wireframe that appeared compliant with Material Design.
My Solution: I used Material Design templates in Sketch to create the next version of design mockups (right), and also incorporated realistic data to better engage the users. I included the design mockups in a document, annotated with some initial thoughts on interactions. Download the design mockup document.
Prototyping and User Evaluation
I created several iterations of medium-fidelity clickable design prototypes, and evaluated each with the HMHB Executive Director. The prototype was constructed in Axure using screen images created in Sketch; I chose Axure rather than InVision in order to animate some Material Design aspects (such as floating action buttons and toasts). Below is a narrated video walkthrough of the prototype, or click here to access and run the prototype from AxShare.
Planning & Communication
Following the completion and signoff of the design, I wrote a "Letter to the next project team", to handoff to a future project team tasked with implementation of Phase 2. (This acts as a “bookend” to the document described earlier, introducing the Phase 1 as-implemented system.) Click on the thumbnail below to see the entire "Next Steps" document, which is published on GitHub.
Results and Retrospective
What was delivered: I researched, designed, and evaluated a new workflow and a UX design to support that workflow. I also wrote an introduction to the project and a "Letter to the next project team". These were published on GitHub, along with the open-source software developed by my teammates for “Phase 1”. In Phase 1, which went live in December 2016, all information was to be entered by a central administrator and did not incorporate the review and approval functions.
What I learned as a designer: From a design perspective, I learned much from Google’s Material Design, especially how a “call to action” button can clarify the user’s path to the primary outcome. I also became more comfortable with designing in Sketch while following standards (especially using symbols in a template).
From a process perspective, I learned that sometimes real-world projects cannot follow a textbook approach. I would have preferred to directly involve people working at partner organizations (who would be entering program information into the system), but that wasn’t feasible. So I created a survey to gather information from partners, and used that to supplement information from interviewing the administrator. User evaluations were completed by the administrator.