top of page
Practical Support_01.png

DARIA

Practical Support

I redesigned a feature for a system that supports case managers and their patients who need financial and in-kind support for surgery.

CLIENT

DARIA Case Management System

ROLE

UX Researcher

Product Designer
Volunteer 

TIMELINE

4 weeks

DELIVERABLES

Competitive Analysis

High-Fi Prototype 

Task Flows 

User Journey Map 

User Stories

Background

Practical Support is help, both financial and in-kind, that abortion fund nonprofits provide to patients so they can overcome the many logistical, financial, and geographic barriers to accessing an abortion. Funds help patients with expenses ranging from transportation, lodging, childcare, and meals. 


The Practical Support feature in the DARIA case management system enabled abortion funds to track information. However, abortion funds' case managers experienced difficulty with it and rarely used it instead opting for external workarounds. Conducting research and reiterating the Practical Support feature was my first project while working with DARIA. 

PROBLEM

There were several issues experienced by case managers involving redundancy, efficiency of use and a lack of visibility of status. 

Efficiency of use

Case managers at abortion funds rarely use the Practical Support form feature in DARIA, which is a less detailed and nuanced form compared to the digital forms they create, customize, and actively use as workarounds. Information living outside of DARIA caused case managers to worry about security. 

When a patient calls the abortion fund in need of financial and practical support assistance, case managers at multiple funds with whom I spoke do a couple of things: 

 

(1) Submit a request for financial assistance in DARIA. 

(2) Complete a form on a separate touchpoint with a detailed breakdown of the patients' practical support needs instead of using the Practical Support feature in DARIA. 

With all of the details of the abortion assistance needed, case managers would go back into DARIA and include a high level written narrative of support needed for the patient in a section for additional information. They were effectively repeating the same work on two different sections.

Lack of visibility status

Case managers have different responsibilities. Some only do information intake from patients while others process payments. Case managers doing information intake needed to flag patients needing practical support in a way that draws the attention of Case Managers who manage financials. 

Case managers found workarounds but there wasn't a seamless method of asynchronous communication about practical support needs or a method of grouping patients in the system who needed practical support. 

OPPORTUNITY

How might users track practical support in DARIA so that information is more secure, reconcilable, and convenient for case managers to find? 

SOLUTION

I developed a new task flow and interface for tracking in-kind and financial assistance. 

Outcomes

1000

One of the abortion funds I interviewed for this project, which uses DARIA, provides assistance to over 1000 patients annually. 

 Here's how it works 

PSAsset 9.png

1. Patient fund transfer information

To centralize information for case managers handling intake and case managers handling financials, reimbursement information was added to the redesign concept. 

PSAsset 11.png
PSAsset 12.png

2. Submit request form

Submission of a practical support request creates a new record in the patient’s file for support needed.

 

I thought it was important that case managers have a streamlined way of processing a request that limits their view to what they need. Therefore, submission requests are first divided by mileage and other expenses. Mileage is the only support category with hyper-specfic information inputs required like start-end information and trip type (e.g. round trip/one-way) information that “Other Expenses” lack.  

3. Updated home page

Submission of a practical support request would prompt a new record on the homepage for Pending Practical Support Requests with the inclusion of the number of pending requests which did not have a status changed to reimbursed. 

*all patient information in this case study is fictional and is show in test environments and do not in any way reflect actual patients 

PSAsset 13.png
PSAsset 15.png

4. Mileage and Other Expenses with statuses 

When a case manager handling financials sees a pending practical support request, they could click on the patient’s record and click on any bright purple pending requests under Mileage or Other Expenses. The bright purple is a suggested edit to branding guidelines at least within the context of notification system. The contrast is a lot higher for this status marker in the list of expenses and draws the eye to pending requests. In hindsight due to different visual impairments I would have probably changed the pending status to be accompanied by a symbol on the side with a specific symbol perhaps a star while reimbursed statuses were accompanied with a $ symbol. 

 Here's the rest of the process 

RESEARCH

My first step was undrestanding through journey mapping

I was unfamiliar with practical support financing procedures. Also, every organization is different, so my first step in the redesign process was to gain insight and understanding.

 

I interviewed 4 embedded stakeholders including 3 case managers. I developed a user journey map outlining their scenarios experienced, their mood, the touchpoints with which they interacted, and opportunities for improvement. 

User Journey Map

RESEARCH

Competitive Analysis

I searched for several apps that were solving similar issues in a variety of contexts. These included SAP Concur and Expensify. I reviewed the landscape for the best and worst of the expense reporting systems. 

image 6.png
image 3_edited.jpg

SAP Concur

Expensify

Looking back and ahead

I shared this design with case managers to get their feedback through moderated usability testing.

 

After presenting the concept to our engineering team, only part of this concept is being pursued for implementation, specifically a notification on the homepage flagging users that a patient is in need of additional practical support processing. 

We chose not to pursue the more detailed in-app practical support request information due to security considerations, a huge takeaway from this experience. 

Enough about me - tell me about how I can help you!

For project inquiries, you can email me at SarahMColoma@gmail.com or find me on LinkedIn. ✌️

bottom of page