Case StudyOptum Serve
A command-level portal giving military leaders and unit coordinators visibility and control over readiness across their organization.
Where the Service Member Portal is built for one person managing their own readiness, the Client Portal is built for the people responsible for everyone else's: unit coordinators requesting services on behalf of their members, Service Component leads tracking budget and utilization, and approval authorities clearing requests before they reach the field.
Overview
A command-level view of readiness, built for the people accountable for it.
The Client Portal is the leadership-facing half of RHRP’s Electronic Scheduling Capability, and the companion product to the Service Member Portal. Where a service member only needs to see their own status, a unit coordinator, Service Component lead, or approval authority needs to see readiness across an entire population, request and schedule services on someone else’s behalf, and approve or deny the requests that come back up the chain.
My role was to lead design across the full leadership experience: running workshops with directors and stakeholders to map the command hierarchy and its handoffs, translating three very different personas into one coherent product, and designing the dashboard, roster, request, and approval flows that ship as the Client Portal today.
Focus: Population-level readiness visibility, delegated scheduling, approval workflows
Scope: Persona research, UX exploration, dashboard and workflow design
Who It's For
Chris, Patricia, and Alan
Unlike the Service Member Portal, this product had to work for three distinct personas at three different altitudes of the same organization, each with their own goals and their own definition of “readiness”:
- Chris, the unit coordinator — oversees medical readiness for a large unit. Requests and schedules services and group events for his service members, tracks completion, reconciles records across systems, and chases down readiness gaps before they become deployment blockers.
- Patricia, the Service Component lead — owns the RHRP program for her component. Allocates funding, monitors utilization, appoints approval authorities, and reports program status to DHA using real-time data rather than static reports.
- Alan, the approval authority — sits in the Surgeon’s Office and approves service orders. Needs confidence that vendors are delivering quality services and that funding is supporting actual medical readiness, not waste from no-shows and late cancellations.
Existing UI
User Research
Personas: Chris, Patricia & Alan
Process Flow
Main Problems
The task was to give leadership a way to act on readiness at scale, not just observe it.
- Coordinators had no unified view of their unit’s readiness — status lived across disconnected systems and phone-first scheduling, so gaps surfaced late, if at all.
- Requesting a service on behalf of someone else was a manual, untracked process with no visibility into where a request stood or who needed to act next.
- Component leads had no drill-down path from command-level readiness to the unit or individual level, making it hard to justify budget decisions with real data.
- Approval authorities had no consolidated queue — service orders and group events needed a clear approve/deny workflow tied to budget and vendor accountability.
- Every persona needed the same underlying data, but at a different level of detail and a different point in the workflow.
Capabilities
- Readiness Dashboard & Insights — unit and population-level readiness status, gaps requiring action, and drill-down from command-level views into unit-level detail.
- Personnel & Roster Management — view and manage assigned service member populations, track individual requirements, and reconcile records across military and contractor systems.
- Events, Scheduling & Requests — create readiness events, submit and track service requests, and monitor scheduling progress from submission through completion.
- Approvals & Workflow Management — review and approve requests, track pending actions, and support budget oversight and vendor accountability.
Unit Readiness View
Exploration
Getting the unit view right
Early versions of the unit view leaned on the same red/amber/green tiles from the Service Member Portal, but a coordinator managing dozens of people needed more than a color — they needed to know who was overdue, who had a request pending, and who just needed a reminder, at a glance and without opening each record individually.
Unit View: Before & After
Requesting on someone else's behalf
The core workflow unique to this product is delegated scheduling: Alan isn’t requesting a service for himself, he’s requesting it for a member of his roster. That meant every step of the request flow needed to carry the service member’s context with it — who they are, what they’re due for, and why — so the coordinator never has to leave the flow to go verify something.
Request Services Flow
Requesting a Service
.BbVxABc2_1KDJUH.webp)
Approvals as accountability
Alan’s needs pushed the approvals workflow in a different direction than either coordinators or leads: every request needed a clear paper trail. We designed the approval queue so an authority could see the full context of a request — who it’s for, what it costs, why it was submitted — before deciding, rather than approving blind or having to hunt down details in a separate system.
Service Request Approval Flow
Approving a Service Request
.BHQjQKZ7_Zl2806.webp)
.DKvmVVnC_2sxNEF.webp)
.8oy2iaXz_1Od81E.webp)
.BSLGP4qP_Z2lY2Tx.webp)
.BVIYOb-b_bTxrz.webp)
How We Worked
Refinements
If I wasn’t desigining, I was in refinements. The team, technical product managers, designers, developers, architects, gathered together for extended sessions to workshop, brainstorm, and work through any and all technical problems from broad ideas, all the way down to the details in order to make it feasible.
Pain Points
Instead of just MVP, we separated features into MVP, Post Award, and Post Go Live. During refinement, as we were thinking of ideas and solutions, we often needed to scale back so that what was being developed met the contractual requirements. The ideas that would be great for the users would be kept in Post Award or Post Go Live so that those ideas could be developed at a later time in order to meet the time constraint.
Dev Team/Architects
Software architects were always in our refinements so they were always aware of the needs and the plans. After design handoff, developers were fully aware of what needed to be done beforehand; the foundation was already in place. We went to UAT frequently in order to make sure that the developed experience was in line with the intended vision.
Final Design
- A single unit view that surfaces who’s overdue, who’s coming due, and who has a request in flight — without opening individual records.
- A delegated request flow that carries the service member’s context through every step, built for coordinators acting on behalf of their roster.
- An approval queue that gives authorities the cost and justification for a request up front, closing the accountability gap around vendor spend.
- One data model serving three altitudes of the same organization — unit, component, and command — instead of three separate tools.