Formally, I joined the project as a UX Writer. In practice, my role evolved into a product-focused position at the intersection of language, design, and product decision-making.

Designers regularly involved me in feature discussions before decisions were finalized, so I could validate concepts from a linguistic and market perspective. I contributed not only at the execution stage, but also earlier, when framing and assumptions could still be adjusted.

I do not have a legal background, but working on a regulated banking product sharpened my awareness of uncertainty and risk. When something felt unclear or open to interpretation, I raised it early and helped bring the right stakeholders into the discussion, rather than allowing assumptions to turn into final product decisions.

The project moved at an unusually fast pace for a banking product: the entire pre-launch phase took around eight months. To speed up delivery, teams reused existing content blocks and translated them instead of creating everything from scratch.

This became a critical issue once it was clear how sensitive the German market is to language quality in banking products. Poorly adapted copy could easily undermine trust, regardless of brand strength or functionality.

At the same time, I was the only UX Writer across multiple teams. Large parts of the application were already implemented, which meant I had to locate texts directly in product flows, review them in context, and rework them under tight deadlines — while new features continued to arrive in parallel.

Once it became clear that language quality posed a product risk, I shifted focus from individual execution to system-level review. I introduced a QA process to review automatically translated content directly in application flows, rather than treating texts as isolated strings. The first version of this process was not effective enough, so together with developers and team members, I iterated on it several times to make it workable under pre-launch pressure.

I raised the issue with the Product Owner, explaining that while the problem did not yet look critical internally, it would become visible and risky after launch. This led to moving from my personal backlog to a shared backlog, allowing prioritization based on critical user flows and risk level.

As stakeholder involvement increased, I facilitated review workshops with product owners, stakeholders, and legal representatives. In these sessions, we reviewed proposed copy, discussed potential risks, and adjusted framing collaboratively within a regulated context.

During a later phase, the team temporarily expanded and additional UX Writers joined the project. In this setup, part of my role shifted toward supervision and coordination.

I structured their work by defining priorities, managing a shared backlog, and ensuring consistency, while deliberately keeping onboarding lightweight. This allowed them to contribute quickly without requiring deep immersion into all underlying processes, so the project could continue moving fast without losing quality or coherence.

Before launch, I reviewed and reworked approximately 80% of the application’s copy. This required repeatedly going back into the product, identifying frontend texts in context, preparing precise change requests for developers, and validating implementation through QA.

The scope of my work covered both mobile and desktop channels. I ensured consistency across platforms and coordinated updates as features evolved. Since development teams did not speak German, I explained every change very clearly — what needed to be updated, where it appeared, and why it mattered — and then verified the implementation through QA.

After launch, I addressed the remaining backlog during the stabilization phase, continuing to improve language quality and consistency as the product moved into active use. As a result, the product entered the German market with significantly improved language quality in critical user flows, reducing the risk of language-related friction in a highly trust-sensitive context.

The project did not end with launch. After the transition from pre-launch to post-launch, I continued working on the product as it entered an active phase of iteration and stabilization.

New features keep coming in, processes are still being refined, and I now work within an already established system. Some aspects became simpler after launch, while others introduced new constraints — maintaining consistency, working within defined patterns, and adapting to change without breaking what was already in place.

In this phase, I shifted from building the system to sustaining and evolving it. I continuously adjust priorities, support ongoing development, and maintain clarity and quality while the product keeps changing.

This project reinforced how critical language and cultural context are in regulated digital products, and how quickly quality can become a product risk if it is treated as a final execution step.

I learned the value of recognizing uncertainty early, facilitating the right conversations, and scaling decision-making through people and processes rather than individual effort.

I am especially effective in complex, evolving product environments where coordination, clarity, and risk awareness are essential — and where structure needs to be built while the system is already in motion.