Product Strategy · Stakeholder Alignment
When Building Isn't the Answer
How I worked within a fast-moving product environment that kept prioritizing new features over foundational work — and what I did to slow that down.
Role
Product Designer · Cross-functional Collaboration
Duration
~3 years · Mobile & Web
Team
1 designer, 5–8 engineers · Healthcare Workforce
Three years in a fast-moving team taught me that restraint is a design skill — and knowing when not to build is as important as knowing how.
Challenge
New features and client demands consistently won over foundational work
Key Decision
Advocated for sequencing, integration depth, and foundational cleanup — often against the grain
Result
The PM began leading roadmap discussions with 'what does this displace?' — sequencing became a standing question before scoping new features
At a Glance
When I joined True Helix, the first thing I noticed was that the staffing portal — the system of record at the center of everything — needed attention. It had grown by addition over the years: features bolted on, navigation items accumulated, complexity compounded. I started a redesign immediately. Three years later, that work had never been seriously revisited. That's the real story of this case study. Not a framework I invented, but what it actually looks like to advocate for foundational work in an environment where urgency almost always wins. The concrete example that captures it best: when engineers pushed to ship a tap-to-view interaction with no visible affordance, I made the case for a Details indicator — not for aesthetics, but because an undiscoverable interaction generates caregiver frustration, support tickets, and eventual rework. The deadline was met. The affordance shipped with it. That kind of call — knowing when to slow down and why — is the thread running through this case study.
The Environment
Three platforms at three different stages of maturity.
True Helix ran on three platforms: an internal staffing portal used by agency staff to manage caregivers and shifts, a caregiver mobile app, and a client portal for healthcare facilities. Each was at a different stage of maturity.
The caregiver app and client portal were actively being built and modernized during my time there. The staffing portal was the original system — the one everything connected to, the one that had been running for years before I arrived. It was functional, deeply embedded in daily operations, and increasingly messy.
The contrast wasn't just visual. The staffing portal's Admin dropdown had accumulated 18 menu items. When a new item needed to be added, I proposed consolidating the menu while we were in there. The answer was no — there wasn't time. So the 19th item was added instead.
The Pattern
Why new work kept winning over foundational work.
The dominant team mindset was: once something ships, it's done. Move on to the next thing. Client requests, stakeholder priorities, and competitive gaps drove the roadmap — and those forces almost always pointed toward new, not better.
This created a recurring dynamic. The staffing portal kept getting new features added to it rather than getting the underlying attention it needed. The caregiver app and client portal were being modernized while the foundation they connected to was aging. New work kept winning over foundational work, not because anyone made a deliberate choice to let the portal deteriorate, but because urgency is loud and maintenance is quiet.
The result was an ecosystem with three relatively modern products orbiting one increasingly messy legacy system. Client-facing features got resourced. Portal cleanup didn't.
There was also a consistent pattern with mobile updates. Work on the caregiver app would begin, then get deprioritized mid-stream when a client escalated or a new feature was scoped. Client needs almost always took priority over in-progress work. The app improved — but more slowly, and less coherently, than it could have.
The Redesign That Kept Getting Deferred
Important enough to start, never urgent enough to finish.
When I joined, there wasn't an immediate project ready for me. I used that time to do what felt obvious: start mapping what a staffing portal redesign could look like.
I explored three calendar layout options, worked through interaction specs, documented edge cases — what happens when a day has 20+ shifts, how re-assignment flows should work, how filter behavior could be simplified.
The work got shelved. Not because it was wrong, but because there was always something more urgent. A client portal feature. A mobile initiative. A stakeholder request. The redesign became something I'd return to when things quieted down — and things never quieted down enough.
Three years later, the portal still looked the way it had when I arrived, plus the features that had been added in the meantime.
Approach in Practice
Knowing which battles were worth fighting — and which weren't.
Working in this environment came down to one thing: knowing which battles were worth fighting.
Not every problem warranted the same response. The Admin dropdown had 19 items when it needed consolidation — but the timing wasn't right and the downstream cost of leaving it messy was manageable. I noted it, named the trade-off, and moved on. The Details affordance was different. An undiscoverable interaction doesn't just create friction — it generates support tickets, caregiver frustration, and eventual rework that costs more than the time saved by skipping it. That one was worth the pushback.
The distinction wasn't about design principles. It was about cost. When the cost of getting something wrong was low, I deferred. When the cost was real and compounding, I held the line.
I stopped asking “should we build this?” and started asking “what does doing this well actually require?”
Not every request needed the same response. Over time I settled into three modes:
Response Modes
Full Commitment
When: High integration need, clear long-term value, low displacement cost
How: Scope deeply, align with existing architecture, plan for extensibility
Lightweight Exploration
When: Uncertain value, high urgency, risk of shallow execution if rushed
How: Prototype or scope narrowly, validate before committing full resources
Deliberate Deferral
When: Valid request, but wrong moment — displaces higher-priority work
How: Name the trade-off explicitly, document for sequencing in next cycle
The Admin dropdown was a Defer. The Details affordance was a Build. The staffing portal redesign was perpetually stuck between Explore and Defer — important enough to start, never urgent enough to finish.
What Shipped
The wins that did make it through — and the one that didn't.
Despite the environment, things did get better. The caregiver app improved meaningfully over time. One example:
The earlier design surfaced all shift information inline with no way to access additional detail. As the platform grew, new information became necessary — staffing firm attribution, additional shift context — and the view couldn't absorb it without becoming unmanageable. The updated design introduced a Details affordance that made additional information explicitly accessible, and a hierarchy that surfaced only what caregivers needed at a glance.
The client portal went from nothing to a fully designed, component-documented product with a consistent design system.
These shipped. The portal redesign didn't. That's the honest account.
Impact & Reflection
What changed, what didn't, and what I took from it.
The PM began leading roadmap discussions with “what does this displace?” — sequencing became a standing question before scoping new features.
That's a real outcome. It's also a partial one. The staffing portal is still what it was. The redesign I started in my first weeks never got the runway it needed. Some things you can change in an environment like this, and some things you can't — and learning to tell the difference is its own kind of skill.
The broader lesson
Not every environment gives foundational work the runway it deserves. The skill isn't just knowing what should change — it's knowing which fights to pick, when to hold the line, and when to let something go.
Three years of that taught me more about design judgment than any single project could.
Let's Talk
If the hardest design problems aren't visual.
If you're working in an environment where restraint, sequencing, and advocacy matter as much as craft — I'd love to talk.