Case study · Human Computer Interaction · 2026
Louder is a mobile app that helps international students in Oldenburg find practical and civic events they can actually join, matched to what they need right now and how comfortable they feel with German.
01 · Overview
International students in Oldenburg take part in local community life far less than local students, even though most of them want to. The barriers are practical, not a lack of interest.
We surveyed 14 students, ran 5 interviews including the International Office, coded 73 mentions into themes, and traced every requirement back to that data before designing.
A guest first app with a comfort based language filter, explained event matching, consent based buddies and an impact screen that only shows verified outcomes. 5 of 6 test participants completed every task.
I led the UI/UX design: wireframes, the interactive HTML prototype, the high fidelity Figma prototype, the usability test materials and the poster. Ahsan and Shanmukh led data collection, and the three of us ran the synthesis together.
02 · Problem
Civic participation, from neighbourhood forums to support sessions and volunteering, is one of the fastest ways to feel at home in a new city. Yet international students in Oldenburg rarely take part.
Our survey showed it was not apathy. 12 of 14 respondents said they would participate if opportunities were accessible, relevant and clearly communicated. The desire was there. Four barriers kept getting in the way, and they came straight from what students told us.
03 · Research
We combined a short survey for breadth with semi structured interviews for depth. Talking to the International Office mattered: they see the same questions from hundreds of students each semester, so they could tell us which problems repeat.
Every open answer was coded, grouped into categories and synthesised into themes through affinity diagramming.
Open full size ↗
04 · Insights
We expected language to dominate. It was important, and the International Office called it the most critical factor. But across all coded data, trust came out on top: students doubted their input would lead to anything real.
“Without that it just feels like a waste of time.”
Survey respondent, on not seeing outcomes · Trust“I had no idea something like that even existed.”
Survey respondent · Awareness“Guests here rather than actual members.”
Survey respondent, on how students feel · Belonging“University should let us know we're welcome.”
Survey respondent · Active invitationStudents said yes, but “depends on the topic.” That told us relevance had to be visible on every event, not hidden in a filter.
05 · From findings to requirements
| Barrier found | Requirement | Where it lives in Louder |
|---|---|---|
| Trust16 | Transparent information and visible outcomes | Impact screen with organiser verified updates, dated and sourced |
| Awareness12 | Easy event discovery | Personalised feed built from two quick onboarding questions |
| Language11 | Language aware participation | Comfort filter plus a language label on every single event |
| Belonging10 | Identity, not only activity | Journey screen framed around growing local confidence |
| Effort4 | Low barrier onboarding | Guest access to every feature, no account needed to join |
| Invitation4 | Explicit welcome | Welcome copy that names the barriers and says students belong |
| Going alone | Buddy participation support | Consent based buddy matching for the same event |
06 · Design decisions
Decision 1
“Continue as Guest” is the primary button, and guests get every feature, including registration and buddy matching. The welcome screen names the barriers out loud and offers five languages before asking for anything.
Decision 2
Our first version asked for an A1, B1 or C1 level. Students hesitated: it felt like an exam. We replaced it with how comfortable they feel, and the screen says plainly that this is not a test. Every event then carries a clear language label.
Decision 3
The feed doesn't just rank events. The best match tells students why it was picked: their interests, their schedule and the language support on offer. We also swapped generic city events for the ones newcomers actually need, like residence permit Q&As, housing contracts and CV clinics.
Decision 4
Students can find someone going to the same event. Both people must accept before any messaging opens, and the screen says so before a request is sent.
Decision 5
The Impact screen separates what a student gained from what organisers report. Organiser outcomes only appear once verified, with a date and a source. Until then, the screen says it is waiting.
07 · Iterations
Stage 1 · Figma
Does the structure make sense? We mapped the flow from welcome to impact and checked it against every requirement.
Stage 2 · HTML/CSS/JS
Does the flow feel right in the hand? A clickable build let us test real transitions and timing before polishing visuals.
Stage 3 · Figma Make
Is it ready for testing? The final version ran on participants' phones in the usability study.
08 · Evaluation
We ran a within subjects usability study with 6 international students. Each completed four tasks across the core flow, then answered questions about usability and whether they would actually participate.
Task completion5 of 6 participants finished every task.
Participation intention5 of 6 said they would join an event through Louder.
ParticipantsInternational students in Oldenburg. A small sample, so we read results as direction, not proof.
09 · Reflection
The most useful thing this project taught me: the loudest barrier in a brief is not always the biggest one. Language was the obvious problem. Trust was the real one, and only the coded data showed it.
If I continued Louder, I would test with a larger group over several weeks to see whether participation actually rises, not just intention. I would also work with real organisers on the verified updates, since the whole trust model depends on them publishing outcomes, and run a full accessibility audit across all five languages.
