About
I started out as a web developer and realised the more interesting questions weren't in the code. Now I solve them in discovery.
Career
For over 20 years I've worked at the intersection where business, technology and user needs collide. I'm not a UI designer who only shapes surfaces — I conceive end-to-end processes and create the structures in which great products can emerge. My career spans digital pioneers like SinnerSchrader and XING, leadership roles such as Director Product Design UX at SWIPE/Accenture, and strategic consulting in regulated environments at Signal Iduna and on the AOK account at Experience One.
That complex systems are my speciality is something I got to prove under extreme pressure: for the Federal Ministries of the Interior and of Health, I was responsible for the Digital Entry Registration (Digitale Einreiseanmeldung) — a national crisis system that we scaled in just 8 weeks from a paper slip to an online registration, connected to more than 370 health authorities, and which the RKI recognised as a lighthouse project.
Most recently, as Head of Product Design & UX at Blockbrain, I worked on exactly the question that will define the future: how do you orchestrate complex AI applications and bots so that they become safe, reliable tools — without the technological complexity landing on the user? Through systemic information architecture and precise user guidance we cut basic support requests by 40 percent, among other results, and secured the foundation for a successful €17.5M Series A.
I live and work in Hamburg.
How I work
Foundation before aesthetics
Scalable architectures are the real foundation of good products. Lasting success doesn't come from surface cosmetics, but from structures that grow stably.
Systemic thinking
I think architectures through to the end — technical feasibility and the administrative receiving end included. Risks and critical breaks are resolved before they reach production.
Context agility
I grasp new, complex subject areas in the shortest of time and am immediately productive. Even with rapidly changing requirements, I stay capable of acting from day one.
Collaboration as equals
Lasting product success needs substance. I equip teams and clients with strategic clarity and operational competence for the long term — a basis that works beyond the current project cycle.
Attitude
Trust is the most valuable resource for solving complex questions and making products successful.
I earn trust through calm under pressure and results built on stable decisions. That's why teams and clients bring me in beyond the original mandate.
What holds for my project work holds all the more for my teams. A team that feels safe delivers reliably even under pressure — and that is the very basis of trust. Ensuring this isn't a question of the setting, it's the job of the lead.
Teaching
Training you apply the next day
For over a decade I've passed on what I learn in projects. At HAW Hamburg, and in corporate formats for Boehringer Ingelheim, AOK, Signal Iduna and Accenture.
UX Basics
Two days from UX models and ISO 9241 to design thinking and agile product development. Participants leave the room with methods they can apply in their own project the next day.
Conversion optimisation
Data-driven methods, with self-developed checklists and self-tests. Participants learn to run optimisation themselves rather than commissioning it.
Product Field
A workshop format for establishing a shared product strategy across multiple departments. Silo thinking turns into a shared picture of the product.
For enquiries about training for your team: oliver@oliver-annen.de
Talks & Workshops
I speak about the questions that, in most projects, get asked too late.
-
Design without a mandate
How to influence systems you're not responsible for. On scope extensions nobody commissioned, and why that's sometimes the only right move.
-
Calm as a competence
Composure under pressure isn't a character trait, it's a skill. Why ER teams, fire brigades and good design teams use the same method: clean preparation, clear roles, trained response.
-
The question behind the brief
Every brief describes a problem. Usually that's not the actual problem. On the method for finding the difference before anyone starts building.