Digital Transformation in Student Living in Studierendenwerk
My role
UX Designer
Team
Self-directed project
Target Audience
Students, Dormitory administration
Platform
Mobile App and Web
Context
Studierendenwerk Siegen managed all dormitory operations - room applications, maintenance requests, community communications, entirely through email and office visits. I led the end-to-end research and design of a mobile app and admin system to replace this with self-service digital workflows. Through research with 52 students across multiple dormitories, I identified a single root cause underlying every frustration, and designed a solution around it.
Problem
Studierendenwerk Siegen manages student housing across multiple dormitories in Siegen, Germany. Every interaction - applying for a room, reporting a broken appliance, asking a simple question required an email, a phone call, or a physical visit to an office. I had a unique starting point as I was a resident myself and faced similar problems myself. That gave me direct access to the friction and informal trust with other students that made honest research conversations possible. But being a resident also meant I had assumptions I needed to test rather than just design around. So before touching any screens, I treated this as a genuine research problem.
Challenge
Design a system that could eliminate the email-and-office-hours bottleneck for both students and administration making everyday dormitory interactions fast, trackable, and available without requiring either party to be online at the same time. The challenge was that two very different user groups had very different needs: prospective students navigating an opaque room application process, and current residents managing daily dormitory life.
Research
To understand which pain points were most severe and most frequent, I conducted 10 in-depth interviews with students across different dormitories, nationalities, and lengths of residence, then distributed surveys to broaden validation to 52 students total. I also mapped the actual current processes through contextual inquiry - observing how booking and communication worked in practice, not just in theory and synthesized everything through affinity mapping to find patterns across very different student experiences.
Insights
Solution
Self-service room application and tracking
The application process was redesigned to be fully self-contained students could browse available rooms with photos and details, submit applications with document uploads, and most importantly, track their own status with a clear timeline. No more calling to find out if they were even in the queue. This directly addressed the black box experience that was driving the most anxiety and the most redundant administrative inquiries.


Asynchronous messaging system
Instead of email or office visits, residents can submit maintenance requests with photos and descriptions, ask questions, and track response status all without needing anyone to be online at the same time. For administration, this replaced unstructured email threads with a managed queue they could work through on their own schedule.





Community connection features
Rather than generic social networking, I designed for the specific reasons students said they wanted to connect: a resident directory organized by dormitory and floor, and an events calendar for dormitory activities. Simple and purposeful rather than comprehensive.




Unified admin dashboard
The admin side centralizes everything staff previously managed across email threads, phone logs, and spreadsheets - room applications, maintenance requests, announcements, and occupancy into one panel. The design principle was that every student-facing feature had to reduce the administrative equivalent, not add to it.


Constraints
Limited staff access for validation: Studierendenwerk staff could only participate during specific windows because of semester-start operational demands. Rather than spread thin validation across both groups, I prioritized depth with students whose needs drove the design and used the limited staff time to validate workflow feasibility and constraints rather than design preferences.
No visibility into existing technical infrastructure: As a thesis project, I had no access to Studierendenwerk's backend systems or databases. The solution was designed to be implementation-agnostic focused on interaction patterns and user flows that would hold regardless of technical approach, so the designs remained actionable if and when development was resourced.
Outcome
This was a master's thesis project and the deliverable was validated research and design, not a launched product. Studierendenwerk Siegen received a complete research report documenting findings from 52 students, high-fidelity prototypes covering both the student app and admin panel.
The aim was to prove that the email-and-office-hours system had a specific, fixable structural problem synchronous communication where asynchronous should have been the default and to design something that directly solved it. The research validated that problem clearly enough that the solution had a concrete, testable foundation rather than a list of assumed improvements.
Reflection
Academic timelines let me go deeper into user research than most product cycles allow. The richness of the findings — especially the synchronous vs. asynchronous insight came from having the time to run 10 qualitative interviews before writing a single survey question. That sequencing mattered.
Being a resident myself was both an advantage and a risk. I had trust and access other researchers wouldn't, but I also had to work harder to surface things I'd normalized. Running structured interviews with students from other dormitories, different nationalities, and varying lengths of residence helped correct for that.
What I'd do differently: I'd push harder for even one or two usability sessions with actual Studierendenwerk staff on the admin panel. Student validation was thorough administrative validation was minimal by necessity. In a real launch scenario, that gap would need to close before any rollout.
