Digital Campus App

Building an app for a new university where students can find their courses, timetable, news, events, and quick links all at a glance.

At a glance

UX/UI Designer/Product Owner 

Role


IT:U, Interdisciplinary Transformation University Austria, Linz. 

Organization


Ombiel Campus M (Mobile)

Platform


March 2026 to ongoing

Timeline


AI Engineer, Senior Software Developer, Data Engineer, IT Operations, 2 Product Analysts, Scrum Master, and me as a UX/UX Designer/Product Owner

Team


Figma, Jira, Font Awesome Pro, Canva, Campus M

Tools


Summary

Campus M is an app for students of IT:U. I designed its interface and user experience, built the Figma design system that now backs it, and worked around the limits of the underlying platform with custom CSS where the standard options fell short. The project was presented to upper management and received strong written praise from the Directors, President, and other panel members.

Students now can access their courses, time table, news, events, and university resources right from the dashboard. This had never been done before. I pioneered the process with my team to create the designs and spearheaded product vision.

A university that is still shaping its identity has a particular challenge: students need a reliable daily touchpoint, and the tools around them are often scattered across emails, portals and separate systems.

Students were typically having issues with the following:

  • Finding course relative information at a glance

  • A time table that is accurate and readily available

  • Information on upcoming events

  • Notifications regarding class and schedule change

  • Quick links

The problem

Goals and constraints

Goals

  1. Meet student needs. Give students a robust timetable, news and events, courses, notifications and quick links, all easy to reach on the go.
    Checked through user interviews and multiple rounds of user testing, and tracked long term through adoption, feature usage, satisfaction, and further user testing.

  2. Make the app feel like IT:U. Keep the interface consistent with the IT:U’s brand.
    Checked through a periodic design audit. Creating a brand identity on the side myself

  3. Create a reusable design foundation. Build a system that other IT:U software can adopt.
    Measured by how many products or teams use it.

Constraints

  1. A fixed platform. The app runs on Ombiel CampusM, which offers a fixed set of components and limited styling control.
    This made me focus on where design could make the biggest difference, and solve gaps directly in CSS.

  2. A small team. Developers owned the build, so design had to be precise and easy to hand off.
    This is why I invested in a documented design system with defined tokens and component states.

My Role

I held two roles on Campus M. I started the project by facilitating the discovery sprint that scoped the problem, and I stayed on as the UX/UI designer, owning the interface design, the visual language and the design system. I was also entrusted with the product owner role, which I carried for about seven months alongside the design work. As product owner, I owned the backlog and priorities, made scope decisions, and kept stakeholders aligned with the team. Throughout, I worked directly with the developers to get the designs into the platform.

Research before design

I started the project by facilitating a discovery sprint. I led the workshop, we interviewed people, and together we scoped the problem before any design work began. Afterwards I distilled the sprint into a set of findings that set the direction for the product.

Discovery did not stop there. I followed up with a series of meetings with stakeholders across the university, including students, learning experts and administrators. Each group saw the problem from a different angle, and these conversations let me test the early findings and fill the gaps.

KEY DESIGN DECISIONS

Designing inside a platform, not around it

Since we were quite constrained in terms of what the Ombiel platform can do. We implemented a custom AEK framework that was powered by live tile SDK. This system ensured us some flexibility in terms of what we can achieve. However, total flexibility wasn’t possible.

Design System built for more than one app

Rather than styling screens one by one, I built a design system in Figma, with Campus M as its first consumer and IT:U's other software in mind.

  • Color: Violet (#7438BB) as the primary, supported by Coral and Mint accents, plus neutral and semantic scales for states like success and error. The palette follows the IT:U corporate identity I also developed.

  • Typography: Since the software was limited to only a few choices. I chose Arial as the typeface for the app.

  • Icons: I chose Font Awesome Pro over Lucide because it supports multiple states per icon (for example outline and solid for inactive and active), which suits navigation.

  • Components: CampusM can be extended through its Application Extension Kit (AEK), so I created components for the AEK implementation: [list them, e.g. buttons, cards, navigation, list items]. I deliberately held back on form fields until real use cases appeared, so the system grows from actual needs instead of guesses.

[Screenshot: color and type foundations in Figma]

Redesigning the sitemap

We figured that the existing sitemap was very confusing for students so we wanted to make some changes to it. I organized a workshop with my team where we took our time to sort out the site mapping via affinity mapping. At the end of things, we gained clarity and had a clear sitemap that needed further testing.

Beyond design: product ownership

Key decisions as the PO

I was given the product owner role during the project and carried it for around six to seven months, while continuing to work as the UX/UI designer. In practice that meant

  • Owning and prioritizing the backlog

  • Deciding what shipped and when

  • Turning stakeholder and student needs into requirements

  • Keeping the team aligned with stakeholders.

[Add two or three concrete examples, ideally one tradeoff you decided.]

Because I had led discovery, designed the product and owned its priorities, scope and design decisions were made together instead of being negotiated between separate people. Presenting Campus M to upper management was part of this work.

Holding both roles taught me that [your lesson, e.g. many design decisions are really prioritization decisions in disguise]. It also made me a better collaborator with developers, because I could see the cost of what I was asking for.

Handoff and build

I documented the design system in Figma with tokens and component states so developers could implement without guessing. Because the platform limits what standard components can do, I also wrote CSS myself for the cases that needed it, which shortened the loop between design and a working result. [Add how often you synced with developers and any handoff process you used.]

This is the part of the work I enjoy most: closing the gap between a design file and what users actually see on their phones.

Outcome

  • Campus M was presented to upper management and received strong written praise from the director

  • A reusable design system is now in place, with Campus M as its foundation and the rest of IT:U's software as the next step

  • [Add any metrics: downloads, active users, task success, feedback quotes]

  • [Add anything else that shipped]

The biggest lesson was how much design can achieve inside tight constraints when you understand the platform well enough to know where to push. Learning to solve small problems in CSS made me a better collaborator with developers and moved me toward the design engineer role I am building toward.

If I did it again, I would [what you would change, e.g. involve students earlier, set up measurement from day one].

[Next step: what is planned for Campus M and the design system.]

Reflection

Also created along the way: an internal showcase poster for Campus M, and the IT:U corporate identity document that the app's visual language builds on. [Include only if you want them in the portfolio.]