00 / OVERVIEW

Supervisor Case Management Portal UX Case Study

Designing the operational hub between field-based casework and executive reporting, giving supervisors one place to manage staff, monitor cases, review documentation, approve requests, and keep critical workflows moving. The portal also helped supervisors triage case-manager workloads and gain a high-level view of individual and team performance KPIs, supporting more informed coaching, workload management, and day-to-day supervision.

Final supervisor case management portal screens

The Challenge

Supervisors were responsible for maintaining service quality while balancing staff capacity, reviewing documentation, resolving workflow issues, approving expenses, and monitoring case progress. Much of that work was spread across disconnected systems, spreadsheets, email, and manual follow-up. The opportunity was to create one reliable operational workspace that showed what needed attention, why it mattered, and what action should happen next.

Timeline

6 months

Role

UX/UI Lead Designer

Platform

Responsive web-based case management portal

Team

1 product manager, 2 engineers, and 1 UX/UI designer

Status

MVP completed and internally tested; broader launch was paused after program funding ended.

My Contribution

I collaborated with leadership and end users to gather requirements, worked alongside engineers to assess feasibility, and delivered final design recommendations that shaped the MVP.

Project Toolkit

Slack Trello Microsoft Office Microsoft Teams Figma FigJam Adobe Color Adobe Xd InVision Google Drive Google Sheets

01 / DISCOVERY

Understanding the Work Behind the Interface

I examined how information and responsibility moved between case managers, supervisors, billing staff, program leadership, and external reporting systems. The goal was to understand the decisions users made, the context they needed, and where work stalled.

Research Activities

Workflow and operational discovery

  • Reviewed existing supervisor, approval, billing, and reporting workflows
  • Synthesized stakeholder conversations and internal user feedback
  • Mapped workflow triggers, handoffs, dependencies, and failure points
  • Analyzed the information required before users could make decisions

Key Insights

What shaped the product direction

Records existed without enough decision context Supervisors managed exceptions more than averages Workflow ownership was frequently unclear Every role required different actions and access Status needed to explain what happened next
Systems Artifact

Product Ecosystem Map

The supervisor portal sat between the mobile field app and the executive reporting dashboard. Mapping the ecosystem clarified where information originated, which users acted on it, and how case activity eventually contributed to billing, compliance, and program reporting.

Ecosystem map connecting the field app, supervisor portal, reporting dashboard, users, and external systems
Research Artifact

Finding the Highest-Risk Workflows

I documented the trigger, primary user, current friction, operational risk, and design opportunity for each major workflow. This helped the team move beyond a feature list and identify where workflow delays created the greatest risk for clients, staff, billing, and compliance.

Operational workflow inventory showing users, triggers, friction, risk, and design opportunities
Role Analysis

Jobs and Decision Needs

Rather than relying on broad personas, I defined each role by the job they needed to complete, the decisions they made, the information required before acting, and the consequences of a missed or delayed decision.

Jobs and decision needs matrix for supervisors, program managers, billing staff, and administrators

Defined Opportunity

Supervisors need one reliable place to understand operational health, identify work requiring intervention, and complete critical actions without losing the case, staff, billing, or workflow context surrounding each decision.

02 / IDEATION & DESIGN

Designing the Operational Layer

The portal was more than a collection of pages. It connected cases, clients, staff, notes, services, tasks, documents, approvals, billing, and reporting. I modeled those relationships before defining navigation and screen-level interactions.

Design Flow

From system structure to repeatable interaction patterns

Model
Permissions
Prioritize
Workflow
UI System
Architecture Artifact

Mapping the System Beneath the Screens

A change to one record could affect several workflows. Approving a case note, for example, could update the client record, move a billing item forward, affect staff performance reporting, and eventually appear in executive reports. The object model made those dependencies visible before interface decisions were made.

Domain model showing relationships between clients, cases, staff, notes, tasks, services, documents, requisitions, and reports
Governance Artifact

Designing Role-Based Access

Permissions affected navigation, visible information, available actions, and workflow ownership. I defined who could view, create, edit, assign, return, approve, and administer each object so access control became part of the user experience rather than a final technical layer.

Roles and permissions matrix for case managers, supervisors, billing staff, program managers, and administrators
Product Strategy

Prioritizing the MVP

I used risk-to-value prioritization to identify the workflows that carried the greatest operational consequence and user value. The MVP centered on supervisor actions, staff workload, documentation review, case-plan and requisition approvals, case assignment, role-based access, and clear status patterns. Lower-risk customization and advanced forecasting remained future opportunities.

Risk-to-value prioritization map for supervisor portal workflows

Hero Workflow: Case Note Review

Connecting field documentation, supervisor oversight, billing, notifications, and audit history

Case note review became the strongest workflow for demonstrating how the system connected roles and data. Supervisors could open a submitted note from the action queue, review the client and service context, identify missing information, approve or return the note with feedback, preserve the decision history, and trigger the next documentation or billing step.

Artifact 07 / Interaction Design

Case Note Review Wireflow

wireflow for reviewing, approving, or returning a case note
Interface System

Designing for Dense Operational Work

I used reusable status badges, data-table patterns, filters, review panels, validation messages, and empty, loading, error, confirmation, and permission-restricted states. The goal was to make complex information easier to scan without hiding the context needed for responsible decisions.

Component and state inventory for the supervisor case management portal

Final Experience

Organized around user outcomes

See what requires attention Understand the full case context Review documentation in context Keep approvals moving Balance team workload Track ownership and history
Final UI Artifact

Supervisor Portal Screens

Final supervisor portal screens showing action queue, case detail, review workflow, approvals, and staff workload Final supervisor portal screens showing action queue, case detail, review workflow, approvals, and staff workload

03 / VALIDATION

Testing the Workflow, Not Just the Screens

Because the product reached MVP and internal testing rather than public launch, validation focused on realistic supervisor tasks, system clarity, workflow ownership, and whether users could act without relying on external guidance.

Testing Scenarios

Representative operational tasks

  • Identify the item requiring the most immediate attention
  • Review and return an incomplete case note
  • Approve a requisition with supporting documentation
  • Find a staff member with capacity for a new case
  • Determine the status and owner of an unresolved action

What Changed

Feedback translated into design decisions

Added current owner and next-action labels Made notifications more specific and actionable Prioritized exceptions above broad analytics Strengthened status and decision history Clarified return-for-correction feedback
Validation Artifact

Creating Traceability From Evidence to Design

One of the biggest issues that came out of testing was scale. If supervisors had to approve every case note, some could be reviewing close to 200 notes a day, which was not realistic. That pushed us to rethink the approval logic and move more of that control to the case-manager level. When a case manager was onboarded, supervisors could determine how much oversight they needed, allowing strong performers to submit notes and requisitions without unnecessary friction while newer or underperforming staff could have more review built into their workflow. At the same time, supervisors told us they needed a much clearer 40,000-foot view of team performance. We worked on a KPI system that made it easy to see which cases were being recertified, which were meeting milestones and goals, where spending was running high, and which case managers were consistently performing well or falling behind. The goal was to give supervisors and program managers enough visibility to step in where it mattered without turning the portal into another layer of administrative work.

Usability findings and severity matrix connecting evidence to design responses Usability findings and severity matrix connecting evidence to design responses Usability findings and severity matrix connecting evidence to design responses

04 / REFLECTION

Designing for Exceptions

This project changed how I think about enterprise UX. The real challenge was not simply organizing a large amount of information; it was making responsibility, context, risk, and system status clear as work moved between people. Designing around exceptions, role-based permissions, and connected system relationships helped turn the portal from a passive dashboard into a tool supervisors could actually use to make decisions and keep work moving. It also strengthened my ability to translate complex requirements into a scalable product model, prioritize the workflows with the greatest operational risk, and design across frontline, supervisory, billing, and executive needs. A broader pilot would be the next step to validate performance, accessibility, permissions, integrations, and configurable workflows across additional programs.