Scattered student services. One AI-powered hub.

An AI-powered search and service hub that lowers support pressure and helps students find what they need on their own.

Role: Senior UX & Product Designer

Focus: UX/UI Design, AI search flow, service architecture, Design System adoption, post-launch iteration

~5 min read

AI Search Flow
Service Architecture
Design System Adoption
Mobile-First UX
Post-Launch Iteration
Stakeholder Mentoring

The problem: A major university's information was scattered across many separate websites, so students, staff and visitors often didn't know where to start looking.
My role: Senior UX & Product Designer. I turned early service-design concepts into real screens, tested them with users, shaped the first release (MVP) and kept improving it after launch.
Decisions I made: One front page and one AI-powered search entry point for all services
Accessible and mobile-friendly from day one
I put the service's accessibility, clarity and ease of use at the centre of the design and defined clear metrics for the work. I made sure the key user groups were closely involved in development.
To keep the design consistent and high quality, we agreed not to use one-off builds. I guided developers to use the Design System's components and set up a working collaboration model between developers and the Design System team.
The outcome: Confirmed by user interviews and surveys after launch: people found answers faster, simple questions moved to self-service so staff had more time for cases that needed a person, and the service worked on phones and with assistive technology.

The brief

Starting Point

A major university had information scattered across many separate websites, so students, staff, and visitors often didn't know where to start looking. I joined as Senior UX & Product Designer to turn early concepts into real screens, test them with users, and shape the first version people could actually use.

Selected screens

Desktop and mobile, one platform

Results

The Impact

These impacts were confirmed through user interviews and surveys carried out after launch.

Faster access to help
Answers are found faster across channels, whether it's AI search, messaging, forms or an information desk.
Less pressure on staff channels
When AI search and self-service handle everyday questions, staff have more time for situations that need personal support.
Accessible and mobile-friendly from day one
The implementation makes the service easy to use independently on a phone, on the go or with assistive technology.
An easy start for new visitors
New students and visitors don't need to know the university's structure beforehand: one entry point leads straight to the right information.

Background

A major university had information scattered across many different websites, making it hard for students, staff, and visitors to find help.

Service designers had already done the early research and mapped out the initial idea for a central service portal. My job as Senior UX & Product Designer was to turn those early concepts into real screen designs, test them with actual users, and refine them for the first product launch (MVP).

After launch, I stayed on to collect real user feedback and keep improving the service based on how people actually used it.

The hard parts

Scattered information

Before this project, university services lived across many separate sites and systems, with no shared starting point. Students and staff often didn't know where to start looking, or ended up on the wrong page entirely. I designed a single front page and AI-powered search entry point that brings services together in one place, so people can search in their own words instead of guessing which department's site might have the answer.

Private staff data appearing in AI search results

During the project, the product's project manager raised an issue: the AI search could show private staff information to visitors who were not logged in. We discussed it closely as a team before I left the project. It was later solved with a login prompt: a window appears as soon as the user starts searching, asking them to log in to see the full results. It solves the privacy issue well, and I understand why that solution made sense given the constraints at the time. My own contribution to the discussion was accessibility and how to make the service clear and easy to use, I tried to bring the important user groups into the conversation, and I proposed setting up metrics. If I'd still been involved, I might have explored whether the login prompt could appear a bit later in the flow, so it interrupts the user less right at the start of their search.

Supporting the Product Owner

Agile development and software projects were new to our Product Owner. Together with our service designer I supported them, helping structure the list of work waiting to be done, organise user feedback, and write clear tasks for the team.

Encouraging shared components instead of one-off builds

To keep the design consistent and high quality, we agreed not to use one-off builds. I reminded developers to use the Design System's components and connected them with the Design System developers to talk things through. I brought in the Design System team whenever something genuinely new was needed.

In hindsight

Set clearer rules for the design before handing it over. Looking back, I would have documented a few key UX principles more clearly before leaving the project, so the experience could stay consistent even without me there to weigh in on changes. After I left, a few small details evolved differently from how they were originally designed, for example, search results appearing below the search bar instead of in the same visible area, so it's not clear when results are loading. Small things like that can add up over time. It taught me something useful: it's not just the design itself that needs documenting, but the reasoning behind it, so that reasoning can still guide decisions even when I'm not in the room anymore.

Set clearer success metrics from the start, beyond basic usage data. We had Matomo (a privacy-focused web analytics tool) in place, which gave us useful data on things like page views and click behavior. We did actually plan to go further than that, defining metrics that could tell us whether the service was solving the right problem for users, not just how it was being used, but we never managed to get it implemented.

Looking back, I'd want to solve this without adding extra burden on users, for example, a lightweight, optional feedback prompt after key moments like an AI search result, rather than a separate survey, or looking at indirect signals we already had access to, like whether staff contact volume for common questions changed over time. Having something like this in place from the start would have given us a clearer way to answer the real question: is this actually helping people, not just are people using it.

Make design's role in the process a bit more structured, not just reactive. I stayed closely involved throughout, checking in regularly with developers and the scrum master, the person who keeps the team's way of working on track. Looking back, I'd set up a few lightweight checkpoints from day one: a short design review before UX-related changes ship, a clear point of contact for technical questions, and the reasoning behind UX decisions written directly into the task descriptions developers already work from, rather than in a separate document nobody has time to read. None of that has to slow a tight timeline down, if it's built into the workflow from the start.

Keep reading

Other case studies

Industrial

Industrial Data & Expert Interface Design

Built practical expert tools for industrial data workflows, making complex calculations and monitoring more reliable for specialists.

View case study →

Public education

National Education Administration Platform

Brought structure to a massive public sector platform by uniting complex municipal school workflows into a clear, accessible tool for teachers and administrators.

View case study →