Timeline
Stalled 2024–2026 · recovered 2026
My Role
Principal Product Designer — end-to-end across web/mobile
Impact
~1,500 inherited design frames → ~300 shipped · 2-year stalled build in production in one month · role-based permission built into the system
Two years of design work that couldn't ship. One month to production.
Challenge
Caily had two years of design behind it and nothing in production. The inherited file held roughly 1,500 design frames across mobile and web. Not 1,500 screens — every state of every screen had been drawn as its own artboard. Empty form, filled form, error state: three hand-made frames where one component with defined states would do. That is why the build had stalled. No frontend team can implement and maintain that surface, and nobody could hold the product in their head well enough to say what "done" meant. Underneath the volume was a second problem: five distinct roles shared one product with no shared system and no permission model in the design. Facility staff at three levels — member, admin, and owner — plus caregivers, family members, and a separate role managing communication across the platform. Each view had been designed independently, so the same record looked and behaved differently depending on where you opened it. The real question wasn't how it should look. It was why design kept producing artifacts engineering couldn't ship.
MY ACTIONS
1. Cut the surface by 80%. I mapped the inherited frames against the actual user scenarios and found the same flows redrawn with cosmetic differences. Consolidating them into shared components with defined states took the product from ~1,500 frames to ~300 — same functionality, a fifth of the surface to build, test and maintain. 2. Audited against the API, not the mockups. Before redesigning anything I checked every proposed screen against what the backend could actually return. That is where the stall came from: fixing the visual layer without fixing the data model would have produced another two years of unshippable work. 3. Built the permission model into the design system. Three staff levels, caregivers, family, and chat management — one record, different visibility per role. HIPAA makes this a legal requirement, not a preference. Permission became a property of each component rather than a per-screen decision, so a caregiver's view and a family member's view are the same component under different access, not two designs to maintain. 4. Wrote design contracts with engineering. Component architecture agreed with the frontend team, so a screen is assembled from known pieces rather than interpreted from a mockup. That is what took the project from stalled to shipping in weeks.
Solution
The product went to production in about a month and is live at caily.com — after roughly two years without a release. Roles now run on one design system with permission built in. Engineering ships from components instead of re-interpreting mockups screen by screen, and ~300 screens carry what 1,500 frames couldn't.
What I'd Do Differently
I ran the API audit first and it saved the project — the existing designs described a data model the backend couldn't return, and no amount of visual work would have fixed that. But I presented it as a design finding, in design language, and it took two weeks to get the team to act on it. Framing it from the start as a delivery risk with a cost attached would have moved faster. The analysis was right; the packaging cost me time.