Healthcare Appointments & Consents

Helping residents manage their healthcare appointments more clearly and confidently through their phones.

Context & Scope

I worked on a public-sector health app in Sweden, focusing on the consent management flows. My goal was to make it easy for residents to view, give, and revoke their healthcare consents. This was a crucial part of the service, both for building trust and meeting legal requirements. One of the biggest challenges was designing for a broad user base, including both tech-savvy individuals and elderly users who might not feel comfortable navigating digital tools. I focused on making the experience as simple and reassuring as possible, no matter who was using it.

Users & goals

The people using the app were regular residents in southern Sweden, and many of them were older adults with different levels of comfort using digital tools. My goal was to make the consent section feel so clear and straightforward that anyone could use it with confidence. That meant working with plain Swedish, using clear and supportive visuals, and making sure the design felt accessible. I wanted users to understand exactly what they were agreeing to — and feel just as comfortable changing their mind if they needed to.

As part of my research looked at how other services and products  approach consent within their digital services. I explored different brands and services from different sectors. I discovered that banking services was a good source of inspiration since digital consents are also one very important part of their services. But I also looked at everyday apps like to spot familiar patterns. This helped me see what tends to work well — like clear toggle switches, simple “Accept” or “Deny” choices, and a confirmation step to give users peace of mind. It also showed me what to avoid, like hiding consent options deep in the settings. Insights from these helped me get a good idea to shape the first outline of our user flows.

Prototyping & testing

Once I had a good sense of the flow, I started sketching it out and built interactive prototypes in Figma. I focused on the core tasks, like letting users see what consents they had already given and how to respond to new requests.

When the prototype felt realistic enough, we tested it with a small group of target users, including older adults. We used a mix of task-based testing (like “Try revoking a consent you’ve already given”) and more open-ended exploration. We asked users to think out loud while using the prototype so we could hear how they were interpreting things in real time. These sessions were incredibly valuable — they helped us spot pain points early and make the flow clearer before moving further into development.

Prototype used for early testing

User testing surfaced several pain points we hadn’t fully anticipated. People got confused by certain parts of the flow, and some of the language and layout choices didn’t come across the way we intended. I gathered the key issues, iterated on the design, and got feedback from other designers along the way to refine the solutions. Here’s a breakdown of what we found — and how I responded:

  • An unexpected step in the flow
    Testers were thrown off by an extra confirmation screen that showed up after clicking “Respond.” One person said they “didn’t expect an intermediate step after choosing to respond.”
    What I did: I removed the unnecessary screen so users would go directly to the accept/deny options. This made the flow faster and easier to follow.

  • Unclear button hierarchy
    The original layout had too many buttons with similar styling, which made it unclear what to tap first.
    What I did: I simplified the layout and clearly highlighted the main action, like “Give Consent,” while visually downplaying secondary options. This helped guide users through the process without hesitation.

  • Confusing labels and categories
    Some of the category names for the different consents were too technical. Users weren’t sure what they were agreeing to.
    What I did: I rewrote the labels in plain Swedish and added short, helpful descriptions below each one. I also introduced icons to make categories easier to scan at a glance.

  • Poor visual affordance
    Some interactive elements didn’t look clickable. For example, the accept/deny choices were just text links at first, and users often missed them. One tester said that “an icon clarifying ‘approve’ vs ‘deny’ would make it easier.”
    What I did: I turned those into proper buttons with familiar icons — a checkmark for accept and a cross for deny. I also made sure all toggles and links followed standard patterns so it was always clear what could be tapped.

  • No confirmation after taking action
    People weren’t always sure if their changes had gone through. One person said, “It’s good to get clear feedback that your choice has been saved.”
    What I did: I added a confirmation message along with subtle UI feedback — like a green checkmark and a note saying “Your preference has been saved.” It was a small detail that made a big difference in building confidence.

After each round of updates, I did quick sanity checks with users and shared the changes with the design team for peer review. Over time, the flow became noticeably smoother. In later tests, users described the experience as “simple” and “clear,” which was exactly the goal.

Prototype from project
Prototype from project