I work primarily with international organizations, NGOs, research institutions, and large corporations — teams that deal with complex data and need to communicate it clearly to decision-makers, funders, or the public. Past clients include WHO, the World Bank, Deutsche Bahn, Mozilla Foundation, and Adidas.

I'm not a web designer, visual designer, or illustrator. I don't create static infographics, brand identities, or design concepts that aren't tied to data or interaction. If your project doesn't involve data visualization, user experience design, or AI transparency, I'm probably not the right fit — and I'll tell you that early.

Neither label fits perfectly. I'm an independent designer with 15+ years of experience working at the scale most clients associate with agencies — long-term engagements, international institutions, complex multi-month projects. I work alone, which means you always work directly with the person doing the work. No account managers, no junior handoffs, no overhead. For projects that genuinely need a larger team, I bring in trusted collaborators and remain the accountable point of contact throughout.

Most of my clients are large institutions, and many have asked themselves this. What I offer isn't the bandwidth of an agency — it's continuity, direct expertise, and someone who stays accountable to your project from discovery to delivery. No account managers, no handoffs between people you've never met. If a project genuinely requires a larger team, I can help scope that and connect you with the right collaborators.

The starting point is a free 30-minute call — no pitch, no pressure. From there, if the project is a fit, I put together a clearly scoped proposal with deliverables, timeline, and cost. Most engagements begin within two to four weeks of that first conversation.

Yes — many of my engagements are retainer-based, spanning several months. For teams that need a consistent design partner across multiple workstreams, an ongoing arrangement often makes more sense than a fixed project scope. This is worth discussing early if you have recurring needs rather than a single defined deliverable.

The visual quality is deliberate, but it's not the point. My work is about helping people understand and act on data. A beautiful chart that misleads or confuses has failed. I push back when a client's instinct would make something look impressive but communicate less clearly — that's as much a part of my job as the design itself.

The most important thing is a willingness to think through the problem together before jumping to solutions. On the practical side: some understanding of your audience, access to the data or a realistic plan for how to get it, and clarity on who the internal decision-makers are. A polished brief is not required — that's part of what the discovery phase is for.

Not usually — at least not in any meaningful way. Data is the raw material. I can help you think about what data you'll need and how it should be structured, but I can't design a visualization without understanding what the data actually contains, how it's distributed, and what its limitations are. Starting before the data exists tends to create rework.

Earlier than most clients expect. Ideally, I join before requirements are fully fixed — in the phase where you're still defining what you're trying to achieve and for whom. Bringing me in after the data structure or platform architecture is locked can significantly limit what's possible.

Yes, and I prefer it. Understanding the strategic context — who the stakeholders are, what decisions this tool needs to support, what's politically sensitive — directly affects the quality of the design. I'm not just someone who takes a brief and disappears. I work best when I'm close to the thinking.

Five phases: Discovery, Definition, Ideation and Prototyping, Design and Delivery, and Support and Optimization. The weight of each phase depends on the project, but I don't skip discovery.

I build feedback loops into every project — typically structured rounds at the end of each phase rather than continuous open-ended revision. This keeps things moving and prevents scope from expanding silently. I'll tell you upfront how many rounds are included, and we agree on a process for collecting feedback from your side before work begins.

I can, and for public-facing tools I often recommend it. User research — interviews, usability testing, feedback rounds — significantly reduces the risk of building something that doesn't work in practice. This is worth discussing early because it affects timeline and budget. For internal tools with a known user group, lighter-weight approaches often suffice.

That depends on the engagement. It can range from interactive data visualizations with code handoff, to UX wireframes and a visual design system, to documentation like a data style guide or model card. I specify deliverables clearly in the proposal. One thing I always aim for: handoff material your team can actually use without me in the room.

Both, depending on the project. For data visualizations I often work directly in code — D3.js, Observable, Svelte. For interface and UX work I typically deliver production-ready designs that your development team implements, and I can support the handoff closely. If you need end-to-end delivery including development, we discuss that upfront.

It varies by project, but the most common outputs fall into a few categories. For interactive products: dashboards, data exploration tools, and scrollytelling or narrative data journalism formats — long-form visual stories where the reader moves through data step by step. These are often built for public communication, annual reports, or editorial contexts. For UX and interface work: wireframes, prototypes from low to high fidelity, and production-ready visual design — depending on where in the process you need me and how much your own development team can carry. For research and communication: data explorations, visual analysis, and chart-based communication formats for journalism, science communication, and institutional reporting. Everything is bespoke — I don't offer fixed-scope packages. The right deliverable depends on your data, your audience, and where the project actually starts.

Occasionally, yes. Some clients come with a specific question — how to structure a data visualization system, whether a planned approach will work for their audience, or a review of an existing tool or dashboard. I'm open to those conversations, and they sometimes lead to a longer engagement, but they don't have to. If you're not sure what kind of help you need yet, the free consultation call is the right starting point.

It varies significantly by scope. A focused data visualization or dashboard project typically runs six to twelve weeks. A full UX and interface design engagement for a complex platform can run three to six months or longer. I'll always give you a realistic timeline in the proposal — not an optimistic one.

Most of my clients are international — UN agencies, European institutions, US-based foundations — so working across time zones is the default, not an exception. I work in CET and respond within two working days. For complex projects, I recommend regular video calls at key milestones, scheduled early rather than left to chance. For kick-offs or key workshops, onsite is occasionally possible depending on location and timing.

English and German. Most of my international client work happens in English; for German-speaking clients in the DACH region I work in German throughout.

You do. All final deliverables — designs, code, documentation — are transferred to you on project completion. I retain the right to show the work in my portfolio unless we agree otherwise, for example in cases involving confidential data or sensitive internal tools.

I typically work on a project basis with a clearly scoped proposal, or on a day-rate retainer for longer engagements. If budget is genuinely tight, the most useful conversation is about scope — what's essential versus nice-to-have — rather than about discounting.

With a free 30-minute consultation call. No pitch, no pressure — just a conversation to understand what you're working on and whether I can help.

For data visualization I work primarily with D3.js and Svelte — tools that give me full control when standard charting libraries hit their limits. For map-based platforms I use Mapbox or Leaflet depending on the project's needs. Interface and UX design happens in Figma. I'm comfortable moving between design and code throughout a project rather than treating them as separate handoff stages.

Most of my work sits at the intersection of data and high-stakes decisions, across a wider range of sectors than people expect. On the institutional side: international organizations including WHO, UNESCO, and the World Bank Group; government bodies including the German Foreign Office; and research institutions including ACLED, EPFL, and universities in Germany and Switzerland. In journalism and science communication: Zeit, brand eins, Scientific American, and Google News Lab. In the NGO and think-tank space: Mozilla Foundation, the International Coffee Organization, Green Web Foundation, and Interface (formerly Stiftung Neue Verantwortung). On the corporate side: Deutsche Bahn, Adidas, Vodafone, REWE, Universal Music, and one of the Mag 7 technology companies under NDA. I've also worked with startups and embedded within specialist data visualization studios as a collaborator, including Truth & Beauty, Studio Nand, and Interactive Things. The common thread across all of these is complexity — data that is hard to interpret, audiences that aren't technical, and decisions that matter.

Accessibility is part of my process, not an afterthought. As someone with mild color blindness myself, I check color contrast, label clarity, type sizes, and visual encoding choices as a matter of course — not only when clients ask. That said, full WCAG compliance is a shared responsibility between design and development, and I'll be honest: no data visualization is 100% accessible in every scenario. What I can ensure is that the design doesn't create unnecessary barriers, and that the choices I make hold up under real-world accessibility constraints. For projects where formal WCAG compliance is required, I'm comfortable working within those guidelines and can flag where tradeoffs need to be discussed.

Yes — and it's often the right starting point. Working within an established visual language creates consistency and speeds up implementation. That said, most brand systems weren't built with data visualization in mind, so some adaptation is almost always needed. Color palettes that work beautifully in marketing contexts can break down when applied to charts — contrast, sequence, and categorical distinction all have requirements that general brand guidelines don't anticipate. Part of what I bring to those projects is bridging that gap: extending your existing system with data-specific components that feel native to your brand but actually work for the job.

Yes. I use AI tools selectively — primarily for research, writing support, and parts of the design process where they genuinely help. I'm transparent about this with clients.

Yes — this is one of my three core service areas. AI systems only create value when the people using them, or accountable for them, can understand what they produce and why. I design the visualizations, interfaces, and documentation that close that gap.