Abstract

I wish that every piece of work I did had beautiful designs that are published quickly, bug free, and seen by millions (doesn’t every designer?), but that’s not always the case. A lot of the work that I do best is thinking about existing structures, and making them work better, regardless of their UI output. This is a prime example of just such UX architecture, where my team and I rebuilt our backend to be better structured for ALL of our users, and scaled as needed based o na user’s role within an organization. I created a solution that solved the problem gracefully with minimal new UI impact to the user, and had positive cascading effects for teams of all sizes.

Background

Feel free to jump down to The Problem if you’re already familiar with Dina.

Dina was originally structured around single Post-Acute Care (PAC) offices operating independently of one another. Through onboarding larger clients, interviewing our users and clients alike, we realized that at scale there was a very real need to manage more than one office at a given time. Often, two or more locations might exist for a single health system, requiring employees to manage patients at both addresses.

The experience I inherited was structured to let a “switch” between locations, acting as an employee/user of each individual location. This was done through a cumbersome administrative panel which was originally intended for the Dina internal team to be able to monitor and support our clients. While this interface had merit for users who physically moved between offices throughout the day or between shifts (EG: a case worker temporarily assigned to a short-staffed office), it was confusing and burdensome to administrative users attempting to manage a large pool of patients from a singular location (a central headquarters).

Problem

“Switching organizations” disrupted how users sitting in a central office thought, and approached their daily work. A request directly from one of our primary customers was “to be able to switch between organizations more easily.”  By exposing this switch org administrative tool we had introduced a convoluted step in these users’ daily workflow, which in turn creating cascading issues with improperly sent/received referrals, creating errant data and making scaling our product to large organizations difficult at best.

 Approach

In order to better understand the need, I had to do some field work. I organized a research excursion to our primary markets, and spoke with users and prospects across our Philadelphia and New Jersey market. These generative interviews were intended to elicit reactions to concepts, and to learn more about the challenges facing these coordinators and their administrative teams. By engaging our users in person, I was able to set our non-tech-savvy users at ease, and provide an inviting environment to gather feedback.

This didn’t sit right

As I created some of these ideas, they did not feel right. They felt symptomatic of a larger issue. I performed discovery type interviews with a dozen or so people in the industry, focused on the challenge of why these users might need to switch between offices.

Implementation

Administrators needed the ability to define which offices acted as “headquarters.” That is to say, which offices were the Central Intake offices, and which locations did they manage?

I specced out lightweight UI updates needed to allow administrators to set up their Central Intake offices. Through my research and tight-knit collaborative team effort in creating a structure that modified the original MVP, the entire update was able to be implemented in tactically and in only a few short sprints. Structurally, this approach required major back-end changes, and huge customer support efforts to to help our existing users through this transition.

An employee who works at the Central Intake office can then sign in directly as a CM user, and manage all their patients at a higher, oversight-style level:

Results

At the time of writing this, our partners included health systems, large hospitals, and smaller PAC providers. To take the CI model to the next logical step would include the ability to allow these Central Intake offices to be managed based on region or service area,  expanding the concept of visibility based on an area, rather than a specific location of a single node.

To read more about the Central Intake model and how it benefits health-systems, see the article authored on the subject.