Digital Care
Giving municipalities self-service in a platform where every minute out in the field counts.
Summary
Digital Care (DC) is Sensapp's device management platform, where both internal and municipal staff manage devices, alarms, and support. I was tasked with improving DC both visually and functionally, with the chance to run a full Design Thinking process. Four interviews with five people across three municipalities pointed to self-service as the strongest recurring need. I built an HTML prototype with the help of Claude, tested it with the same participants, and delivered a requirements specification for the team to build on.
The challenge
Digital Care is a device management platform (DMP) with three types of users logging in: Sensapp's own staff configuring devices and resolving support cases, administrative roles in municipalities overseeing their residents' devices, and home-care staff in the field responding to alarms and helping with installation. I was tasked with improving DC both visually and functionally.
Behind the brief was a business idea: shift more responsibility onto the municipalities themselves to resolve the most common support cases, easing the load on Sensapp's support team and making municipalities more self-sufficient. Unlike Bubblan, I had direct access to all three user groups here, letting me run a complete Design Thinking process from empathy through to usability testing.
Interviews and insights
My manager gave me contact details for relevant people in three municipalities that were already customers. This became four interviews with five people between April 1 and 15, conducted over Teams from an interview guide approved by leadership, kept open enough to surface both concrete pain points and new requests.
The clearest and most recurring theme was self-service: being able to change operator during coverage issues, toggle alarm clocks on and off, remove old devices, and adjust door-alarm and camera timing while out on-site with a resident. Other themes were that the homepage showed something was wrong but not what or how to proceed, and that devices were listed by serial number instead of the resident's name, making them hard to find in long lists.
What we learned
The wish for self-service wasn't an abstract desire for more control, but tied to concrete situations where staff stood on-site with a resident and couldn't solve the problem there and then. The support they got from Sensapp was described as very good, but didn't solve the immediate, in-the-moment need.
Insight
Observation
All four interviews, regardless of municipality or role, asked for the same kind of self-service features tied to specific field situations, not general control over the system.
Why it mattered
Self-service turned out to be a win-win: the municipality becomes faster in the field while Sensapp's support gets freed up for more qualified cases.
Design implication
The prototype prioritized a clearer information architecture, a dashboard showing what needs attention, and direct paths from anomaly to self-service action.
From insight to prototype
Based on the insights, I built a prototype for an upgraded DC focused on the clearest problems: self-service, better overview, and a shorter path from anomaly to action. I built the prototype not in Figma but in HTML, with help from Claude, Anthropic's AI model, something I highlight myself as decisive in letting me complete the full cycle from interview to usability test within the internship period.
I built in a new information architecture: a per-municipality dashboard with clear status counts (active, in stock, online, warning, offline), devices linked to the resident's name instead of serial number, a per-device detail view with direct self-service actions like changing operator or scheduling a site visit, and a role-based flow for adding new staff with an audit log.
Prototype and usability testing
Once the prototype was ready, I ran usability tests with the same people who'd taken part in the initial interviews. Participants were given tasks based on their daily work and also navigated freely through the flows, including the detail view for a single hub with its connected devices and alarm path.
The reception
The response was strongly positive. The new information architecture for the device fleet, the dashboard, and the flow for linking devices to residents were particularly well received, representatives from Vingåker said outright they wanted the system exactly as the prototype showed it.
The tests also surfaced new, unanticipated requests: a filter for food/eating alarms in the event log, the ability to pause cameras and sensors for residents who split their time between addresses, and exporting the past week's logs as a PDF or zip file for follow-up, a routine already used in Tjörn kommun's operations.
Outcome
The work resulted in a requirements specification that I handed over to Sensapp, which the team is now building on. This was the last thing I completed before the internship ended, so the prototype isn't in production. The outcome is a verified research foundation and a tested direction, not a shipped feature.
Reflection
Having direct access to users completely changed the character of the work compared to the Bubblan case: I could ask, listen, build, and retest with the same people. At the same time, I stayed humble about what direct contact actually delivered, participants were already experienced DC users, adapted to the platform's current logic, which makes the gap between what users say and what they actually do worth remembering.
One small but telling observation: one of the participants, new to the role and without experience of the old system, navigated the prototype more easily than several far more seasoned participants, not scientific proof, but a signal worth noting. If I were to redo the work, I'd want to observe staff in their daily work rather than just hear them describe it, and I'm clear that the AI tool sped up production and iteration but never replaced the human presence in the Teams calls or the visit to my contact in Vingåker.
