Two weeks to ship, a discount to win

Business challenge

Connect EMR is the healthcare system used by ABA Centers of America clinics. Clinic staff needed to request Uber Health rides for clients directly from the system.

The objective was an MVP in two weeks. That was the condition for a discount on the Uber subscription in the initial contract. For confidentiality reasons, the amount of the discount cannot be specified.

Two things made it hard:

• The two-week deadline was fixed by the contract.
• Two companies had to align on product and technical decisions inside that window.

What Uber provides and what I designed

Uber’s booking widget is not the whole feature. The split below shows where its work ends and mine begins.

Uber’s booking widget provides:

• The ride booking form and the map: who is riding, plan ride, pickup now or a future ride.

I designed, inside Connect EMR:

• The “Uber Health” entry in the main navigation, visible only to users with permissions, opening the ride request view in a new tab.
• The info banner with the “Uber Health Portal” button, to track ride status and review completed and cancelled requests.
• The processing loader.
• Ride summaries after confirmation, for single rides and round trips.
• The confirmation alert when cancelling one leg of a round trip.
• The full ride tracking view, designed for the next iteration.
• The framing of everything with Crayon components, so it feels native to Connect EMR.

The summaries and the cancellation screens are Connect EMR screens, built by the Connect EMR team. They are not part of the widget.

Role and contribution

Product design

I helped define the implementation path: the widget over the API. I also prioritized direct access to the Uber Health portal for the MVP, and left the full tracking view ready for the next iteration.

UX

I designed and iterated the request flow, the states and the round-trip logic, so the flow was clear for clinic staff.

UI

I integrated the widget into Connect EMR’s look and feel with Crayon components: info banner, modals, loader, buttons and alerts.

Research (technical discovery)

I reviewed Uber’s booking widget documentation before designing anything. Then I validated feasibility in product and technical conversations with Uber’s team.

Approach

I designed the MVP iteratively under a fixed deadline:

1. Technical discovery. I read Uber’s booking widget documentation.
2. Alignment. Product and technical conversations between both teams decided the implementation path.
3. UX iteration. I refined the request flow.
4. Tracking proposal. I designed a ride tracking view with ride status, date and time, destination time and place, duration and ride type, with more detail per record.
5. MVP prioritization. Tracking shipped as a banner linking to the Uber Health portal. The full view stays for the next iteration.

Tools and how they were used

• Figma: the integration flow, the tracking proposal and the final screens.
• FigJam: flows and working sessions with both teams.
• Crayon design system: the Connect EMR components that frame the widget.
• Jira: user stories and follow-up with development.
• Claude Code with the Figma MCP: to speed up graphic and text elements and to refine the flow.

Key decisions

1. Widget, not API.
   • I chose Uber’s booking widget for the MVP over a custom booking flow built on Uber’s API.
   • Because: the API path could not be delivered in two weeks, and the deadline was worth a discount on the subscription.
   • At the cost of: less control over the booking form’s look and behavior inside Connect EMR.
2. A link to the partner’s portal, not in-app tracking (for now).
   • I chose a banner with direct access to the Uber Health portal for ride status and history, over shipping the full tracking view I had designed.
   • Because: users needed visibility of their rides from day one, and the portal already provided it.
   • At the cost of: users leave Connect EMR to track rides until the next iteration.
3. A separate tab behind permissions, not a panel in the schedule.
   • I chose an “Uber Health” entry that opens the ride request view in a new tab, only for users with permissions, over a panel or modal inside the schedule view.
   • Because: the widget needs room, the schedule stays open and access is controlled by permissions.
   • At the cost of: taking the user out of the view they were in.

Edge cases and states

• Users without permissions never see the entry.
• A processing state shows while the request is confirmed.
• Single ride and round trip each have their own summary.
• When a user cancels one leg of a round trip, a confirmation explains that the request will no longer be a round trip and only the other ride is kept.
• Widget failures, invalid addresses and no available drivers: the widget encapsulates that logic and shows its own messages. Connect EMR receives the event, and the booking cannot be completed.

Challenges

• Two-week deadline. I helped the team pick the fastest viable path, which made the on-time MVP and the discount possible.
• Aligning two companies. I turned the partner’s documentation into a clear, working flow inside Connect EMR.
• Ride visibility from day one. The ride request view links directly to the Uber Health portal, while the fuller tracking experience waits for the next iteration.

Result and impact

• The MVP shipped in two weeks, in April 2026.
• Meeting the deadline secured a discount on the Uber subscription. Source: the contract with Uber. For confidentiality reasons, the amount of the discount cannot be specified.
• The integration handles about 3,200 rides a month on average. Source: internal report, an average over the first 3 months in production.

How my experience made the difference

• I read the partner’s technical documentation before designing.
• I bridged product and technical conversations between two companies to choose the fastest viable path.
• I prioritized with a product mindset: ride status and history available from the first release, and a richer tracking experience already designed.

What I learned

• Shipping an MVP with a link to the portal met the deadline, but left ride visibility outside the app. Today I would start our own tracking earlier.
• Designing around a component you do not control means defining first which states and errors belong to the partner and which are yours.