Goal
[CS 3724: Introduction to Human-Computer Interaction] Designed TimeOff, a geolocation-based tracking app that limits device use — automatically restricting entertainment platforms after 11pm and using location tagging to block specific applications in places the user chooses. The research question behind it was whether that kind of enforced boundary could reduce feelings of depression and isolation, rather than simply reducing screen time.
Background
Screen-time tools generally assume the user's problem is a lack of information — show someone their weekly average and they will correct course. That framing does not match how the habit actually breaks down: the moments people most want to protect are late at night and in specific places, and those are exactly the moments when a dashboard is least persuasive. TimeOff was built around time and location as the enforcement primitives instead, so the restriction fires without requiring a decision at the point of temptation.
Methods
Participants
Recruited from the target audience for both the generative phase and the usability evaluation; the exact count was not recorded in the original project write-up.
Study Design
The generative phase used contextual inquiry and contextual analysis alongside interviews and direct observation, so that reported habits could be checked against observed ones. Findings were organised as sticky notes in Google Jamboard and consolidated into personas.
Design moved through conceptual designs, storyboards and wireframes, prototyped in Balsamiq, Sketch and Figma — low fidelity first to settle structure, higher fidelity once the flows held. The resulting prototype went through a usability evaluation with the target audience.
Insights
Overall satisfaction with the interface was positive, but the evaluation surfaced two clear problems. Customising restricted zones — the feature the whole geolocation premise depends on — was convoluted enough that users struggled with it. And the dashboard presented so much information that it became a distraction in its own right, which is a particular failure for an app whose purpose is to reduce distraction.
Both pointed the same direction: simplify. The product's value was in the enforcement, not in the reporting, and the interface had inverted that emphasis.
My Learnings
The lesson I took from this one was blunt: no matter how good a design may be, it is not a good design if nobody will use it. A restriction app is unusually exposed to that, because the user can simply delete it — adoption is not a metric layered on top of the design, it is the thing the design has to earn.
It also taught me to watch for the case where the interface argues against the product's own goal. Building a busy dashboard into a focus tool was not an oversight in isolation; it came from treating "show the user their data" as a default rather than a decision.