Systems Design · Multi-Platform
Designing for Authority, Not Sameness
How I defined authority boundaries across three user types and three platforms — ensuring each surface reflected the right level of control, not just a consistent look.
Role
Product Designer · Multi-Platform Systems
Duration
~3 years · Mobile & Web
Team
1 designer, 5–8 engineers · Healthcare Workforce
When everyone wanted consistency, I reframed the problem around authority — and changed how the team made decisions.
Challenge
Expand access without inheriting legacy complexity
Key Decision
Defined authority boundaries across platforms
Result
The authority framework became a shared team reference — messaging was scoped as a standalone platform service as a direct result.
At a Glance
When True Helix expanded from an internal staffing portal to a caregiver mobile app and client portal, I reframed platform decisions around authority — who controls outcomes — rather than visual consistency. The result: a framework the team adopted for all subsequent platform work, a messaging capability architected as an independent service, and a PM who began leading every roadmap discussion with ‘who owns this outcome?’ That question didn't start as a design artifact — it became a team habit.
Context
The platform, the people, and the original authority model.
True Helix is a healthcare workforce platform structured around staffing agencies as primary system tenants. It originally launched as an internal staffing portal — the system of record — used by agencies to manage licensed healthcare professionals and their placement across client institutions.
When I joined, a caregiver mobile app already existed, but its scope was intentionally limited. Caregivers could clock in and out of shifts, while scheduling decisions and broader workforce workflows lived exclusively in the internal staffing system.
For caregivers — healthcare professionals clocking in and out of shifts, often on their phones between jobs — this distinction mattered in practice. A confusing interface wasn't just a design problem. It created real friction in the moments that affected their work.
Platform Ecosystem
System of Record
Staffing Portal
Full control · Approvals · Scheduling
Caregiver App
Mobile
Clock in/out · Self-schedule intent only
Client Portal
Web
Oversight · Shift requests · Intent only
Fig 1 — The staffing portal retains full authority while downstream platforms operate with limited, intent-based access.
Emerging Tension
What happened when downstream platforms started making decisions.
As newer platforms began taking on more responsibility, a recurring design challenge emerged: how to expand access and capability for downstream users without inheriting the structure and complexity of the original internal system.
Decisions made at this stage would shape whether future platform features scaled — or fractured — across the ecosystem.
The first major shift came with expanding self-scheduling into the caregiver mobile app. A narrowly scoped tool began supporting decisions that historically lived within the staffing portal.
Caregiver filters are preference controls, not scheduling controls. The distinction matters: caregivers narrow their view, but the staffing portal determines what's actually available to them.
The Pressure to Mirror
Why consistency was the wrong goal.
As this work progressed — and later as the client portal emerged — alignment pressure increased. Stakeholders often pushed for new experiences to mirror the staffing portal's structure and terminology in the name of consistency and reduced internal friction.
Ease of support was a primary driver. Internal teams believed visually similar interfaces would make live troubleshooting easier when assisting caregivers and clients. Because the staffing portal was the long-standing system of record, familiarity felt safer and lowered perceived risk.
Caregivers
Interacted on mobile under time pressure — needed speed and clarity.
Client Users
Engaged periodically, focused on oversight rather than operations.
Despite these differences in authority, pressure to replicate the portal persisted. Aligning tools with unequal levels of control risked obscuring responsibility, creating false expectations, and pushing internal complexity downstream. The tension wasn't whether alignment mattered — it was how to support internal teams without compromising clarity, usability, or long-term system health.
Reframing the Problem
Replacing ‘make it consistent’ with ‘who controls this outcome?’
This moment clarified how I approach complex systems: I pause at inflection points and reframe decisions around responsibility, not surface-level consistency.
In practice that meant consistently naming the same principle across many small conversations — in reviews, in scoping sessions, in moments where the easy answer was “just match the portal.” Each time, the question I kept returning to was the same: does this surface reflect what this user actually controls? When the answer was no, I said so. Not as a design complaint — as a risk flag. That consistency is what eventually shifted how the team framed platform decisions.
Rather than treating the problem as visual or structural alignment, I reframed it around authority. Across the ecosystem, staffing portal users retained final control, while caregivers and clients could initiate intent but not execute outcomes.
Once named, it became clear that mirroring the staffing portal too closely risked communicating the wrong mental model. Consistency wasn't about making every surface look the same — it was about accurately reflecting each user's level of control.
Authority × Intent Matrix
High Authority, Low Intent
Admin / System Config / Compliance Layers — System enforcement & policy control
High Authority, High Intent
Decision and configuration authority.
Low Authority, Low Intent
System-driven activity with minimal direct user initiation.
Low Authority, High Intent
Users can express intent but do not finalize outcomes.
Fig 2 — Mapping authority and intent reveals where platform actions carry real decision weight versus where users express preference without finality.
Authority Flow
Caregiver / Client
Initiates request
System
Routes & validates
Staffing Portal
Approves or rejects · Downstream Final authority
Fig 3 — Downstream users initiate requests, but final approval always flows back to the staffing portal.
Messaging as a Platform Decision
Why messaging became a standalone service, not a bolt-on feature.
Toward the end of my time at True Helix, the team began designing a messaging capability to support communication across staffing teams, caregivers, and clients. Early discussions centered on embedding messaging directly within the staffing portal for speed and familiarity.
The staffing portal, as the system of record, had accumulated significant structural and interaction complexity. Introducing messaging directly into that environment risked compounding design debt and further entangling responsibilities. At the same time, support teams needed speed and familiarity, engineering needed clear ownership, and the business needed forward progress.
Rather than framing the decision as speed versus rigor, I focused on where separation reduced risk — and where alignment could still exist through shared language, concepts, and rules.
Based on prior experience expanding self-scheduling into downstream platforms, I recognized another inflection point. Messaging wasn't simply a portal feature — it was a cross-cutting capability spanning multiple user types and future workflows.
Mapping the admin control layer for messaging revealed six distinct workflows — consent requirements across email and text, opt-in configuration, preference management, and settings navigation. This scope is why messaging couldn't live inside the staffing portal as a feature. A portal feature doesn't require its own authority layer, its own consent logic, or its own configuration surface. A platform-level service does.
My Recommendation
- ✓Treat messaging as a platform-level service, not a portal feature
- ✓Make it accessible to staffing users through contextual entry points
- ✓Avoid inheriting the portal's navigation or accumulated complexity
Messaging: Two Approaches
Embedded in Portal
- ✕Coupled to portal nav
- ✕Inherits legacy complexity
- ✕Hard to extend later
Platform Service
- ✓Independent service
- ✓Contextual entry points
- ✓Future-extensible
Fig 5 — Treating messaging as a platform service avoids coupling it to the portal's legacy complexity.
Impact & Reflection
What the framework changed — and what I'd push further next time.
The authority framework became a shared reference point for the team. When subsequent platform decisions arose — where to surface new features, how to scope permissions, whether to extend existing views or create new ones — the model gave engineers and stakeholders a structured way to evaluate tradeoffs without defaulting to precedent or visual parity.
One concrete shift: after introducing the framework in a product review, the PM began leading with authority questions in roadmap discussions — “who owns this outcome?” became a standing question before scoping new features. The framing moved from a design artifact to a team habit.
Framework Adoption
After a product review, the PM began leading roadmap discussions with authority questions — the framing moved from design artifact to team habit.
Messaging Independence
Messaging was scoped and architected as a standalone platform service — a direct outcome of applying the authority framework to a high-stakes capability decision.
More broadly, platform expansion decisions began accounting more explicitly for downstream users, differing authority levels, and the long-term cost of coupling new capabilities to legacy systems.
Takeaway
As the sole designer embedded in a small engineering team for three years, I learned that the most impactful design work often isn't pixels — it's naming the dynamics that shape product decisions.
The authority framework I developed here isn't healthcare-specific: it applies wherever multiple user types operate with unequal control over shared outcomes. Getting those boundaries right isn't a design preference. It's a responsibility.
Let's Talk
Getting authority boundaries right early saves a lot of rework later.
If you're expanding into new surfaces or user types, I'd love to be part of that conversation.