Case Study
Create a reporting tool for healthcare administrators to analyze data
Product/Development Team
3 Months
Figma
Ayva is a medical software that optimizes communication and preparation for patients going through various medical processes. Tracking and managing these processes creates a lot of data so there were requests for a tool that would be able to track and analyze different levels of data. By using data collected from patients going through the Ayva system we wanted to provide a tool for organizations to be able to track their own provider and patient's interactions and success/compliance numbers through various organizational levels.
Healthcare administrations and facilities that are partnered with Ayva did not have an immediate tool to manage track, and analyze the data produced by different healthcare facilities at different levels. This responsibility was often left to Ayva's Development team which ended up being very time consuming and added a redundant layer of work/communication since all parties would have to go back and forth to finally produce this data.
To create a robust and dynamic administrative reporting console that would give healthcare administrations the ability to manage, track, and analyze the data collected from patients from all the different levels of their organization.
The initial research phase involved interviewing and collecting feedback from key stakeholders from both internal and external sources. Both parties provided an abundance of knowledge pulling from their past experiences that utilized similar tools. Following multiple interviews and meetings, my team was able to identify key features and needs that would be key for the creation of a robust reporting console that would succeed the needs of all our clients. Certain highlights and key features identified were things such as the ability to track all the different levels of a healthcare organizations as well as the ability to drill down to the specific details to create reports for analysis and sharing with their peers. The wider goal identified by our internal team would be to provide a tool that would allow our clients to "learn how to fish" when it comes to their organizations data produced by the Ayva system.
The main persona for the reporting console would be those who work at a healthcare organization's administrative levels. We proceeded to gather a wealth of information to better understand this persona such as pain points, immediate needs, and future needs. This helped establish a some basic goals that would lead to creating the initial design parameters that would meet the expectations for what a healthcare administrator would want from a reporting tool. Our main goals were to cater features that would not only help mitigate a lot of those identified paint points but also add in features that would go above and beyond to help with easily reviewing and comparing all levels of a medical organization's patient data.
Our base personae developed was Lynette, a busy healthcare administrator who must manage a lot of moving parts within a healthcare organization. To make sure her organization is operating at a top level she is always experimenting with different tools and processes to make sure her facilities and their respective physicians/case managers are operating at a high quality and efficient level. Providing a tool that would give her the ability to easily manage and track the various facilities data sets and drill down to the root of areas of data that stands out would be key.
We created an initial workflow to establish the basic structure and account for all the necessary functions and levels that would comprise the reporting console as well as a connected reporting dashboard. At the most macro level would be the organization then following down the hierarchy would be the different divisions which are groups of medical facilities based off of geographic location. Then contained in each facility would be the most micro level of the console reporting which would be each facilities specific physician console. Each console would contain overall patient summary data around patient compliance, experience, and enrollment volume.
Once basic wire flows, persona needs, and features were aligned with stakeholders and product team. We created initial designs for the Admin Reporting console. The main goals were to demonstrate/set parameters that addressed the key feature needs identified below.
The whole structure and navigation of the reporting console is predicated on the left rail that contains all the nested layers of healthcare administration in hierarchal fashion. Seen in the images and prototypes below users can quickly switch from the most Macro layer of an administration into a more micro layer such as a facility or physician and add or edit members/facilities to their respective layers.
Reporting console user can easily navigate through the various levels of a healthcare organization using the left rail.
This allows users to quickly shuffle through the various levels of the organizational for quick viewing. This format makes for easier/fluid analysis to drill down and compare patient summary data from the most macro to micro levels of organizational data.
The user needed not only the ability to drill down on healthcare data by different levels of an organization but also by all the numerous specialities and specific time-frame parameters of patient summary data.
Shown here is a multi-functional filtering tool that is utilized right under the header. Allowing the user the ability to filter data by dynamically to fit user needs.
Filters are set within the hover and can be shown and edited as tags for quick and easy editing and toggling of filters.
The last key functionality was to develop a separate reporting section connected to the original dashboard. This is to accommodate personae needs for generating detailed table reports that are conducive for overall analysis and data comparison.
Users will be able to utilize the same filtering functionality in the dashboard but instead to populate different chart views. Here they will be easily able to to drill down and compare different data sets from all levels of a healthcare organization. Users can then easily export this data to a desired format to then be shared throughout their organization for those who do not have access to the dashboard.
Confirmed Assumptions: The overall structure and filtering in the design for both the dashboard and report generator was well received by key stakeholders and client. They felt structure and navigation was a much needed and easier to use from previous tools.
Challenged Assumptions: The initial dynamic filtering in structure was well received but there was quite a few updates on the overall categories in the medical practices being tracked/sorted. There was also a design update to include quick edits to the filters that were less than three clicks. These were addressed in the second iteration by adding filter receipts in the forms of the editable tags in the header lessen the amount of clicks.
Lessons Learned: One big lesson learned was try and to incorporate stakeholder feedback more frequently throughout the design process next time around. There were quite a few large reworks and pivots in the overall design and data points categories since we could not meet with stakeholder as frequently as needed.
Next Steps: The next steps would be further adding on to the base structure created and creating even more insular views of the various data points and widgets selected. This will give future users the ability to select and compare various targeted levels using infographics and patient categories.
