> Case study by Lokesh Saini · Product Designer > Canonical (HTML): https://www.lokeshsaini.com/healthcare-rcm > Tags: Healthcare, Product Design, UX Research, Web, 0-to-1 # Revenue Cycle Management. Redesigned. > From hypothesis to shipped product in 6 weeks. --- ## TL;DR A healthcare professional approached me with a startup hypothesis: there was a better way to manage clinic revenue cycles. They had deep domain expertise and a detailed requirements document, but no product. Over 6 weeks, I ran the full design process (discovery workshops, competitive research, IA, wireframes, design system, prototypes). The client validated product-market fit and shipped a production web application. **6 weeks** hypothesis to shipped product · **Full design ownership** from requirements to delivery · **Design system** that accelerated development --- ## Quick Facts | | | | --- | --- | | **Company** | Under NDA (a well-established healthcare professional) | | **Role** | Product Designer (sole designer) | | **Team** | 1 client (healthcare domain expert), 1 front-end developer | | **Platform** | Web application | | **Timeline** | 6 weeks | | **Tools** | Figma (workshops, wireframes, design system, mockups, prototypes) | | **Responsibilities** | Discovery workshops, competitive analysis, market research, information architecture, wireframing, design system, prototyping, developer handoff, build management | > **Under NDA.** Some details in this case study are generalised to protect the client's intellectual property. The focus is on design process and methodology decisions. --- ## The Client A well-established healthcare professional with deep domain expertise in clinic revenue cycles. They had spent years navigating the complexity of patient intake, claim submission, and reimbursement firsthand. They arrived with a detailed requirements document and a startup hypothesis: there was a better way to manage clinic revenue cycles. What they needed was a product designer who could translate that clinical knowledge into a shipped product. --- ## The Challenge Revenue cycle management (the process from patient intake through claim submission and reimbursement) touches every part of a clinic's operations. Getting it wrong means delayed reimbursements, denied claims, and frustrated staff. The client had spent years navigating this complexity firsthand. They understood the problem intimately. But knowing the problem and knowing the solution are two different things. ### The gap in the market Competitive analysis and market research revealed that most existing RCM tools were built for large hospital systems: bloated, complex, and expensive. The opportunity was in the gap: clinics too small for enterprise software but too complex for spreadsheets. *[Visual: Patient journey flow through the revenue cycle, from intake to claim reimbursement]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/hero-journey-flow-desktop.png) ### The translation challenge The client's requirements document was detailed and thorough, built from years of clinical experience. My job was to get underneath the requirements and find everything they didn't cover. Revenue cycle management has branching logic, exception handling, role-based views, denied claims, partial payments, resubmissions. The requirements captured the happy path. The product needed to handle every path. **The core design question: How do you translate deep clinical domain expertise into a product that non-expert users can operate without training?** --- ## What I Built A structured 6-week design process that moved from hypothesis to shipped product: - **Workshops first.** We extracted the client's clinical knowledge into a designable format before any screens were created. - **Wireframes before pixels.** Low-fidelity first to validate structure and expose hidden complexity before committing to visual design. - **Design system alongside hi-fi.** As high-fidelity screens took shape, I built a design system in parallel, reusable components that compounded in speed with every new screen. - **Prototype as specification.** Every interaction, state, and edge case documented in a clickable format that doubled as the developer's build spec. - **Prototype reviews with the domain expert.** Every flow walked through with the client against their requirements document before handoff. *[Visual: Simplified user flow showing the core screens and decision points in the RCM application]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/simple-user-flow-desktop.png) --- ## The Process Six weeks demanded a tight sequence: workshops first, then competitive analysis and information architecture, then wireframes to expose hidden complexity, then high-fidelity screens with a design system built alongside them, then prototype reviews before developer handoff. Discovery workshops pulled out the client's implicit clinical knowledge: workflow nuances, edge cases, and user expectations the requirements document had missed. Lo-fi wireframes revealed that a simple 6-screen flow actually required branching logic, error handling, and role-based views. As high-fidelity screens took shape, I built a design system in parallel, reusable components that compounded in speed with every new screen. Interactive prototypes doubled as the developer's build spec. I managed the developer handoff, sprint prioritisation, and build reviews throughout. *[Visual: Process flow: hypothesis to shipped product in 6 weeks]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/process-flow-desktop.png) --- **Decision 1** ## Invested in Workshops Before Designing Anything ### Context The client arrived with a comprehensive requirements document. It would have been easy to start wireframing immediately. The requirements were clear, the timeline was tight, and the client was eager to see screens. But requirements documents describe what someone wants built. They don't always describe what should be built. The client had deep clinical expertise, the kind of knowledge you only get from years of practice. That knowledge was implicit, embedded in how they talked about workflows, not written in any document. ### Options considered | Option | Approach | Verdict | | ------ | -------- | ------- | | Design from requirements | Start wireframing directly from the document | Rejected: would miss implicit domain knowledge | | **Structured workshops** | **Facilitate sessions to extract and challenge assumptions** | **Chosen: higher upfront cost, better foundation** | ### What I chose and why I facilitated structured workshops to unpack the client's vision, challenge assumptions, and define scope. These sessions revealed workflow nuances, edge cases, and user expectations that the requirements document had not captured. The workshops gave us shared understanding. Every design decision that followed could reference conversations we had together, not interpretations I made alone. > "The customer journey and design processes were very straightforward for us." > > The client *[Visual: Workshop board capturing domain knowledge, user flows, and assumptions from structured discovery sessions]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/workshop-board-desktop.png) ### What I gave up Two days of the 6-week timeline went to workshops instead of design. On a tight schedule, that felt expensive. But the alignment it created saved more time than it cost. We avoided the back-and-forth that derails early-stage projects. --- **Decision 2** ## Used Wireframes as a Thinking Tool, Not a Deliverable ### Context The client wanted to see the product taking shape. High-fidelity mockups feel like progress. Wireframes feel like planning. On a 6-week timeline, everything needs to pull its weight. ### Options considered | Option | Approach | Verdict | | ------ | -------- | ------- | | Jump to hi-fi | Start with polished mockups directly from workshop outputs | Rejected: premature commitment to layout and flow | | **Lo-fi wireframes first** | **Outline information at each step without visual design** | **Chosen: faster iteration, focused feedback** | ### What I chose and why Low-fidelity wireframes let me share a layout, get client feedback, and iterate in hours rather than days. The client could focus on whether the flow was right without getting distracted by colours and polish. This is where the hidden complexity emerged. What started as a simple 6-screen flow expanded into a system with branching logic, error handling, and role-based views. Wireframes made that complexity visible before any visual design was committed. *[Visual: Low-fidelity wireframe screens showing the information architecture and screen flow]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/wireframe-screens-desktop.png) *[Visual: Expanded journey map documenting every touchpoint, decision branch, and edge case in the revenue cycle]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/expanded-journey-map-desktop.png) ### What I gave up The client didn't see "real" screens until later. For someone funding a startup hypothesis, that takes patience. I managed expectations by sharing the wireframes as progress, showing that the thinking was happening even if the polish wasn't. --- **Decision 3** ## Built a Design System Alongside Hi-Fi Screens ### Context Six weeks. One designer. A complex domain with dozens of screen types, form patterns, and data displays. With the structure validated through wireframes, I needed a way to produce high-fidelity screens fast. The standard approach would be to design screens individually, establishing patterns as they emerge. ### Options considered | Option | Approach | Verdict | | ------ | -------- | ------- | | Screen-by-screen design | Design each screen individually, extract patterns later | Rejected: too slow for 6-week timeline, inconsistent handoff | | **Design system in parallel** | **Build a consistent visual language with reusable components alongside hi-fi screens** | **Chosen: compounding returns as the system grew** | ### What I chose and why As I moved into high-fidelity screens, I built the design system alongside them: consistent hierarchy, reusable components, coherent colour palette. Each new screen contributed components back to the system, and the system accelerated every screen that followed. Without it, I wouldn't have finished in 6 weeks. When the developer started building, every screen had a clear, consistent specification to follow, reducing questions during build and revisions after. ### What I gave up The early hi-fi screens took longer because the system was still taking shape. But by the midpoint, the compounding kicked in and new screens came together rapidly. *[Visual: Outcomes grid showing shipped deliverables, validated hypotheses, and process results]* (https://www.lokeshsaini.com/case-studies/healthcare-rcm/outcomes-grid-desktop.png) --- ## Reflection I almost skipped the workshops. Two days out of six weeks feels like a lot when the client is eager to see screens. But those sessions saved far more time than they cost. We caught misalignments in conversation that would have shown up as rework in week 4. The wireframes surprised me. The client's requirements were thorough for the happy path, but wireframing every screen forced us to deal with branching logic, error states, and edge cases nobody had written down. Better to find those gaps in pencil than in code. The design system was a similar bet. Building it alongside the hi-fi screens meant the early screens took longer, but each one contributed components back to the system. By the midpoint, new screens came together fast. The developer had consistent specs throughout. It compounded exactly the way you'd hope. One thing I'd do again without hesitation: staying involved through the build. On a small team, you can't hand off a Figma file and walk away. I reviewed builds, helped prioritize sprint order, and caught inconsistencies early. The final product matched the design because I was still there when it shipped.