Cover image

Background & context

Dental Stack is a B2B healthtech platform built to digitize and connect Orthodontists, Aligner Companies, Design Labs, and Patients. This project introduced the Practice(Clinicians) user type that works with an Aligner Company(Aligner Providers) to obtain aligner treatment plans and track patient progress in one place, without Practices needing their own paid plan on the portal.

Let’s first understand the two key users in this case study:

Practice

Orthodontic clinics that admit patients, prescribe aligner treatments, and want to track treatment progress on the platform. They send planning orders, but in this setup, they cannot create plans themselves because they operate under the Aligner Company’s subscription.
Aligner Company (Lab)

Organizations that provide aligner services to Practices. They receive planning orders from Practices, create or manage treatment plans, and act as the main vendor on the platform for both planning and (where applicable) manufacturing.

This case study focused on enhancing collaboration between these two actors in developing treatment plans, considering real-world constraints: limited direct user access, no analytics, and requirements primarily based on my manager’s understanding of client needs.

Problem statement: Before planning orders

Originally, the platform did not support Aligner Company users at all. There were:

No planning orders: Aligner Companies couldn’t send or manage treatment planning orders on the portal.
No provision for inviting customers: There was no way for Aligner Companies to collaborate with external customers. Even those who wanted to track treatment progress, unless they had their own plan on the portal.
No shared treatment tracking: Customers without a direct account (no plan/subscription) couldn’t participate in portal-based treatment tracking.

Approach

Requirements analysis, role mapping, and rapid design - using mental simulation of clinical and lab behaviors, quick design iterations, and explicit phasing. All blocker resolutions were based on discussions with the Manager and development team.

Key blockers

Key blockers.png

Blocker	How It Arose	What We Did	What Could Be Done
Clear guidance on next steps assuming everyone might have a different workflow	Different labs and customers follow slightly different internal workflows, so a single “happy path” wasn’t enough to tell everyone what to do next.	Linked plan actions to order status so that key states (e.g., in review, approved, completed) give a clear, at-a-glance hint of what typically comes next without forcing a rigid process.	Add more explicit, role-based guidance (e.g., inline tips, “next best action” prompts, or simple checklists) that teams can optionally follow or adapt to their own workflow.
Simplify order details page UI to minimize dev effort	Rebuilding a brand‑new order details layout would have taken too much design and engineering time for this release.	Reused the existing patient profile layout (left–right split with all sections visible in a single scroll) for the order details page.	Move to a horizontal header with key sections split into tabs for better scannability and space for future additions.
Manual vs. auto order status change	End users needed timely status updates, but fully manual changes risked delays, while fully automatic changes risked feeling out of their control.	Chose automatic status changes based on plan actions for this release to keep the flow simple and avoid stagnant orders.	Revisit the behavior with real usage feedback and, if needed, add options like overrides or mixed manual/auto controls per user type.
Lack of communication between Lab and Practices	Practice and Lab might need to address things per-order basis	Included a Timeline section in the Order details page - kept it open for both Practice and Lab to comment at all times	Future: Introduce separate chat between Practice and Lab