Challenge
Turn fragmented humanitarian workflows into a testable MVP that supports real operational needs.
Background
Speed and accuracy are critical in crisis response, yet many local NGOs still rely on fragmented spreadsheets, paper lists, and disconnected tools. This often creates data silos, slows down coordination, and makes it harder to track who needs what support, where capacity is available, and whether aid has been delivered effectively.
Relif is a modular platform designed to bring beneficiary, shelter, inventory, and donation data into one system, so teams can manage operations more clearly and respond more efficiently.
About Relif
Relif was shaped by the founders’ long-term experience in disaster response, where they repeatedly saw how fragmented tools slowed coordination and made field work harder to manage. The platform was created to bring those operational needs into one clearer system for smaller NGOs.
Relif supports several connected workflows across emergency response, from beneficiary management and shelter allocation to inventory and donation distribution. Donation touched several parts of the platform and introduced requirements specific to humanitarian response. That made it the focus of this case study.
My Responsibilities
As a junior UX/UI designer, I supported the design lead across multiple workflows in the platform, including global search, sign up and onboarding, donation entry, and donation distribution. These were collaborative efforts, and several of the flows I contributed to were later revised further by the design lead. The area I worked on most deeply was the bulk donation workflow.
Discovery Phase
Before I joined, Relif’s founders had already spoken with people working in humanitarian response to validate the product direction. Their interviews gave the team an early understanding of how field operations were being managed, and we used those insights to guide later design decisions.
What the early interviews revealed
Across interviews, recurring issues centered on fragmented data, low visibility, and slow coordination. These findings shaped the product’s focus on donations, inventory visibility, and delivery traceability.
Duplicate data entry
Teams often relied on spreadsheets, paper lists, and disconnected systems across different stages of response. In some cases, the same information had to be entered in both Masterlist and ProGres, then checked again elsewhere. This created extra admin work and increased the risk of inconsistent records.
Stock visibility gaps
Available stock, donor requirements, and expiration dates were not always visible in one place. Without a clear overview, teams found it harder to know what was available and what could be distributed safely.
Slow field distribution
Incomplete or outdated data slowed down material delivery in the field. User often had to verify information manually or follow up across teams before items could be handed out.
Donor accountability
Reporting back to donors was difficult when delivery records were fragmented or incomplete. Teams needed a clearer way to track what was distributed, to whom, and whether proof of delivery had been collected.
Designing the solution: Capturing donor conditions during donation entry
Donation entry was not just about adding stock. The same product could come from different donors, each with different eligibility rules, expiry dates, or proof-of-delivery requirements. We designed the flow to capture these conditions at the start, so they would stay visible later in inventory and distribution.
Reusing Product Information Without Losing Donor Details
To keep donation data easy to scan and easy to enter, we separated product-level information from donation-specific details. On the donation overview, users can expand a product to see different donated batches. When adding a new donation, they can reuse existing product records and only update the details that are different for this donation.
Donation overview
1
Parent rows show the product. Child rows show each batch’s donor, expiry and eligibility.1
Add new donation
1
Search and reuse an existing product, then update only what differs for this donation.1
Making Donor Requirements Visible from the Start
Some donations come with conditions. For example, the same hygiene kit may be donated by different organizations: one can be given to any beneficiary, while another is reserved for domestic violence survivors and requires proof after delivery. We separated these requirements into three fields so user could record them clearly from the start.
- Donating entity
- Records who provided the donation. This could be an NGO, company, individual donor, shelter, or other partner organization.
- Eligibility
- Defines who can receive this donated stock. User can select groups such as domestic violence victims, unaccompanied minors, disabled beneficiaries.
- Proof of delivery
- Sets whether delivery evidence is required. User can choose either a signature or a photo confirmation, so the proof can be shown later in donor reports.
Donating entity
1
Search an existing donor or add a new one.1
Eligibility
1
Choose who can receive this stock. It becomes a tag for filtering beneficiaries later.1
Proof of delivery
1
Mark if delivery needs proof. User then adds a photo or signature when confirming.1
Bulk Donation Flow
Bulk donation supports a common field task: distributing selected items to multiple beneficiaries in one workflow. I designed the flow to help user move from selecting donations, to choosing beneficiaries, to confirming quantities with enough context.
Select items
1
2
Donate buttons appear when item is selected.1
Selected items could be sent into the bulk donation flow from the donations table.2
Choose beneficiaries
1
2
User can filter beneficiaries to find the right group for distribution.1
“View donation” shows the selected products without leaving the beneficiary list.2
Set quantities
1
Each item card shows total needed and stock left before processing.1
Connecting Desktop Tracking with Mobile Delivery
Clear delivery tracking helps user avoid duplicate distribution and gives donors reliable proof after aid is delivered. I designed the desktop flow for coordination and overview, then connected it to a mobile confirmation flow for on-site delivery.
Desktop Tracking for Bulk Donation Records
After a bulk donation is processed, it appears as a record in the bulk donation history. Opening the record shows the delivery list, where user can review the donation details, donor requirements, delivery progress, and each beneficiary’s status.
This keeps coordination work on desktop, while making the next delivery actions easy to find.
Bulk donation history
1
Processed bulk donations are saved as records to track status and reopen later.1
Delivery list detail
1
2
3
Overview cards show products, donor requirements and delivery progress.1
The QR code opens the same delivery list on mobile for on-site confirmation.2
Row actions appear only when needed, to add proof or mark an item as delivered.3
Mobile Confirmation for Field Delivery
Delivery often happens away from the desk, so the main confirmation flow was moved to mobile. User can scan the QR code, open the beneficiary list on their phone, and confirm each delivery on site.
If proof is required, they can add either a signature or a photo before marking the item as delivered. This keeps the process flexible in the field while preserving proof for donor reports.
Delivery on desktop
Mobile flow
1
The QR code opens the delivery list on mobile for on-site confirmation.1
Usability Testing & Iteration: Redesigning the Bulk Donation Flow
We tested Relif at two stages: an early low-fidelity test to check the overall workflow, and a later usability test to evaluate the detailed interaction design. One key issue appeared in the bulk donation flow.
Testing revealed a quantity misunderstanding
My first version followed a simple shopping-cart logic: users selected items, set quantities, then chose beneficiaries. In think-aloud testing, 3 of 5 participants misunderstood the quantity step. They read the number as the total amount to distribute, rather than the amount each beneficiary would receive. One participant said, “I thought this was the total number to give out.”
This showed that the issue was not only wording. Users needed to know who would receive the items before deciding how much to give. I redesigned the sequence so users selected beneficiaries before setting quantities.
Select items
Set quantities
Choose beneficiaries
Initial quantity modal
Initial quantity modal
1
Users read this as the total quantity, not the amount per beneficiary.1
Reordering the flow around field habits
The updated flow gave the quantity step more context. Users could now see how many people were selected, then decide how much of each item each person should receive. The final page also showed total needed and stock left, helping users check whether the planned distribution was realistic before processing it.
After the redesign, we tested the flow again. Users found the new sequence easier to follow.
- Select items
- Choose beneficiaries
- Set quantities
View donation pop up
View donation pop up
Design library
Built a library of 76 components, from buttons and form fields to table rows and status tags. As more flows got added, this kept the interface consistent without redesigning the same pattern each time, and it gave developers a clear reference when building screens.
Final Screens
What I Learned
When I joined, my job was mostly supporting the design lead. I'd take a flow he'd already thought through and turn it into screens. As I spent more time on the product, I started understanding how the pieces connected, like why donation touched inventory, why eligibility rules mattered later in distribution. Then I felt more confident designing the bulk donation flow.
Relif's workflows weren't things I had personal experience with, and the team didn't have much room to build things twice. So before I designed anything, I got into the habit of asking questions, checking with the founders on what actually happens in the field, and checking with the developer on whether something was realistic to build before I got attached to a design.
The team was also spread across different regions and time zones, so a lot of alignment happened async. I had to get better at explaining my design decisions clearly the first time, laying out what I was solving for and why, so feedback could happen without three rounds of back and forth. That's the part of this project that changed how I work the most.
Next in the file
DreamCatcher
Mar 2025 — May 2025
An AI-assisted dream journal designed to help people record their dreams, tag what keeps coming back, and read the patterns those tags reveal.
P-ID 0325 0525 · 04