Statewide Healthcare Service UX Design

Translated requirements into user workflows

The work began with dense proposal requirements that described what the service needed to support but did not necessarily define how those requirements should become a usable product. Rather than treating the requirements as a checklist of screens, I mapped them into product areas, user tasks, relationships, permissions, and interaction flows. For each area, I considered what users needed to understand, what actions they could take, what information was required at each stage, and where the experience needed decision points, review steps, confirmation, or support. This helped turn a large body of requirements into a more coherent model of how the service could actually work.

Mapped the patient journey before designing every screen

I created journey maps and workflows for patient personas, including a primary path through the service. The flows covered how a patient might enter the product, complete onboarding, review information, fill out forms, receive education, review and respond to consent requests, manage settings and alerts, get help, and understand the result of completed actions. The workflow diagrams also functioned as early structural wireframes. They made it possible to see relationships between different parts of the service and identify missing steps before every interface was fully designed.

Patient journey mapping showed how account setup, forms, education, consent, and confirmation connected as one experience.

Designed one service around 30 roles and different permissions

The broader system needed to support 30 distinct user roles rather than a small set of simple personas. Patients, guardians, caregivers, providers, and other authorized users could have different responsibilities, relationships, and levels of access. I worked through these differences to understand what each type of user might see, what actions they could take, and where the interface needed to respond differently based on role and relationship. The goal was to avoid treating every role as an entirely separate product. Instead, the design established a shared application structure that could present different information and actions according to role and access. This made permissions and relationships part of the product architecture rather than something added only at the individual screen level.

Made consent flows explicit and deliberate

Consent was not a single button or screen. Users needed to understand what they were reviewing, what action they were taking, and what happened afterward. I designed flows that accounted for reviewing information, signing or declining consent, confirmation, and later revocation. Breaking these actions into clear stages helped make consequential healthcare decisions more visible and understandable within the larger service experience.

Used prototypes to evaluate the service as a connected experience

Interactive Figma prototypes made it possible to move through the product from a user's point of view rather than reviewing screens individually. Following complete flows exposed inconsistent navigation, missing states, unclear labels, and places where the information architecture needed refinement. This was especially useful because the service covered many different tasks and role relationships. Prototyping helped reveal whether those tasks felt like parts of one connected product rather than a collection of unrelated features.

Designed across mobile and desktop

Patient tasks needed to remain understandable regardless of the device being used. I designed mobile and web experiences around the same underlying workflows and product structure so that moving between form review, consent actions, account management, support, and other tasks did not require a fundamentally different mental model on each platform.

Patient forms and consent tasks used consistent structures across mobile and web.

Improved consistency across the experience

I refined typography, color, sizing, layout patterns, and repeated interface elements to make the product feel more like one system. Consistency was particularly important in this context because users needed to recognize what information they were seeing, understand what was being asked of them, and distinguish routine actions from more consequential healthcare and consent decisions.

Led design work while supporting a junior designer

As lead designer, part of the work involved creating enough structure for another designer to contribute effectively. I guided a UX design intern through competitive and comparable product review and related design work, while maintaining consistency across the broader service and keeping the work aligned with the requirements, workflows, and product direction.

Designed the structure to accommodate future growth

The immediate work needed to support proposal and MVP needs, but the product was being conceived as a broader healthcare service. I considered how the information architecture, workflows, role model, and reusable interface patterns could accommodate additional features and scenarios without requiring the experience to be reorganized around every new requirement.