Digital Detox
An app that nudges 15-19 year olds to reduce their screen time, without making it feel like restriction.
Team
4 (cross-functional)
Timeline
6 weeks
Role
UX Researcher
UX/UI Designer
Tools
Figma
Our client, a teacher at an MBO school in the Netherlands, wanted an app to help students become more aware of their screen time and build healthier habits as a class. We had six weeks to design the experience, grounded in research on what would actually motivate this age group to change.
Problem
We interviewed 10 students at the client’s MBO school. One participant, P1, said her phone use felt “okay”, then checked mid-interview and found she’d already used it for 4 hours. It was only 11am. She wasn’t the exception. Other students described similar patterns, with screen time of 6 to 8 hours a day treated as normal among friends. The problem wasn’t that students needed to be restricted. It was the gap between what they thought they were doing and what they actually did.
Findings
Thematic Analysis
6.3
average frustration rate
/10
After the interviews, we used the COM-B framework to make sense of the patterns we’d observed.
Physical restrictions, like requiring phones to be put away during class, worked short-term, but participants felt it took away their autonomy, and the effect didn’t last. Phone use for 6 to 8 hours a day didn’t raise concern among friends. Participants said they wouldn’t react to a friend’s heavy use, since their screen time was just as high (P3, P5). Yet when they were doing something they actually cared about, like football or time with people they were close to, their phone use dropped on its own. That pointed to the direction: not restriction, but something personal enough to matter and social enough to stick.
3
gave up on a piece due to transposition issues
/5
The clearest pattern came from Barriers and Current Method: frustration was driven not just by the time and cost involved, but by how much the difficulty depended on a piece’s popularity. None of the 5 participants’ actual solutions involved a dedicated transposition app. Instead, they relied on manual work, paid websites, or built-in device features.
The key insight from this analysis was that transposition was not only a practical problem, but created frustration and influenced how participants approached or abandoned pieces
Key findings:
5
needed to transpose sheet music
/5
To understand whether this was already being solved elsewhere, I compared 4 apps used by musicians.
P1 rated their frustration with transposing as “laziness level 9.5.”
P5, on the time cost of finding a correctly transposed version: “Sometimes I bought one but it was just incorrect… so then the next day I had to find another one.”
None of the 4 apps analysed (Metronaut, Melody Scanner, ForScore, and MuseScore) have transposition as their main feature; it works as a secondary or side feature in all of them. Free versions were generally too restrictive, with most core features locked behind a premium upgrade. Melody Scanner’s camera scan redirects to an external website, creating friction in the workflow and a potential drop-off point.
To bring the interview findings together, I applied thematic analysis to the data, coding it into several themes: emotions, barriers, context, behaviour, current method, and needs.
Conflict
→
We validated the concept with a card sorting session: 9 students, 17 features, sorted into “would motivate me,” “neutral,” and “would not motivate me.” Discount codes, Levels, and Personal progress overview scored the highest. Reflection-based features, like Weekly reflection questions and Mood tracking, scored among the lowest. They required more time and effort from students than features like Discount Codes or Levels.
This created a conflict. Our client wanted students to reflect on their screen time every week. He wasn’t certain exactly when or how it should happen, but weekly reflection itself was a clear requirement.
We made Weekly reflection optional. In his own classroom, he could still prompt students to reflect together as a class. For everyone else, reflecting stayed a choice. Mood tracking, which scored even lower and wasn’t something the client had asked for, we removed from the concept entirely.
Design Decisions
Reflection stayed optional
The lesson reflection kept a skip option next to the submit button. In the client’s own classroom, he could still prompt students through it together.
Challenges, built on students’ own interests
COM-B showed that participants naturally cared less about their phones when doing something personally meaningful, like football or time with people they were close to. During onboarding, students shared what makes them put their phone down. I used those interests to write challenge copy that felt personal, not prescriptive.
“Your daily goal”, not “amount of reduction”
A teammate had changed ‘your daily goal’ to ‘amount of reduction.’ I changed it back. Our COM-B analysis showed us that autonomy mattered to participants.
Outcome
I tested the high-fidelity prototype with 8 participants across 4 tasks. All 8 completed the core tasks, except P2, who couldn’t find the My Progress page.
Results:
100%
task completion rate
(8/8, tasks 1- 3)
7/8
found My Progress
(Task 4)
82.8
SUS score
I also asked directly: Did the app feel forced or restrictive?
“Didn’t feel forced or restrictive, they can control in the app.”
The whole project started from one question: how do you get students to reduce screen time without it feeling like punishment. We couldn’t test whether screen time actually dropped, but this was the closest we had to an answer.
Reflection
Working across multiple research methods taught me to look for where they agreed and where they didn’t, and to use that tension to sharpen the reasoning behind a decision. Writing the actual copy was the first time I saw that reasoning turn into something concrete, word by word.
Next step
Improve navigation to My Progress, which one participant couldn’t find during testing
Explore whether the app could extend beyond the original target group, as a few participants suggested during testing