Background

When I joined Omada, my first role was to lead the design of our Care Platform - the tool our care providers and coaches use to deliver care to our members.

The care platform needed an overhaul. It was originally built as a tool for a single coach supporting members through a 16 week, fixed diabetes prevention program. It wasn’t designed for multi-person care teams, multiple conditions being treated, or to accommodate the volume and type of information now being stored in it. It had had features bolted on to it quickly over time, but this now had led to a decrease in usability of the overall platform.

Over the course of my first year at Omada, I worked on a small team to define the future of the care platform and illustrate how we could scale to it accommodate Omada’s changing needs and return it to being a fast, usable tool our care team could use to deliver high quality, personalized care.

Approach

1. Define the problem

Identify what problems we’re looking to solve and what success looks like

2. Research

Understand the user needs, business needs, and any other relevant context

3. Design strategy

Define our approach to making the platform more scalable and usable

4. Design + iterate

Begin executing on specific projects as we iteratively progress toward the vision

Define the problem

Omada’s program is evolving

The Omada Care Platform was originally designed to enable coaches to support participants in a 16 week Diabetes Prevention Program. Now, however, Omada offers 5 conditions with multi-person care teams, and only plans to continue to expand their capabilities.

Specifically, I’ve been working closely with our company’s leadership to envision a digital clinic that can support whole person, multi-condition care, with care teams empowered by data science to provide excellent care at scale.

To do this, Omada will need larger care teams with more varied expertise, and a tool that lets these care teams effectively collaborate together, make care decisions, and ultimately deliver that care to our our members.

But the care platform hasn’t kept up

The Care Platform as it currently exists, however, isn’t up to the task. While it has evolved over the years, it was typically built on in unscalable, ‘bolt it on as fast as possible ways’. At the time, this was the approach that made the most sense for Omada as it was rapidly changing and the Care Platform needed to keep up. At this point, however, so much technical and UX debt has built up that this approach is no longer viable. Below are four of the key areas we identified as major issues in our initial discovery.

Doesn’t support robust care planning

• The care platform cannot functionally accommodate the future Omada is planning. Currently the only action care team members can take is to send a message.

• There is also no scalable design pattern for adding new actions to the system

• In the future, we want them to be able to suggest resources or goals, comment on specific meals logged, reorder lessons, etc.

Can’t support clinical customization

• Many changes to clinical guidance and protocols currently require engineering support or are done in round-about, inefficient ways that increase risk of error.

• In the future, we want to give our clinical team more direct control to rapidly customize and change care team protocols to provide better, more efficient care

Wasn’t designed for multi-Person care teams

• The care platform does not support multiple users. A workaround has allowed limited multi-person care teams to use the tool, but it has significantly hindered usability in many ways.

• Many features intended for one user become useless with 2 or more, such as reminders that can’t specify who the reminder is for.

• No easy way for care team members to collaborate or communicate with one another.

• No way for each care team member to separately communicate with the member

• In the future, we want a tool that is designed with multi-person care teams in mind and supports their collaborative workflows.

Can’t easily scale and is difficult to understand

• There’s no scalable pattern for adding new data and information to the care platform, requiring a custom design solution every time even a single piece of information needs to be added.

• This has also resulted in the information architecture of the tool to be highly unintuitive and inefficient for care team members, resulting in less effective care.

Together, these issues formed the foundational problems we needed to solve:

This was a major undertaking, and we knew we weren’t going to solve all these problems at once. Instead, our plan was to learn and explore enough to come up an informed recommendation and strategy for a series of projects over the next few years to evolve the care platform in the direction we wanted.

To do this, we needed to assess what it would take, at a high level, to address each of these issues, then with a deep enough understanding in mind, propose a prioritized series of projects aimed at addressing the most pressing needs.

Research

To assess the best high level ways to approach these issues, we needed a clearer picture of how our care team members and operational staff used the platform. We conducted extensive user research with members of our care team and our clinical staff. Here’s what we learned:

Members of the care team work in cyclical task completion

Task selection: Prioritize what to do next - often with guidance or directives from the care operations and clinical team.

Information gathering: Gather the context needed in order to complete the selected task.

Action: Take the appropriate action before moving on to the next task.

Task selection

Information gathering

Action

Identifying mental models for information architecture

We also conducted a card sorting exercise with members of the care team to understand their mental model of member information. In aggregate, we deduced eight types of information frequently cited by our care team:

• Basic member information: Non clinical info like dietary restrictions, etc

• Clinical information: Medications, labs, PCP visits, etc

• Data & measurements over time: Weight, BP, BG, Sleep, Engagement, lab results, etc. 

• Activity: Documentation of actions taken by our care team and member

• Care plan & management: Ability to see and modify what a member is working on

• Task management: Personal, care team, system tasks, both required and suggested

• Care team free text areas: Notepad, tags, etc

• Account information: Program info, device, info, etc
  

Design strategy

From here, we began a broad set of concept generation with our key opportunity areas in mind.

Normally when doing design explorations, you want to isolate as many variables as possible so you can compare different choices at a single decision point. That was very difficult to do in this case given the vast scope of the exploration. All the decision points were too interrelated - Every time one thing changes, it opened up and closed off wide arrays of other options so is impossible to isolate any one decision.

Instead, we generated a series of ‘whole concepts’ - combining everything we’ve learned into a rough, best guess of how everything might fit together. The goal is not to be correct, but to have something we can then use to stress test against the key moments we want to enable and get feedback on from members of the care team. For example, below you can see one such concept being stress tested against the moment a care team member welcomes a new member to the program.

In this example above, for instance, we were able to evaluate:

1. A new ‘dashboard concept for task selection

2. What kind of information and a context a coach would need to get up to speed on a new member and see how streamlined that information was.

3. The overall information architecture including new care plan functionality and the high level journey involved

4. A more scalable pattern for actions

5. A model for task completion consolidating several existing systems with overlapping utility

Using this method we were able to stress test and iterate on a few different concepts to get a sense of which approaches would be most effective. We were able to use this to eliminate some concepts and hone others in an iterative fashion until we had a relatively clear sense of directionally what we thought would be needed to address most of the fundamental issues.

We didn’t come up with solutions to all the problems - we just did enough explorations to have a directional sense of how we thought they would be solved in order to inform our planning.

Out of this work, I partnered with our PM to create a multi-year project plan. We prioritized the plan with three levels in mind:

1. Functional requirements: Projects that are non-negotiably needed for the business to continue working

2. Effect multipliers: Projects that will make future projects more efficient or easier

3. Efficiency and effectiveness optimizations: Projects that improve the efficiency and effectiveness of the care teams, prioritized by impact and cost.

Outcomes

Since setting this strategy, I directly worked on and launched 2 of these projects before beginning my new role managing the design team. Now another designer has taken the lead and is working on the third. Since the launch of the first two, we’ve seen a reduction in missed SLA’s from our care team, and large increases in efficiency of core workflows.

Thank you for reading! Please reach out if you’d like to talk.