Specialty Plasma Collection

Scaling beyond MVP to enable the collection of specialty plasma worth 5-20x standard value

TL;DR

  • Lead designer that scaled initial MVP experience, unlocking specialty plasma collection worth 5-20x the value
  • Strategic product thinking that allowed for significant descoping while still solving the core problem
  • Partnered closely with internal SME to understand the domain

Key screens & artifacts

The problem

A core goal for our product team was to increase revenue. The two levers we focused on were 1) increasing operational efficiency to process more total plasma, and 2) collecting higher value plasma that could be sold at a higher price point. This specific project focuses on the latter, allowing plasma centers to begin collecting and selling specialty types, like Male-AB blood type or tetanus-antibody plasma, rather than just generic (normal) plasma.

Testing assumptions

While not unique, it does feel worth mentioning that our product development strategy was really focused around developing MVP functionality so we could deliver value as quickly as possible, and this certainly influenced decision-making as detailed below.

I believe my biggest contribution to this project was during this initial kickoff, before I even opened Figma.

The core requirement outlined for this project was that we needed to support multiple versions of each plasma type to align with differing needs from consignees. For example, Consignee A might adhere to slightly different donor eligibility than Consignee B, for the same plasma type. As I began exploring how to solve for this, I quickly noticed the complexity beginning to snowball: if consignees differed, then locations shipping to multiple consignees would need to reconcile competing collection requirements, labeling, and storage rules, leading to a large jump in scope. So before going deeper, I wanted to confirm — were the needs actually different, or was this us trying to preemptively cover every edge case? After further discussion, it turned out that these needs were hypothetical, and the current reality was that they were standard across the board, at least in the US (EU regulation we deliberately deferred). We were trying to move fast and deliver value, so I pushed to build for the reality, not the hypothetical, and the team agreed.

That simplification made me hopeful that the solution itself would be pretty straightforward — we just needed to be able to define the proper criteria for each product. That's it, right? Now wouldn’t this job be boring if things were that easy? 😅 When discussing the direction, our SME surfaced a case that somehow hadn’t been shared previously. We wanted to collect hyperimmune plasma, the antibody-rich plasma produced after a donor is immunized against something like tetanus. We couldn’t leave all criteria at the product level because there are processes that had to exist independently of the product itself — a donor must follow certain immunization timelines (and is compensated for doing so) long before their plasma qualifies as any special product.

Bringing It to Life: The Tetanus Processing Flow

With this updated direction in hand, I then worked to define flows for each step of the donation journey. That journey can differ depending on the plasma type, but I’ll highlight pieces of the flow for the tetanus program as that was the most complex at the time.

  1. Program creation: A new program is configured in the system, with its own eligibility criteria, immunization schedule, and compensation rules. This is a one-time setup step that happens before any donors are enrolled.
  2. Interest and manual evaluation: A donor expresses interest in the program. A staff member then manually evaluates the donor and decides whether to place them on the tetanus program at all.
  3. Program placement and immunization: Once placed on the program, the donor is enrolled in an immunization schedule for tetanus. At this point, nothing about their plasma has changed yet. What has changed is their status as a program participant, which is the distinction that made a standalone program layer necessary in the first place.
  4. Ramp-up period: While the donor works through immunization, they continue donating normal plasma as usual, while their titer (antibody) levels are monitored. Compensation during this period reflects their commitment to the program itself, not just what they're currently producing — donors get paid more for being enrolled, well before any of their plasma actually qualifies as tetanus product.
  5. Reclassification once the threshold is met: Once titer levels cross the required threshold, the donor's product classification changes — their donations are now tetanus plasma rather than normal plasma, and can be sold as such to consignees
  6. Producing tetanus plasma until it drops out of range: The donor continues donating tetanus plasma for as long as their titer levels stay in range. When levels eventually drop back out of range, the donor exits the tetanus product classification and is moved off the program. This completes the special program loop.
The tetanus program in product1/3 · click to cycle

Outcome and reflection

This Special Programs work was still in active development when I left Buoy, so I don't have usage or revenue metrics to point to. What I can point to is a willingness to ask questions and poke holes in assumptions, as well as a keen sense of how to successfully move projects forward.

While I’m most proud of the strategic thinking I brought to this project, I believe the design work itself turned a complex system into a manageable set of flows that not only allowed the company to reach its goal of collecting high valuable plasma, but did so in a way that made sure the staff could operate efficiently, safely, and in full legal compliance.