The Challenge

Quilt was not a typical single-sided product. It was a dual-sided healthcare platform with two interconnected experiences:

• A free patient-facing app (B2C)
• A paid provider-facing app (B2B)

That created a difficult product challenge. The patient app needed to feel useful and coherent on its own, even for users who were not yet connected to a provider on Quilt. At the same time, the platform needed to support provider-managed care, organizational workflows, role-based permissions, and healthcare compliance requirements.

This meant the work was not just about designing screens. It required defining how patients, providers, care teams, care plans, and organizations would relate to one another in the product, and how the experience should adapt based on each patient’s entry point and level of clinical connection.

---

My Role

As the first product designer on the team, I helped turn an early concept into a structured product foundation. My responsibilities included:

• Defining end-to-end flows for both patient and provider experiences
• Mapping onboarding and care-request journeys across different patient scenarios
• Shaping the platform’s information architecture and object model
• Establishing the visual language and component patterns for the MVP
• Customizing Ant Design for Quilt’s product needs
• Documenting the design system and writing a user guide for consistent implementation
• Partnering closely with engineers while requirements were still evolving

Because the product was still taking shape, research, IA, flows, UI, and system thinking were happening in parallel.

---

Understanding User Entry Points

One of the first challenges was understanding that there was no single “patient onboarding” flow. Patients could enter Quilt in multiple ways:

• Invited by a provider already on the network
• Invited by a provider not yet fully integrated
• Signing up on their own
• Joining with an existing patient record already created elsewhere in the system

Each path affected what data was available, what permissions were possible, and what value the product could offer immediately.

To make sense of this, I mapped the different account creation scenarios and patient entry states early on. This work helped clarify where the product needed flexibility, where it needed stronger validation, and where provider-side workflows would shape the patient experience.

---

Research and Product Definition

Before getting deep into UI, I spent time breaking down the problem through journey mapping, object mapping, card sorting, and prioritization exercises.

These artifacts were important because the challenge was not only what to design, but what the product should offer first and how those features should relate to each other.

I explored questions like:

• What can a patient do before being connected to a care team?
• Which actions require provider involvement?
• Which concepts are core objects in the system versus supporting metadata?
• How do we reduce friction in a healthcare product without oversimplifying important consent and care workflows?

This helped the team move from a loose set of user stories toward a clearer product model.

---

Designing for Early Value

A central product question was how to make the patient application useful before clinical connections were established. Healthcare products often ask for large amounts of sensitive information early in the process. This can create friction and trust barriers.

To address this, I explored which features could deliver immediate value while minimizing data requirements.

Using card sorting and prioritization exercises, I evaluated potential features across several dimensions:

• Perceived user value
• Frequency of use
• Trust burden (how much sensitive data was required)
• Time to first meaningful outcome

That framework helped us focus on features that were both useful and realistic for an MVP, especially in a healthcare setting where asking for sensitive data too early can create friction.

This work shaped the early product around a smaller set of core patient experiences instead of an overly broad feature set.

---

When the data pipeline changed the design

One of the features that scored well in prioritization was the ability to search for clinical trials by location, something patients consistently mentioned in interviews as meaningful. The requirement was written to support geo-based search, and early designs reflected that.

When I brought the flow to engineering, I learned that geolocation data wasn't part of the current data pipeline and wouldn't be available by MVP. The feature as designed would have shipped in a misleading state: a location search with no location data behind it.

I made the call to cut it. For the MVP we scoped it down to name-based search, with location-based filtering documented as a post-launch dependency. It wasn't the experience we'd planned, but shipping a broken promise would have been worse than shipping a smaller one. This kind of negotiation between what users want, what's technically possible, and what's honest came up regularly throughout the project.

---

Defining the Core System

As the product evolved, it became clear that the complexity of Quilt was not primarily a UI challenge. The real challenge was understanding the underlying structure of the system.

The platform connected multiple actors and entities — patients, providers, care teams, organizations, care plans, and clinical data — all with different permissions and relationships. Without a clear model, it would be difficult to design coherent workflows across the patient and provider applications.

To make sense of this complexity, I used an Object-Oriented UX (OOUX) approach and the ORCA framework to map the core objects in the system and define how they relate to one another.

This approach focuses on identifying:

• Key objects in the product
• Relationships between those objects
• Attributes that define them
• Actions users can take on them

The object model became a useful reference point as we designed flows for both the patient and provider apps, helping ensure that the product remained consistent as features were added.

---

Designing around a compliance constraint

One of the harder design problems was how to let patients search for and connect to their hospital or care center without exposing which organizations were contracted with Quilt. This was a HIPAA requirement that ruled out a straightforward directory approach.

After several iterations, I designed a flow that worked around the constraint. Patients could search for an organization and request a connection, but the system wouldn't confirm whether that org was on the platform. Instead, it would enter a pending state with a human review step before any connection was established. For organizations already on Quilt, the system would quietly compare the patient's date of birth against existing records, with three attempts allowed before routing them to contact their provider directly.

The compliance problem was solved. The communication problem wasn't, at least not fully. Patients weren't getting clear feedback about what was happening or how long it might take, and that was partly a process gap internally, not just a UX gap. It's something I'd have pushed harder on with more runway. What shipped was compliant and functional, but not as transparent as I would have liked.

---

How a layout decision got resolved

Early versions of the Care Hubs screen combined available and connected/pending organizations in a single view. Engineering pushed back because the pending state created ambiguity: if a hub was pending, should it still appear in the available list? We didn't have a clean answer on either side.

Splitting the view into tabs resolved it. Available hubs on one side, connected and pending on the other. The separation made each state cleaner, and the final design was better for the pushback.

---

Design System and UI Foundations

Alongside product flows, I also helped establish the visual and component foundation for the platform.

We used Ant Design as the starting point, then customized it to fit Quilt’s product needs and tone. My role included defining how the system should be adapted, choosing and refining reusable UI patterns, and creating consistency across the patient and provider experiences.

To support implementation and future scale, I also wrote a user guide for the design system, documenting component usage and patterns for the team. This helped create a more consistent handoff process and gave engineering a clearer reference point as the product evolved.

That work was especially important in an early-stage environment where speed mattered, but consistency still needed to be intentional.

---

Outcome

Within about six months, we shipped MVP versions of both the patient and provider applications. The MVP established the foundation for Quilt’s core care experience, including:

• Care plan
• Care team
• Request care workflow
• Quilt card for sharing medical history and care plans via QR code
• Clinical trial options

Beyond those shipped features, the work also created underlying product structure that made the platform more coherent: onboarding paths, core objects, interaction patterns, and a documented component foundation for future growth.

---

Reflection

What made Quilt interesting was that the hardest problems were not purely visual.

The work required balancing product strategy, healthcare constraints, system design, and interface design all at once. The challenge was figuring out how the product should behave across multiple patient states and provider relationships, then turning that into something simple enough to ship as an MVP.