Lead product designer
2024
Reduce OPex by Linking evidence to chronic conditions
Cityblock Health is building a scalable solution to address the root causes of health for underserved, urban populations from social to medical care.
Team:
- Lead product designer (me)
- Product manager
- Sr. staff engineer
- Sr. software engineer
Most of America's $4.5 trillion healthcare spending goes toward managing chronic diseases, but nearly 90% of people with early-stage conditions like prediabetes don't know they have them. Cityblock serves low-income Medicaid populations who often can't access regular healthcare and end up in expensive emergency rooms when problems become serious—but early diagnosis dramatically improves their lives, with cancer patients caught early having 96% survival rates versus only 10% when caught late.
Unlike traditional healthcare that gets paid per procedure, Cityblock operates on "value-based contracts" where they receive a fixed amount per member and keep the savings when they prevent expensive hospitalizations—creating a business model where keeping members healthy and alive directly drives profits.
This alignment means Cityblock invests heavily in finding diseases early: preventing one diabetes case saves the company $4,000+ annually while helping members avoid a lifetime of complications, and each cancer caught early can save $100,000+ in treatment costs while potentially saving the member's life. Cityblock uses community health workers, home visits, and predictive data to find health problems before they become life-threatening crises—making early diagnosis both their core competitive advantage and the key to dramatically improving members' health outcomes and quality of life.
Healthcare providers spend valuable time manually hunting through scattered medical records—searching through progress notes, lab results, medication lists, and other documentation—to piece together potential diagnosis opportunities before patient visits, creating a time-consuming and frustrating workflow that delays care and reduces the time available for actual patient interaction.
Automatically surface and prioritize relevant evidence for providers before patient visits, eliminating manual record searching and enabling providers to focus their time on patient care rather than data hunting.
* Decrease in provider selecting "No information found" or "Not enough time"
* Increase address rate
User research
I joined this scrum team right before the vendor evaluations. This meant I need to jump in and understand the users' perspective quickly to be able to advocate for certain functionality during the vendor evaluations.
I interviewed and shadowed 9 care team members who scheduled appointments with members during their day-to-day work: behavioral health providers, outreach specialists, and community health partners.
Problems discovered during research
- Inefficient search flow: Users must restart their search if no availability is found for a selected modality type.
- Limited availability: Some modalities have no openings for up to 3 months.
- Manual overrides: Schedulers often book outside provider availability to prioritize preferred providers.
- Calendar gaps: Internal Cityblock meetings aren’t reflected in Skedulo, requiring manual checks in Google Calendar.
- No drive time support: Skedulo doesn’t account for travel time, leading dispatchers to work through breaks.
Final designs
A seamless scheduling flow in Commons that allows our care team members to schedule appointments based on accurate time slot availability, modality, and appointment types, within one singular system.
With our new scheduling vendor, Axle, we can create our own user experience on top of their technology. That means we created a seamless scheduling experience that keeps our users in our internal care management tool, Commons.
In this project, I tackled both business problems and product/design problems:
1. Reduce booking errors and maximize appointment availability
2. Design pattern and design system improvements
1. Reduce booking errors and maximize appointment availability
To reduce booking errors and maximize appointment availability, I improved 2 critical areas of the scheduling flow: the booking grid and the modality and appointment selection.
Booking grid
The booking grid is used to select appointment slots while the scheduler is actively on the phone with a member. This means the workflow must be fast, intuitive, and interruption-proof—allowing the user to navigate seamlessly while both asking and answering questions in real time.
Before
With the Skedulo implementation, our users would get redirected to the Skedulo booking grid from Commons. This created a disjointed experience filled with booking errors, forced workarounds, and lack of analytics tracking. The Skedulo experience was poor and we couldn't fix or make improvements to this experience.
Originally, errors were created on the Skedulo booking grid due to it's limited ability to show availability for multiple modalities. Skedulo also allowed for users to do forced workarounds which allowed them to schedule appointment with providers outside of their availability window.
After
To reduce booking errors, the new booking grid in Commons can show all availability regardless of modality (which can be filtered) and does not allow users a way to create forced workarounds. Overall, the new booking grid is simple but allows our users to focus on scheduling member appointments.
The booking grid also encourages viewing all appointment available through the modality filter chips. The filter chips allow users to easily filter through different modality types to find open availability, while reducing booking errors by showing which modality is not availability for the appointment type or date/time.
Modality and appointment selection
To view available appointments, a user has to select an appointment type and modalities for the booking grid to properly filter in a reasonable amount of time. This is the starting point for the scheduling flow.
Before
For users to search for an appointment type, users had to select the modality and appointment type before going to the booking grid. This was not ideal and create issues for our users who are usually on the phone with our members while going through this flow.
By selecting a modality this early on, the user does not know if there are any appointment availability until they go to the Skedulo booking grid. Unfortunately, once they get to the booking grid and realize that there are no appointments available for when the member wants, they will have to go back to this screen and restart the search.
After
Now, users can select multiple modalities at the start. From research, our members can be flexible with modality. This allows the user to find the best time, regardless of modality, for the member when scheduling an appointment.
By allowing users to select multiple modalities, users can see all available time slots to select from and provider members the best options instantly when scheduling on the phone. Some members are open to different modalities that fit their schedule.
2. Design pattern and design system improvements
This project is an important workflow in Commons for our users, as it is incredibly important we nail scheduling appointments for our members and appropriately managing our providers' time. Therefore, this project had the capability to set necessary changes and improvements in Commons from design system additions to cementing preferred design patterns related to modals vs pages.
These design decisions did not happen in a silo. They were discussed in detail in Design Studio with the design team and in weekly pairing sessions with the product manager and engineers. We had to discuss and determine consistency, feasibility, and preference.
Typically in Commons, we've had a pattern of overusing modals. Throughout the product, you'll find buttons leading to modals and modals on top of modals. While there's a time and place for a modal, we've far surpassed that. This is something the team is looking to make improvements on.
My first iteration of scheduling was through a... you guessed it right, a modal. It was just instinctual to start with one. But as a I got through sketches and wireframes, I decided to explore a page approach. From there, I mocked up a page experience and discussed both options with my engineers. They were ecstatic about the page approach as our modals are technically more complex for certain interactions. I brought the designs to Design Studio and the designers also felt like this was the right direction for the product to move towards.
In Commons, we have tags. We have tags everywhere! For statuses, labels, responses, and more. We also have other components that look similar to tags. We also have tags modified to be a filter chip. This leads to a confusing experience for users. Some tags are interactive while some aren't.
I spoke with the Design System Guild and we decided we should find a way to differentiate filter chips from tags.
This coordination span across multiple meetings between Design Studios and the Guild to get alignment across the entire design team which led to a brand new component that my scrum team added to the Design System.
Results
We launched in June 2024. After one month of tracking metrics and monitoring feedback channels, scheduling operations did not skip a beat. Not even on day 1. Our biggest achievement was that we overhauled a large workflow and no one blinked. Users continued to schedule appointments and the business continued without a hitch. This was the biggest accomplishment for the team.
As for our success metrics, we decreased booking errors by 42%. To continue to improve this metric, we started to work with the operations and clinical teams to clean up the naming and number of appointment type available.
Technical decisions discovered during design and development
During design and development, our engineers are discovering Axle's capabilities and lack of capabilities. These discoveries lead to changes to the initial ideal designs. Luckily, there were no curve balls thrown at us that we couldn't elegantly solve.
In the ideal state, users could select the Cityblock team member on the booking grid. So for example, if I wanted to schedule with Provider A but they didn't have availability, I could choose another provider from a dropdown menu.
Unfortunately, we couldn't continuously call to Axle to make this change on the booking grid. We needed to select a team member from the start of scheduling an appointment.
Next steps
Our next goal with scheduling is to improve the kept rate and decrease no show/cancellation rates to increase the number of members being seen by a Cityblock team member.
Learnings
We had to be ruthless in prioritization and we had to constantly ask the question, "is this necessary for launch?" This meant that I needed to design for MVP with a vision in mind. How would this scale in the next few months once we went back to optimize and add more features?
