Case Study
Kaiser Permanente's internal Revenue Cycle websites serve the teams who handle patient financial services, reporting, and regional operations. I was the only frontend developer on the team, on a contract in 2012 and 2013, and I coded the redesign of the internal desktop site from scratch, working closely with the UX designers and handing the finished frontend to the backend team. The designs did not arrive as layered files. They arrived as PDFs.
This job sits early in my career, before the UX roles elsewhere on this site. It is also where my habit of designing things developers can actually build comes from. I had been the developer waiting on the files.
The finished internal site. Patient Financial Services and the regional Revenue Cycle pages, coded from the PDF designs.
The Problem
Design handoff usually means layered source files and specs. Here it meant PDF documents of finished page layouts, with no layers to inspect, no assets to export, and nothing interactive to test. At the same time, the internal site needed a full rebuild rather than a touch up, and the backend team's work could not start until the frontend existed. The first job was turning flat pictures of pages into a plan a developer could build from.
PDFs instead of layered design files. Every measurement, color, and asset had to be recovered from the documents themselves.
The internal desktop site was being redesigned, and the codebase started empty. Structure, styling, and behavior all had to be created, not inherited.
The backend team would integrate whatever I built. Unclear or sloppy frontend code would become their problem, and then everyone's.
Research
Before any code, I analyzed each PDF design for its layout, components, and interactive elements, and planned the structure of the site: the header, footer, navigation, and content areas, and how every element would be positioned and aligned. The PDFs were imported into Photoshop and converted to PSD files, so the designs could be measured, sliced, and prepared as web assets.
Finding. A flat PDF hides its own logic. Layout, components, and interactive elements had to be identified page by page before anything could be planned.
Decision. Each design was analyzed and mapped to a structure first. No page went to code as a mystery.
Finding. With the structure clear, the image work could be planned: which slices, which formats, JPG or PNG, and how each asset would be compressed.
Decision. Assets were optimized for fast page loading without giving up quality, a real concern on an internal network.
Key Moves
Move One
Every PDF was imported into Photoshop and converted into a PSD, recreating the layered file the handoff should have included. From those files I could measure the layouts precisely, cut the image slices, and prepare the assets the way a developer needs them, instead of estimating from a picture.
Finding: you cannot code accurately from a picture of a page. Decision: rebuild the source files first, then code from real measurements.
Move Two
The codebase was written from scratch with semantic structure: header, nav, section, and footer elements, a proper heading order from h1 to h6, labeled form and input elements, descriptive alt text, and descriptive links. CSS ran through Sass with Flexbox layouts and cross browser compatibility checks, and JavaScript libraries handled the interactions, with moderate tweaks where the designs asked for more.
Finding: an internal site is used by everyone in the building, including people on assistive technology. Decision: accessibility was part of the structure, not a pass at the end.
Move Three
The frontend went to the backend team as a complete package: the code, comprehensive documentation, testing and bug reports, and performance, security, and deployment guidelines. The code structure was kept adaptable on purpose, so the design changes that arrived during the build could be answered quickly instead of triggering rewrites.
Finding: the backend team integrates whatever the frontend hands them, and their questions arrive after you leave the room. Decision: treat the handoff as a deliverable of its own, documented and tested.
Challenges
The designs kept evolving while the code was being written. A consistent pattern structure is what let the build absorb changes quickly instead of starting over.
Internal users ran whatever the organization gave them. The CSS had to hold up across browsers, not just the one on my machine.
Analysis, file conversion, coding, debugging, testing, and documentation were one person's job, run in two week sprints.
Healthcare internal systems carry real obligations. Performance, security, and deployment guidelines were part of the delivery, not an afterthought.
Outcome
The redesigned internal site was coded in full and handed to the backend team for integration, with documentation, testing, and bug reports ready. There are no usage metrics to quote from an internal build of that era, and I will not invent any. What this project shows is different from the others on this site. Before I designed experiences for a living, I built them, file by file and line by line, and that has shaped every design role since.