UX Researcher & Service Designer

A practical, outcome-first collaboration model

This profile summarizes how I work as a UX researcher and service designer. I combine qualitative research with service maps and prototypes so teams do not build the wrong thing with exceptional polish. Over the years I have supported organizations that needed alignment across marketing, product, and customer success. The sections below follow how I run engagements end to end, from the first working session to production and continuous improvement. Everything here is sample content for demonstration; it is not a reference to any specific client, person, or confidential engagement. I structure work so you can see trade-offs, dependencies, and costs before we commit, and I prefer honest ranges over optimistic promises.

At a glance

• Primary line — Discovery that survives engineering reality
• Core skills — User interviews, Journey mapping, Workshops
• Set-up — hybrid with a parttime cadence and 7 years of relevant experience
• Languages — English, German for meetings and deliverables

A three-step cadence (typical)

1. A focused discovery pass — map outcomes, constraints, stakeholders, and the riskiest dependencies.
2. A thin end-to-end slice first — so integration, delivery, and observability are real, not deck fiction.
3. A clean handover — playbooks, decisions, and a backlog your team can carry without a prolonged dependency.

“I combine qualitative research with service maps and prototypes so teams do not build the wrong thing with exceptional polish.” — synthetic pull-quote for list 06; not a real client reference.

Demo links & resources: Delivery checklist (sample), Workshop outline (synthetic), Q&A and assumptions — all content is fictional and safe for public demos.

The longer read: how scope, risk, and quality connect

Quality is a product decision. I work with you to pick the right test pyramid: contract tests for APIs, targeted end-to-end suites for the highest-risk user journeys, and static analysis in CI to catch the categories of defects that your team is tired of re-opening. I encourage pairing and mobbing when knowledge transfer matters, and I leave your team with scripts, templates, and a definition of done that is enforceable, not aspirational. Performance work follows evidence from traces and budgets rather than pre-emptive rewrites, and I document hotspots with reproduction steps your developers can re-run locally. Accessibility and internationalization are treated as requirements with concrete checks, not late-stage tickets.

The user interface is where your promise meets reality. I combine qualitative insight from interviews and sessions with analytics that show where workarounds and silent drop-offs begin. I translate that into a coherent interaction model, component library usage, and writing patterns for empty states, errors, and long-running operations. I prototype at the right fidelity: sketches when the problem is poorly understood, high-fidelity when alignment between marketing and product is the blocker. I coordinate with brand and content so the tone of voice in the product matches the story you tell on the website, and I prepare engineering handoff that reduces rework on spacing, copy, and motion.

Data engineering only matters when the business can trust the numbers. I set expectations around freshness, idempotency, and reconciliation between sources. I am explicit about the difference between a dashboard for day-to-day operations and a dataset for modeling, because mixing them is how organizations ship optimistic forecasts by accident. I have worked with dbt, streaming ingestion, and batch warehouses; I will recommend the mix that fits your data volume, skill mix, and regulatory constraints. I document lineage, ownership, and SLAs, and I build the first set of data quality rules that are painful enough to fail loudly when the pipeline breaks, not months later in a board deck.

I treat APIs as public contracts even when the audience is internal. Versioning, deprecation policy, and error models are part of the first design review, not a retrofit after launch. I favor standards where they exist — OpenAPI, problem+json, OAuth2 patterns — and I document the intentional deviations so future maintainers are not left guessing. For integrations with third parties, I map retry semantics, idempotency keys, webhooks, and data residency expectations up front, using realistic sandbox data before anyone commits a launch date. That discipline reduces the integration surprises that show up in production under customer load.

Appendix: extra detail (still synthetic)

I approach leadership as a system: clear goals, protected focus time, and a rhythm of reviews that is honest about blockers. I have led mixed seniority groups across time zones, and I structure ceremonies so that distributed teammates have equal access to context. I work with people leads on growth plans, not only tickets, and I am explicit when trade-offs are technical versus organizational. When a programme is in distress, I reset the narrative around outcomes and a minimal recovery path instead of a sweeping rewrite, because morale and momentum often return faster with a small win on the critical path.

Security and reliability are not separate from delivery speed. I use threat modeling light enough to finish in a morning but concrete enough to drive a backlog. I am pragmatic about control frameworks: I map your risks to a sensible subset of actions instead of a checkbox parade. I align with legal and DPOs on retention, sub-processors, and data subject workflows where personal data is involved, always using test personas for demos — never real individuals from production. For operational resilience, I make sure on-call has runbooks, escalation paths, and a blameless postmortem culture that produces durable fixes.

Discovery always starts with constraints: business outcomes, team topology, security posture, and the timeline you are willing to invest in. I run structured workshops that turn vague goals into measurable acceptance criteria, service boundaries, and a backlog that your stakeholders can read without a glossary. I document decisions in a lightweight decision log, link them to your roadmap, and make sure the same context travels into engineering — so scope creep is visible before it is expensive. Where legacy systems are involved, I start with a thin slice that proves integration patterns and de-risks the hardest dependency first. That sequence keeps momentum while protecting production traffic and on-call engineers from unplanned work.