sovanta
At sovanta I wanted to learn how to work professionally with design systems and how to run user research in a methodical way. Along the way I saw how UX is put into practice in an organization that simplifies complex SAP processes through design and technology.
Note: role labels apply to all genders.
Role
User Research
UX Design
Design Systems
Timeframe
February 2025 - May 2025
The final leave-request tool for managing vacation and absences.
My first task was redesigning an internal leave-request tool. Employees should be able to manage absences, submit requests, choose stand-ins and coordinate within the team.
After analyzing the existing tool, I wanted to make first sketches of how I would improve it. But my mentor stopped me: I should not think about designing yet, and start with user research first.
I had assumed that for an internal onboarding task, user research would not be possible. In that moment it became clear to me how seriously sovanta takes user-centered work. It was not a nice-to-have, but an essential part of the process.
Early sketches of my project
I ran interviews with people in different roles, from interns and working students to employees and managers. I looked at how they used the existing tool and where uncertainties came up.
Even after the first conversations it was clear that a vacation request is much more than I thought. Behind the process there were different roles, approvals, calendars, stand-ins and follow-up actions. Employees wanted to understand their vacation balance and the status of their requests. Managers had to spot overlaps and review requests. Stand-ins needed information about the time frame and projects.
The team calendar grew out of one of the most common user requests.
The interviews were a learning process too. Instead of asking about possible solutions, I learned to ask open questions about concrete experiences, like "Tell me about the last time you ...". That way I avoided leading the answers and got a realistic picture of how things actually worked.
After the interviews I had a lot of observations and some contradictory wishes. I clustered the results and looked for recurring patterns.
From that came the core requirements: a quick overview of vacation days and request status, a clear request process, the option to add a stand-in, and a team view for overlaps.
Instead of jumping straight into finished SAP Fiori components, I started with scribbles and wireframes. That let me change flows quickly without committing to details too early. Back then, AI prototyping was far less mature. Today this part of the process is shifting for me: with AI tools I build working prototypes in minutes and can test them in a realistic way much faster. The core idea stays the same though: check the structure first, before too much time goes into the details.
After the research my prototype felt coherent. In the usability test, though, it turned out that some information was expected in other places and a few steps stayed unclear.
The interviews gave me a solid basis, but not a finished solution. The design was my own interpretation of the findings and therefore had to be tested again. I reworked the wireframes, simplified flows and tested iteratively until the design worked.
The leave-request tool was only the start. For an external client I also designed an automation tool for recurring processes. With little time to get up to speed, I still built an overview, a flow for creating new automations, and a clickable prototype that I presented to stakeholders.
Beyond that I worked on a method contribution about UX audits, supported the internal design system, designed presentations and videos, and won an internal AI hackathon with my team.
Since most of this work was for real clients, I cannot show the applications and processes in detail. They shaped me all the same: I got to develop solutions on my own, do research and present results. I never felt like an intern, but like a full member of the team.
At sovanta, UX is not just a job but part of the company culture.
Good UX comes from listening, testing early, and being willing to question your own decisions. And to throw designs away, even when a lot of work has already gone into them.
Before you design or write a single line of code, you have to understand who you are working for: how do people behave? What processes already exist? Where do problems come up?
