SAP remains one of Germany’s strongest DAX companies and a global technology leader, but its user experience is often seen as complex. SAP for Me is the customer and partner portal: for many people it is the first touchpoint with SAP’s product world.

Generation Z is entering the workforce now, Generation Alpha will follow within the next decade. They grew up with personalized, mobile, conversational products and bring these expectations to their work tools. I wanted to find out what these users will expect and what SAP for Me would have to change to meet them.

Designing for users who partly don’t exist yet required more than one lens. I combined methods that look at today’s evidence and at tomorrow’s signals:

• Interviews & surveys with SAP designers, product stakeholders and potential future users
• Trend & technology analysis: AR/MR, proactive AI, voice-first interfaces, immersive experiences, personalization ecosystems
• Speculative design to explore plausible futures from early signals
• UX audit of the current SAP for Me homepage and mobile experience
• Two personas modeling representative New-Gen SAP users

The audit and interviews pointed to four gaps:

I prioritized the gaps by how strongly they affect a new user’s first weeks and by how realistic a change is inside SAP’s ecosystem. Then I compared three directions:

Trade-off: gamification can feel unserious in an enterprise context. I kept it tied to real task completion and made the whole companion optional, so engagement never gets in the way of efficiency.

As a solo thesis project, I owned the work from question to recommendation:

• Defined the research question and designed the mixed-method study
• Planned and ran interviews and surveys, and synthesized them into insights and personas
• Conducted the UX audit of SAP for Me
• Concepted, sketched and prototyped MyJoule, from wireframes to a hi-fi homepage
• Translated the findings into strategic recommendations beyond the UI level

1. Extend Joule instead of inventing a new assistant

   Users meet one consistent AI across SAP, and the concept stays realistic for SAP to build on.

2. Two modes for two generations

   Chat for Gen Z, who value speed and efficiency. Voice-first for Gen Alpha, who grew up talking to devices.

3. Personal, not childish

   Customizable avatars, skins and expressions plus a leveling system that rewards completed tasks, so personality supports the work instead of distracting from it.

4. Onboarding in small steps

   Short tutorials and guided steps close the gap caused by having no prior contact with the platform.

5. Always an exit

   MyJoule can be disabled, and the redesigned, more minimal homepage works without it. That keeps experienced users on board.

Although the thesis was individual work, it depended on people inside SAP. Interviews with designers and product stakeholders grounded my speculative scenarios in real constraints, such as the Fiori design system and existing roadmaps. Where early ideas proved unrealistic for an enterprise context, I narrowed the concept to what could be built on existing technology, and moved the bigger shifts into the strategic recommendations.

The findings were presented to the SAP for Me design team as well as internally at the university before an academic audience, and were subsequently awarded the highest possible grade of 1.0 in the Master’s colloquium.

The next generation of enterprise users expects more than efficiency: experiences that are accessible, adaptable and emotionally engaging.

The biggest lesson was balancing speculation with evidence. Next, I would validate MyJoule with usability tests among Gen Z employees and measure whether it actually shortens time to first successful task.

Technical scrutineers play a critical role in motorsport: they make sure vehicles and drivers comply with safety and regulatory standards before a car goes on track. Their workplace is the paddock, with high noise levels, strong odors and tight schedules between sessions.

Many scrutineers work as freelancers and manage their own documentation. Every minute spent on data entry is a minute missing from the actual inspection.

I interviewed 32 scrutineers about their workflow and clustered the findings with the team. Four needs came up again and again:

The biggest design question was how to handle the variety of racing series without making the app complicated. We compared three models:

Trade-off: we chose phone over tablet because scrutineers move around the car and need one hand free. That means less screen space, so the design relies on large tiles and clear priorities instead of dense tables.

• Planned and conducted stakeholder interviews with scrutineers and synthesized the results
• Defined the information architecture: series, divisions, vehicles and inspection categories
• Sketched the flows on paper and iterated them into wireframes
• Designed the UI and interactive prototype, including the toggle-based configurator
• Shaped the accessibility decisions for loud, hectic environments

1. Large category tiles

   Vehicle, safety cell, seat or fire extinguisher: each category is a big, icon-led tile that is easy to hit quickly, even with gloves.

2. Errors first

   Red counters on every tile and in the header show open issues immediately, so scrutineers go straight to what needs attention.

3. Configure with toggles

   Fields like start number, driver, manufacturer or vehicle pass are switched on or off per series. No form building needed.

4. Offline by default

   Data is captured locally and synced later, so a dead zone never interrupts an inspection.

5. Visual, not auditory feedback

   Sound is useless in the paddock, so every status is communicated through color, icons and text.

Scrutineers were involved from the first interview to the prototype review. Their feedback changed the concept: an early version used dense lists , and testing showed tiles were faster to scan in their environment.

By digitizing and simplifying the documentation, Scrutifree contributes to safer and more equitable racing events, and its configurable model can scale to other and future motorsport disciplines.

Designing for the paddock taught me that context shapes the interface more than features do.

Next, I would test the prototype during a live race weekend and measure entry time against the old process.

As part of a Software Engineering Project course, our team took part in a development competition hosted by John Deere Mannheim. The challenge: design and implement a digital solution that reduces the workload of John Deere’s customer service department.

Instead of starting with features, we started with the calls. We interviewed John Deere staff and analyzed customer service transcripts to understand where the workload comes from.

Trade-off: a portal needs a login, which adds friction. We kept the sign-in minimal and made the order status the first thing users see afterwards, so the effort pays off immediately. Notifications stayed on the list as a future extension.

• Co-led the user research: stakeholder interviews and transcript analysis
• Sketched the core flows (sign-in, dashboard, past orders) as hand-drawn wireframes
• Designed the UI in line with John Deere’s corporate identity
• Worked with the developers on frontend implementation and integration planning
• Presented the solution to John Deere stakeholders

1. Status as the hero

   A personal greeting and a progress tracker for the current order sit at the top of the dashboard: the answer to the most common call, at a glance.

2. Details on demand

   Model, dates and delivery information are grouped below the tracker, so the page stays calm but complete.

3. Purchase history one tap away

   A detailed history of previous purchases covers the second most common type of inquiry.

4. Familiar brand, modern interface

   John Deere’s green and imagery create trust, while a simple, modern layout replaces the typical enterprise look.

Design and computer science students worked together in Scrum sprints. Designing in the same rhythm as development meant I delivered wireframes early and refined them sprint by sprint, instead of handing over a finished design. When technical limits appeared, we adjusted scope together and focused on the flows with the biggest impact on call volume.

Our team’s solution was awarded first place in the competition, recognized for its efficiency, clarity and strong alignment with business needs.

The best feature was the one grounded in data: we didn’t guess what customers need, the transcripts told us.

Next, I would add proactive status notifications and measure how the call volume on order status changes after launch.

In SAP Fiori applications, Message Strips provide contextual feedback, for example about specific table rows. At the same time, highlighting (colored status indicators on rows) signals status visually. Both are well documented on their own, but their interaction had not been clearly defined in the design system documentation.

I reviewed the current Fiori guidelines and the UI5 implementation and mapped every scenario across the four message types: Error, Warning, Positive and Information. Three open questions caused most of the ambiguity:

Trade-off: consistency versus team autonomy. I made rules mandatory only for errors and kept the rest as recommendations, with the UX Design Team having the final say. That kept the guideline adoptable instead of ignored.

• Identified the gap and owned the guideline end to end
• Audited Fiori documentation and UI5 behavior and mapped all scenarios
• Defined the interaction logic and state model
• Built the Figma guideline, clickable mockups and a logic flow diagram
• Aligned with the UX Design Team and handed off to development

1. Errors persist until resolved

   In an error scenario, the highlight and the Message Strip stay visible until the underlying issue is fixed, so no problem can be dismissed by accident.

2. Dismissing depends on the scenario

   Whether strips and highlights can be closed is defined per scenario. It is not mandatory, and the UX Design Team has the last say.

3. Highest priority first

   When several issues affect one row, the most severe message is shown first. Error comes before warning, and warning before information or success.

4. Documented as logic, not just visuals

   A flow diagram describes priority and persistence, so developers can implement the rules without interpreting screenshots.

The guideline had to work for two audiences. I reviewed early drafts with UX/UI designers for clarity and with developers for feasibility in UI5. Feedback moved it from a strict rule set to a priority-based model with room for team decisions. Clickable mockups made edge cases discussable in minutes instead of long spec threads.

The documentation was handed off to the SAP for Me development team for implementation. The behavioral model can be reused for other UI components such as cards or list items. 

A good guideline isn’t the strictest one, it’s the one teams actually follow.

Next, I would propose the model as a contribution to the official Fiori documentation, so teams beyond SAP for Me benefit from it.