Shipped

Shipped

Orchestrating cross-provider mobility within a rigid, engineering-led technical ecosystem

Orchestrating cross-provider mobility within a rigid, engineering-led technical ecosystem

Reciprocity Management System

Reciprocity Management System

Project Context

Project Context

Portal for managing temporary affiliate transfers between healthcare providers based on formal reciprocity agreements.The product was part of a broader system, with a pre-defined technical architecture (web app with side panel) established by engineering prior to design involvement.

Client

Tekhne SA - COSSPRA

Timeline

4 weeks

Role

Product Designer

Year

2023

Outcomes

Outcomes

✓ Clearer ownership and responsibility across institutions
✓ Reduced confusion caused by inconsistent terminology
✓ More actionable interface for staff handling high volumes of requests

✓ Clearer ownership and responsibility across institutions
✓ Reduced confusion caused by inconsistent terminology
✓ More actionable interface for staff handling high volumes of requests

✓ Clearer ownership and responsibility across institutions
✓ Reduced confusion caused by inconsistent terminology
✓ More actionable interface for staff handling high volumes of requests

How i did it

How i did it

Problem

Managing affiliate transfers between institutions was operationally complex and highly dependent on manual review. The initial structure lacked clarity around:

  • request ownership (origin vs destination provider)

  • role responsibilities

  • inconsistent terminology across organizations

This resulted in confusion, inefficiencies, and increased cognitive load for staff handling requests.

Key Challenges

Transfers could be initiated by either the origin or destination provider, requiring clear role logic
- Requests were only valid if a formal agreement existed between institutions
- All requests required manual validation and approval
- Terminology (“sent”, “received”, “departing”, “arriving”) meant different things depending on context

Transfers could be initiated by either the origin or destination provider, requiring clear role logic
- Requests were only valid if a formal agreement existed between institutions
- All requests required manual validation and approval
- Terminology (“sent”, “received”, “departing”, “arriving”) meant different things depending on context

Approach and Key Decisions

Research & Analysis

Focused on deep documentation review and technical requirements due to a lack of direct access to end-users. I relied on a pre-established framework of critical functions and held multiple sessions with the Project Lead to ensure the design respected all regulatory and operational constraints.

UX & Information Architecture

Developed detailed user scenarios to empathize with different user types and their specific needs. I iterated through various information architecture models to streamline the navigation, focusing on creating a faster, clearer path to access core features and reduce cognitive load.

UI & Visual Design

Adapted to the pre-existing layout and technical constraints, focusing on simplifying the interface to make it as functional and accessible as possible.

Product Collaboration

Iterated with the Project Lead to standardize terminology for a national scale. I also collaborated closely with developers to define the display of complex tables and high data volumes, ensuring technical feasibility without compromising clarity.

  1. Simplifying data management

Early analysis showed providers were static entities.
We proposed syncing providers automatically from the organization’s database, removing manual entry and reducing operational overhead.

  1. Reframing language to remove ambiguity

Through flow mapping and IA diagrams, we identified terminology as the core usability issue.
After several iterations, we introduced a clear distinction:

Internal affiliates: members of the organization’s own network
External affiliates: members from other providers.

This semantic shift clarified responsibilities and aligned mental models across institutions.

  1. Structuring the interface around actions

We grouped all requests requiring action and used:

  • tab-based navigation to distinguish request types

  • a secondary interaction layer for approval/rejection to keep the main interface focused and clean

Learnings

  • Information architecture diagrams were critical to untangle complex, multi-actor systems

  • Language is a product decision: poor semantics can undermine an entire workflow

Opportunities for Improvement

  • Further refinement of request prioritization and visual hierarchy

  • Better surface key information in request management views

More

Next Project