Din Psykolog

Final design

What I have done

Project lead from research to implementation, owning the design process in an OKR-driven organization where design work is aligned to business objectives. Defined data tracking points together with the tech team and followed up on performance.

Experimenting with AI tools for prototyping: Claude, Stitch and Cursor.

Complete user journey mapping with data analysis and workshop facilitating to find ideas of improvement. Design of top 4 prioritized improvements.

Analysis of data to drive design decisions, from A/B-tests, funnels, heatmaps, interviews and surveys, in collaboration with the product owner.

Interviewing users and leading usability tests.

Testing as a part of implementation.

Internal presentations, info graphics, illustrations, interactive onboarding material and UX-writing.

Design of caregiver platform: edit, delete and archive patient functionality in chat, google calendar integration and patient review visibility. Iterations of the patient and caregiver platform as well as the landing page in Figma.

Supportcenter and troubleshooting guide

Before

After

Designing for accessibility. Healthcare puts accessibility requirements on the products it uses, but the stronger argument came from who these screens are for. Someone opening the Support Center is usually not browsing. They are a few minutes from a session with their psychologist and their microphone will not work. That is a bad moment to ask anyone to interpret an interface, so every decision below was about removing one more thing the user has to work out for themselves.

Troubleshooting Guide

Helping patients recover from camera and microphone issues before a video appointment.

Design for the emotional state, not just the task. Users hit this guide moments before (or during) a missed appointment, stressed and time-pressured. That reality shaped every decision: short steps, one clear action at a time, and reassurance up front that a missed call could be rebooked at no extra cost. Lowering anxiety was as important as solving the technical problem.

Remove every decision the system can make for the user. Instead of asking people to identify their browser and device while panicking, the guide detects what's blocked, which browser, and which device automatically, and surfaces the right instructions immediately. Manual override stayed available for the edge cases where detection is wrong, but it's never the default path.

Let research set the hierarchy. Rather than listing every possible issue equally, I leaned on existing interviews, survey data, and the tech team's input to learn that camera/mic permissions were by far the most common failure. The most frequent and fastest-to-solve problems lead; Wi-Fi and audio-quality issues sit lower as secondary links. Ordering by real frequency is what makes a guide feel effortless.

Progressive disclosure keeps a stressful flow calm. Steps reveal one at a time: browser permissions first, then device settings, then restart or try another device, with a large CTA moving the user forward only if the previous step failed. Pairing each step with a screenshot and an orange highlight on exactly where to click removed ambiguity.

Accessibility. Screenshots with the target marked. The troubleshooting guide shows a picture of each step with an orange square around exactly where to press. This is not a formal requirement anywhere, and I included it because the requirements are a floor rather than a goal. Written instructions assume you can hold a sequence in your head and map it onto your own screen. If you are stressed, or tired, or simply not confident with the device, that assumption breaks first. Showing the target instead of describing it removes the step where things usually go wrong.

Constraints are part of the brief.Because the service runs on web rather than a native app, permissions behave inconsistently (sometimes in-browser, sometimes in device settings). Designing within that limitation, and making the inconsistency invisible to the user, was the core challenge.

Support Center

Turning a single support email and scattered FAQs into one organized hub.

Benchmark before designing. Market research made the best practice clear: a single categorized hub beats FAQs spread across the product. Starting from a proven pattern, then adapting it (category structure plus icons for quicker scanning), gave the work a solid foundation rather than a guess.

Placement is a design decision, and it should be testable.I moved the hub into the service for logged-in users instead of leaving it on the marketing site, based on a hypothesis: logged-in users need support most (invoices, rebooking), and the old flow forced them into a new tab that was hard to navigate back from. I kept a separate, new-user-focused FAQ on the landing page so each audience got content matched to its context.

Validate hypotheses with data, not belief.Working with the tech team, I set up tracking on where users entered the support center from. A month after launch, the in-service entry point was a clear majority, confirming the placement decision and the assumption behind it. Closing the loop with measurement is what turned a reasonable guess into a defensible decision.

Accessibility. State that is readable without color. In the Support Center the selected category is marked with a color change, and the contrast between the selected and unselected state does not meet WCAG 1.4.3. I could not fix that with color alone, so I made sure the state was carried by three other things: the chevron rotates to point down, the questions for that category expand underneath it, and any previously open category collapses. The selected state is legible even if the color difference is invisible to you, which is what WCAG 1.4.1 asks for.

I would rather have solved it properly. The design system I was working in is built on light colors and a light mode only, and it did not contain a selected state with sufficient contrast. I prototyped one using the dark green with white text, which would have passed comfortably, but the dark green already carried a different meaning across the platform and using it here was voted down as inconsistent. That was a fair call for the product as a whole, and it left a gap in the system rather than in this screen.

If I were continuing the work, this is what I would push for first: a defined selected state in the design system that meets contrast requirements, rather than every designer solving it locally.

Accessibility. Icons always carry text. Categories are labeled, not just illustrated, and status messages like "Din mikrofon är blockerad" pair the icon with the sentence. An icon on its own asks the user to already know what it means, and someone using a screen reader gets nothing from it at all.

Accessibility. Links you can see without color. Links are underlined rather than only colored, so they are distinguishable to someone who does not perceive the color difference.

Caregiver platform designs

Editing, deleting and archiving in the caregiver platform

Giving caregivers safer, more flexible tools to manage many patient conversations.

Balance user flexibility against patient safety with clear constraints. Caregivers wanted to fix or remove messages sent in error, but unrestricted editing is risky for patients. The compromise: messages stay editable/deletable for one hour, deletion is blocked once the patient has read the message, and tooltips explain these limits before the user acts. The constraint is the safety mechanism.

Borrow mental models people already trust. Marking edited or removed messages with "Redigerad" or a deletion notice follows familiar messaging conventions (e.g. Messenger), so caregivers and patients understood the behavior instantly, with no learning curve and full transparency about what changed.

Design for the real workflow.Caregivers juggle many patients, so I added "mark as unread" after feedback that they sometimes open the wrong patient's message and lose their place. Small affordances that match how people actually work often matter more than big features.

Better structure can be its own feature.The archive function, a dedicated tab in the chat list plus an archive action on the patient profile, solved an information-architecture problem: previously every "inactive" patient (whether inactive two weeks or several months) lived in one undifferentiated tab. Letting caregivers archive patients who are "lost" per routine restored a meaningful, manageable structure.

5-Star Reviews on the Caregiver Page

With reviews

Empty state

Edge cases and empty states are part of the happy path. I designed the logic to look back up to three months when the latest month has no 5-star reviews, plus a dedicated empty state for caregivers (often new ones) with none yet. Planning for "what if there's no data" up front kept the feature from feeling broken for the people who need encouragement most.

Protect privacy even in positive features. Because the reviews are anonymous, I showed only month and year rather than exact dates, removing a detail that could help identify a patient. Safety considerations don't pause for feel-good features.

Emotional design can serve a real goal. A motivating title ("Såhär påverkar du") and visible star ratings were intentional choices to show caregivers their impact and reinforce the behavior. Design in service of motivation, not just information.

Reflection

The clearest signal came from the Support Center placement. A month after launch, tracking showed that the in-service entry point was used by a clear majority, confirming the hypothesis behind moving the hub out of the marketing site and into the service.

What I would follow up on is whether the troubleshooting guide actually reduces missed appointments, and how well the automatic detection holds up across the full range of browsers and devices in the wild. That is the part of the design leaning hardest on assumptions I was not able to test in full.

Want to see more of my UX work?