Statewide Healthcare Service UX Design
Designing patient-facing mobile and web experiences for a complex healthcare service involving consent, account access, family relationships, and more than 30 user roles.
I worked on the initial UX design for a statewide healthcare service intended to connect patients, providers, guardians, and other participants through a shared system for healthcare information, consent, account access, forms, education, help, alerts, and related services.
The larger system needed to support more than 30 user roles with different responsibilities, relationships, and levels of access. My work focused primarily on the patient-facing mobile and web experience, including onboarding, account setup, consent and signing workflows, healthcare information, settings, and relationships between patients, guardians, and children.
The project was still at the proposal stage, so the initial challenge was turning a large set of requirements into a coherent product structure while identifying assumptions and questions that would need to be validated as the project progressed.
I designed the patient-facing portion of the service and helped translate proposal requirements into product workflows and interface concepts.
- Translating a large set of proposal requirements into features and workflows
- Mapping the patient journey across onboarding, account access, consent, information, and ongoing use
- Designing mobile and desktop experiences in Figma
- Defining patient personas and relationships with guardians, children, providers, and other roles
- Designing onboarding and account creation flows
- Designing consent, signing, revocation, education, and confirmation experiences
- Identifying gaps, inconsistencies, assumptions, and future requirements
- Tracking general and role-specific questions for later SME review
- Conducting competitive review with a UX intern
- Creating reusable interface patterns and visual conventions
- Building flows and prototypes for review and future validation
- Considering privacy, sensitive information, and role-based access throughout the experience
The service combined healthcare information, identity, consent, permissions, and relationships among many different types of users.
Patients might interact with the system independently, as part of a family, through a guardian, or in connection with healthcare providers. The experience also needed to work across mobile and desktop contexts, including situations such as patient onboarding, healthcare check-in, reviewing information, and signing or revoking consent.
Requirements were extensive, but not every question had been resolved. Part of the work involved distinguishing what was known from what was assumed, determining what belonged in the initial product, and identifying issues that would require input from subject matter experts or users before implementation.
This was a proposal-stage effort, and I did not yet have direct access to patients, providers, or subject matter experts. I treated the initial designs as hypotheses to be validated rather than assuming that the requirements represented complete user needs.
As I worked through the system, I maintained a detailed set of general and role-specific questions, assumptions, and unresolved issues for future SME review. This allowed the design work to move forward while making the limits of what we knew explicit.
I began by breaking the proposal requirements into features, tasks, users, relationships, and dependencies. Rather than moving directly from individual requirements to screens, I looked at how those requirements connected across the larger patient experience. This helped expose missing states, conflicting assumptions, and places where one workflow depended on decisions elsewhere in the system.
I mapped the experience from a patient's perspective across onboarding, account creation, healthcare interactions, consent, information access, settings, alerts, help, and ongoing use. The journey helped establish a structure for a service that otherwise existed primarily as a large collection of requirements. It also made it easier to identify transitions between mobile, desktop, and provider-facing interactions.
A patient could not always be treated as an isolated account. Guardians, children, providers, and other participants introduced different relationships and access needs. I incorporated these relationships into the flows and identified questions about visibility, authority, consent, and account management that would need to be resolved with subject matter experts.
Consent involved more than presenting a document and collecting a signature. Users needed to understand what they were agreeing to, review relevant information, complete the signing process, receive confirmation, and potentially revisit or revoke consent later. I treated these as connected stages of an experience rather than isolated screens, with particular attention to clarity and the consequences of user actions.
I translated the workflows into mobile and desktop designs in Figma, creating reusable patterns for navigation, forms, information presentation, actions, confirmations, and other recurring elements. As the interface developed, I used the prototype to identify inconsistencies and missing requirements as well as to demonstrate how the proposed service could work as a connected product.
Because direct SME and user access was not yet available, I documented questions as part of the design process rather than silently resolving ambiguity through design assumptions. These included both broad questions about the service and specific questions tied to individual roles, workflows, permissions, and healthcare scenarios. The resulting question set provided a starting point for future SME conversations, user research, and design validation.
With a large requirements set and many interconnected roles, designing screens independently would have made it easy to miss dependencies. I mapped workflows and relationships first so individual interfaces could be designed within the context of the larger service.
The service needed to support many different participants without becoming a collection of unrelated products. I looked for shared structures and patterns while accounting for differences in access, responsibility, and relationships between users.
Consent was a consequential action, so the experience needed to support understanding as well as completion. I separated education, review, signing, confirmation, and later management into a clear sequence rather than treating consent as a single transaction.
The service needed to work across different devices and situations. I considered how tasks and information would translate between personal mobile use and larger-screen healthcare interactions rather than treating one platform as a scaled version of the other.
When requirements raised questions that could not yet be answered, I documented them rather than allowing assumptions to become invisible design decisions. This created a clearer path for later SME review and user validation.
The project produced a comprehensive Figma design for the patient-facing mobile and web experience, including workflows, prototypes, reusable interface patterns, and interaction models covering onboarding, account access, consent, healthcare information, relationships, settings, and related services.
The work transformed a large proposal and requirements set into a more coherent product structure while also identifying gaps, assumptions, and questions that would need to be addressed through future SME involvement, user research, technical review, and implementation planning.
Because my involvement was during the initial proposal and design stage, I was not involved through launch and did not have access to post-implementation usage metrics.
This project reinforced the importance of involving subject matter experts and end users early when designing complex healthcare services. Requirements can establish scope, but they cannot fully describe the realities of patient, provider, guardian, and organizational workflows.
It also strengthened my practice of explicitly tracking uncertainty. When immediate validation is not possible, documenting assumptions and unresolved questions helps prevent provisional design decisions from quietly becoming treated as established facts.
Finally, the scale of the service reinforced the value of establishing shared interaction patterns, technical constraints, and a design library early. With many roles and interconnected workflows, consistency becomes increasingly important as the product grows.