I designed, coded, and documented the first design system in this medical SaaS product’s 15-year history. I replaced fragmented UI decisions with reusable foundations, components, layouts, and production code that accelerated delivery.
Medical Asset Management's flagship product, iRCODER, helps hospital teams turn procedure details into accurate billing codes. The product led its niche, but fifteen years of incremental development had left the interface inconsistent and costly to extend.
I had joined the company as a technical writer, taught myself front-end code, and became its first-ever designer. I audited the implemented product, built its first design system, and shipped HTML/CSS directly to production, cutting comparable UI turnaround from twelve months to three and creating a shared language across teams.
Problem
A trusted product grew for fifteen years without a designer
iRCODER was functionally mature and a leader in its niche, but it had never had a design function. For fifteen years, interface decisions were made by full-stack engineers as each feature demanded: capable people solving front-end as an afterthought to the server-side work they were hired for. The workflows hospital teams depended on stayed intact, but typography, spacing, controls, color, and language drifted screen by screen into a visible patchwork.
Every screen solved design alone, and the exceptions compounded
With no component library or front-end ownership, similar actions looked different, unrelated actions sometimes looked identical, and each new screen inherited another generation of exceptions. The dated appearance was the symptom customers could see, while the cost engineers felt was rebuilding the same decisions over and over. The challenge was modernizing the interface without disrupting workflows that clinical teams had trusted for years.
insight
Why did routine interface work require so much engineering effort?
I audited the implemented product rather than starting with a speculative redesign, revealing over a decade of local decisions with no shared foundation. I inventoried screens, selectors, colors, type, controls, alerts, forms, icons, and repeated language, then tested cloned markup in browser DevTools. This was an implementation audit, not generative user research: its purpose was to trace visible inconsistency back to the system producing it.
Inconsistency was an issue of delivery as much as style
The audit exposed years of one-off decisions that added design effort, engineering effort, QA scope, and regression risk. Interface knowledge was being recreated instead of accumulated. Product, SME, engineering, and QA review helped ensure new standards preserved the clinical workflows users already trusted.
Jobs to be done: When clinical staff complete high-frequency workflows, they need consistent behavior so they can work without relearning each screen.
Josef
Priya
Scott
decision
Three ways to modernize, each risking a different failure
The audit showed that inconsistency was structural, but the application was actively used, technically constrained, and dependent on familiar workflows. I considered three scopes:
- Apply a visual refresh — Normalize color, typography, and spacing while leaving components and layouts largely intact.
- Clean up UI during feature work — Improve individual patterns only when related screens entered the backlog.
- Build the system holistically, then introduce it incrementally — Define shared foundations, components, layouts, content rules, and implementation guidance before rolling them into production through normal releases.
Design tension: The interface needed greater consistency and maintainability without disrupting trusted workflows or requiring an application-wide rewrite.
I built the full system, then shipped it incrementally
Defining the system holistically gave local decisions a shared foundation. Delivering through active releases preserved workflow continuity and kept every change reviewable inside the existing process. A simple refresh would improve cosmetics, but a reusable system becomes shared infrastructure. Each completed pattern reduced the cost and ambiguity of every screen that followed.
Gallery
I turned scattered values and language into a shared product vocabulary
By defining tokens to enforce fundamental design discipline, I collapsed years of scattered color, type, spacing, icons, states, and interface copy into shared rules. Five typefaces became one brand family plus a monospace, while reusable tokens governed visual decisions. I applied the same approach to language, standardizing action labels and rewriting messages around what happened and what users should do next.
I made semantic purpose, hierarchy, and state reusable
I audited recurring buttons, fields, alerts, and controls, then separated what an action means from how strongly it should appear. Shared components replaced one-off styling and aging scripted controls with consistent hierarchy, states, content guidance, and accessible, declarative HTML patterns.
I assembled components into predictable, responsive page structures
I organized dense screens around repeatable regions for navigation, status, forms, tables, and actions. Shared spacing and responsive rules replaced page-by-page alignment, allowing columns and controls to reflow without changing the familiar order of clinical workflows.
I changed the architecture underneath the interface
By carrying the system into production (not just Figma), I avoided bottlenecks and interpretive drift. I moved styling decisions from scattered declarations into reusable tokens and component rules, working against cloned production markup and resolving legacy cascade conflicts in DevTools. The .NET team reviewed my HTML/CSS through its existing code-review process.
Delivery
I delivered design as production code, not as pictures of code
I owned the UI audit, system architecture, Figma components, prototypes, front-end implementation, documentation, and release coordination. Shipping HTML/CSS directly let design intent survive implementation, while foundations that affected many screens moved through Jira, engineering review, QA, and phased releases.
Adoption came through the team's existing workflow, not around it
The system succeeded because it plugged into outcomes stakeholders already valued:
- Faster implementation
- Fewer repeated decisions
- Easier QA
- Brand consistency
Engineers reviewed my code through their normal process. Product leaders and SMEs reviewed workflow implications. Backend logic, merge authority, and release control stayed with engineering. The system gained credibility because developers could inspect, challenge, and reuse it inside the workflow they already trusted.
Validation
Every pattern earned its way in through prototype, review, and production
Validation happened at several levels:
- HTML prototypes made interactions reviewable in staging before production
- Browser implementation exposed cascade and server-rendering conflicts
- Product and SME reviews protected workflow continuity
- QA tested regression risk
Production use then surfaced exceptions that were folded back into component rules instead of patched independently. The project's strongest evidence concerns delivery efficiency, implementation consistency, and reduced UI debt.
IMPACT
I slashed delivery time by turning one-off UI work into reusable patterns
Comparable UI delivery became 75% faster and identified UI debt fell 40% over twelve months. I wrote or maintained more than 5,000 lines of production front-end code, making the system part of the shipped product rather than a reference engineering had to interpret. The source architecture improved materially:
Though these code metrics are not user outcomes, they are evidence that the design approach replaced many local decisions identified during the audit. Users retained familiar workflows during the modernization. Developers gained reusable patterns instead of repeatedly rebuilding controls. Design knowledge became institutional.
Josef
Priya
Scott
REFLECTION
Phased delivery turned design standards into working infrastructure
The incremental strategy matched both the technical constraints and the organization’s design maturity. Building through active releases forced the system to solve real implementation problems and gave design, engineering, product, and QA a reusable language grounded in production behavior. The strongest lesson was that a design system gains influence when it reduces uncertainty for the people expected to adopt it, not simply when its components look more polished.
What I'd do differently next time...
With hindsight, I would preserve the incremental delivery strategy while establishing stronger foundations and measurement much earlier.
- Define first-principles rationale and governance.
- Plan migration beyond .NET Web Forms.
- Measure component adoption and task usability.
- Build a versioned, testable component library.
That would move the work from successful legacy modernization toward a more measurable, portable, and technically independent product capability.