I bring user,⁰¹
business⁰² and tech⁰³
views together.

The UX design team already had a Jira board and a Confluence space, but they were unstructured and had no workflow that fit how the team or the company worked. Client projects and pitches sat next to admin, organisation, skill development and training without a clear system. At the same time, more and more AI tools promised to speed up design work, without a clear view of which ones were usable and worth bringing into the workflow.

I reworked the team's tooling from the ground up: the structure of the Confluence space and the Jira board, workflows, automations, templates and permissions. For one of my projects I set up a Jira workflow that everyone in the company could use to submit requests. On the AI side, I tested and analysed external tools for the design team, and after the company-wide Claude rollout I worked out how to bring our brand guidelines and design system into Claude Design.

Tools only help if people actually use them. So instead of adding more structure on top, I rebuilt it around how the team really works: one place for everything, from projects and pitches to admin and training, with a workflow that matches the team's and the company's processes. Repetitive steps such as creating subtasks run automatically. For the design system in Claude, Figma stayed the single source of truth, so the brand doesn't drift into a second copy that nobody maintains.

The whole UX design team managed its work in this setup. For my project, colleagues across the company submitted their requests as tickets, with subtasks created automatically. With the design system in Claude, employees can now create documents in the corporate design themselves, ready to send to clients.

Digitalization rarely fails on technology, it fails on adoption. The same thinking I use for products works for internal tools: start with how people really work, remove steps, then automate. And AI only scales across a company when the basics, such as brand, templates and a source of truth, are in place first.

The client, a truck manufacturer, wanted to introduce a tool on a tablet used by workshop technicians during vehicle servicing. The existing workflows for inspections, diagnostics and repair guidance were complex, time-consuming and not optimized for real workshop conditions. The challenge was to design a tool that supports technicians wearing protective gloves, while also addressing the information needs of fleet and operations managers who require a broader overview of vehicle status and maintenance activities. Balancing these very different user groups without overcomplicating the experience was the core design challenge.

As the sole UX/UI Designer on the project, I worked directly with the OEM's Product Owner and development team throughout the product design process. I collaborated closely with developers to ensure technical feasibility and smooth implementation while aligning design decisions with business priorities.

The core tension was designing one tool for two fundamentally different working modes: technicians who need to execute repair steps fast, often in gloves, with zero tolerance for friction, and fleet managers who need a broader operational overview. Instead of building two separate interfaces, I structured the product around a shared information hierarchy: a stripped-down, high-contrast, large-touch-target layer for in-the-moment repair tasks, and a separate overview layer for fleet-level insight, both drawing on the same underlying data. That meant deliberately cutting lower-frequency features that would have added completeness but slowed down the core repair workflow.

The final designs (wireframes, interaction flows and a documented information hierarchy) were handed over to the OEM's development team as implementation-ready assets. As an external design partner, my engagement ended at handover; I don't have visibility into the tool's later rollout or adoption.

Designing for two audiences with opposite cognitive needs on one product showed me that "more information" and "better information" are often in conflict. The fleet manager's need for oversight could easily have bled into and cluttered the technician's need for speed. The real design work was keeping those two needs from contaminating each other within a single system, not adding features for either group.

On today's social platforms, it's surprisingly hard to know, in the moment, who among your friends actually has time and is up for hanging out right now. Plans get buried in group chats, and feeds show what happened yesterday rather than what's possible today. 2gether set out to close that gap: a social app built around real-time availability instead of curated content.

I co-founded 2gether with one co-founder, who provided the funding. I was solely responsible for product and design, from the very first sketch through release and marketing. A single developer was contracted for implementation; everything else, I owned end-to-end, alongside a full-time job. Timeline: 2023–2026.

With limited resources, one of the most important calls was resisting feature creep: keeping the product tightly focused on real-time availability rather than expanding into a broader social feature set, so the core idea could be validated with real users as early as possible.

The app launched and organically reached several hundred users. Without budget left for marketing, growth stalled, and we've since filed for liquidation.

Running product, design and go-to-market solo taught me how much of "shipping" is prioritization under constraint, and confirmed that even a small, dedicated budget for marketing needs to be secured before launch, not after.

Innensicht is a personal project: a mobile app for emotional self-reflection, combining a swipeable deck of 37 "inner parts" cards with a three-stage emotion wheel and private, on-device history. Beyond the product itself, I wanted to test something for myself: could I, as a solo designer with no engineering team, take an idea all the way to a real, submitted App Store build using only AI-assisted development?

Sole designer and builder: brand, UI/UX design and the full build, all directed through Claude Code without Figma, end-to-end through the release in both stores. No team, no agency, no outsourced development.

1. Designed the brand and screens directly in Claude Code, without Figma: name, a deliberately reduced 3-color palette, logo and the core flows (card deck, emotion wheel, history).
2. Built the React Native/Expo app with Claude Code as well, so there was no hand-off between design and code.
3. Iterated on both UI and content structure live.
4. Finished with App Store prep: app icons, legal pages (privacy policy/imprint), export compliance and privacy declarations, and submission via EAS. All in the same afternoon.

User view first. I made it easy to bring the outcomes to a therapist, and I built widgets, reminders and an Apple Health integration so users don't forget to check in. I integrated a second check-in that includes the body. The experience is step by step so it never overwhelms, and it leaves the decision to the user whether to do a step or not. I chose local-only storage (AsyncStorage, no server, no accounts) as a privacy-first stance baked into the product, not bolted on. I used Claude Code as a full development partner rather than a no-code builder or template, to keep the app fully custom.

A real app, not a prototype: live in the App Store and on Google Play. Listing, screenshots, privacy questionnaire and pricing are done. Built solo, and the first version was ready for submission after a single afternoon.

Proof that a designer without a traditional engineering background can own the entire build when directing AI-assisted development with a clear product and design vision. The bottleneck shifted from "can I code this" to "can I make the right product and design decisions fast", which is where the actual value of the afternoon went.

As part of a connected mobility pitch for OEMs, we explored a smart assistant for van drivers that personalizes the travel experience based on habits, preferences and context. The core idea was to support "van life" users who expect very different things from their journeys: from highly spontaneous travelers who want freedom without planning or logistics overhead, to families traveling with children who need structure, predictability and detailed organization. The challenge was not just personalization, but designing a system that could intelligently reduce cognitive load by taking over planning and coordination tasks, without overwhelming users or forcing them into rigid workflows.

My contributions included:

• User research and synthesis
• Definition of key personas and behavioral patterns
• Customer journey mapping across different travel styles
• UX concept development for the smart assistant
• Wireframing key interaction flows
• Creation of the pitch presentation (storytelling, structure and visual narrative)

The central decision was to reject a "feature-based app" model in favor of a behavior-driven assistant that adapts to mindset rather than trip type. Rather than building separate flows for spontaneous and family-style travel, which would have fragmented the product into two apps, we designed one adaptive system that dynamically adjusts three variables: planning depth, information density and proactivity. The guiding principle: only show what's needed for this journey style, and handle everything else invisibly in the background.

The concept was presented to OEM stakeholders as part of the pitch and was well received. It validated that a single adaptive system could credibly replace multiple rigid, mode-specific interfaces. As with most pre-sales concept work, I don't have visibility into whether it progressed further internally. What it did produce was a reusable model (personas, adaptive UX logic and a pitch narrative) for framing personalization as cognitive-load reduction in future connected-mobility work.

The most important insight was that good personalization isn't about adding options, it's about removing decisions. Spontaneous travelers need trust and invisibility of the system; structured travelers need control and clarity. The real UX challenge was balancing both without splitting the product into separate apps. It reinforced mental load reduction as a primary UX metric in mobility contexts, where users are already cognitively occupied.