Note: This work is public and open-source, but some details about the process have been omitted for confidentiality.
The Centers for Medicaid and Medicare (CMS) maintain four FHIR APIs that allow providers, payers, and patients to securely access interoperable healthcare claims data: AB2D, BCDA, DPC, and Blue Button.
Our CMS office's overarching goal was to increase the number of beneficiaries served. My team's specific objective under this goal was to identify barriers to adoption and boost customer engagement, both for the APIs and for the relatively new FHIR standard.
I led strategy for this effort and contributed to research, design, and front end development. I worked closely with a talented team of content strategists, product managers, and developers.
User journey map across all Bulk FHIR APIs, synthesizing pain points and opportunities identified in user interviews.
3 out of 5 users interviewed learned about AB2D "coincidentally" or "almost by chance" from a chain email or newsletter that went around their office.
I recommended that we apply research findings to improve the public marketing website and written technical documentation for a single API (AB2D), then extend this effort to other APIs. This strategy to standardize emphasized joint research efforts, a repeatable approach, and pre-built web templates that could be used across all four APIs.
A high-level snapshot of information architecture across similar Dev-X websites reveals industry standards and Diataxis principles.
Card sort exercise
Web analytics sample
We spent several sprints mocking up and testing key user flows and improved documentation for a single website: ab2d.cms.gov. We could extend these learnings and to other API websites down the road to save time and to reinforce standardized practices.
Crucially, we kept in close contact with Product Managers and stakeholders from other API teams throughout prototyping. This ensured that designs were universalized to accomodate each API's unique features and user needs.
In testing, the majority of users sorted 34 out of 36 task flows onto the same category, which represented a webpage. This validated the robustness and accuracy of the new information architecture.
Results of testing for key task flows shows agreement among the majority of users.
Approved content and mock-ups were implemented in a staging environment on a page-by-page basis, allowing for simultaneous, agile development alongside design.
We used Markdown and TypeScript to create intuitive code components that extended USWDS within guardrails, allowing non-technical teammates to easily contribute code. This was heavily influenced by GOV.UK's Govspeak.
Design for the process list component
Code for the process list component
After all pages had been implemented and user-tested, the full website was publicly launched. See the GitHub repository.
Since information architecture, layouts, and front-end templates were already built and validated by users, we were able to skip the design stage altogether for the remaining API websites. New content was implemeted directly in staging, without compromising on accessibility or user experience.
We built the following sites in weeks instead of months, then days instead of weeks. See the BCDA GitHub repository and the Blue Button GitHub repository.
Read the Case Study.