“How do I explain what I do at a party? The short version is that I say I humanise technology.”
— Fred Beecher, The NerderyI'm Flora, a product designer based in Berlin.
I didn't arrive here through a straight line. I started in sales and marketing at an IT company — the kind that connects banks to telco infrastructure, the unglamorous but necessary part of the tech world. I went to industry events like MWC Barcelona and WWC Madrid, met people building things, and realised I wanted to be closer to that. Not engineering, but not purely visual either. UX and UI showed up at exactly the right moment.
That winding route gave me something: I understood early that people don't make decisions based on what's objectively best. They decide based on what they can see, what they trust, and what feels manageable. It shapes everything I do.
Over three years I've designed for industries where the stakes are real and the project that shaped me most was BAT Agrar. It was my first lead role, clearly senior in scope, with little guidance and no prior domain knowledge. What I found was that there's always a first principle to return to: understand the people, understand the problem, then figure out the shape of the solution. What experienced designers call intuition is just that logic, internalised. The process makes it available before the experience catches up. The compliance staffing PoC — delivered in three weeks from a Miro board with no brief — was proof I'd actually learned it.
My instinct on any project is to diagnose before I design. The most expensive mistakes aren't visual — they're structural: a dependency missed, a mental model ignored, a workflow that looks right in Figma but breaks the moment a real user touches it. Complexity is rarely the problem; unnecessary complexity is. The job is to remove what isn't earning its place, while keeping what matters visible, controllable, and trustworthy.
Outside of work, I shoot street photography — people, cities, ordinary moments that are quietly beautiful if you slow down enough to notice them. I'm drawn to the mundane: a figure in a doorway, komorebi, the small things most people walk past. Whether I'm framing a shot or mapping a workflow, the instinct is the same — deciding what deserves attention, and what can be left out.
FAQs
-
It depends on the project, but there's a consistent instinct underneath it: diagnose before design, reframe before redesigning.
On every project I've worked on, the stated problem and the real problem have been different. With BAT Agrar, the brief was a usability overhaul — what the work revealed was a structural gap: 20 years of accumulated workarounds that had never been modelled correctly. On the staffing PoC, there was no brief at all — just a Miro board of technical terms and three weeks to deliver something trade-show ready. In both cases, the most valuable thing I did early wasn't design. It was mapping — users, tasks, dependencies, and the risks hiding between them.
I use AI selectively to accelerate parts of this: synthesizing research patterns, generating realistic prototype content, stress-testing logic. But the decisions that matter — what to scope, what to cut, what the structure needs to be — require judgment that no tool replaces.
The practical result: de-risking months of engineering time by getting the logic right before anyone starts building.
-
I try to be useful before the design phase starts — not just during it.
With PMs, I've found the most valuable thing I can do is make the problem visible before we talk about solutions. On the staffing PoC, I created a diagram mapping user tasks, flows, and dependencies before touching screens. The PO told me it showed him something he hadn't considered. That shared picture became the reference point the whole team worked from.
With engineers, I get into technical conversations early — not to design around constraints, but to understand them well enough to make them visible in the design. On BAT Agrar, that meant sitting with engineering leads to understand what was feasible before proposing anything. The decisions that stuck were the ones engineering could commit to.
With stakeholders, I've learned that disagreements about design are usually disagreements about priorities in disguise. When the BAT Agrar dashboard became a negotiation about who gets what on their overview screen, I didn't argue — I turned to user interviews to help users articulate priorities rather than preferences, then let usability testing make the call. The data resolved what opinion couldn't.
-
I try to define what success looks like before design begins — because metrics chosen after launch tend to confirm whatever happened, not evaluate it honestly.
On BAT Agrar, the KPIs were clear upfront: digital adoption and system performance under peak load. 500K+ price requests processed in two weeks and 1,000+ digital contracts completed in 60 days weren't vanity metrics — they were proof the system could handle the operational demand the previous platform couldn't.
Not every project has numbers. On the staffing PoC, success was a PoC credible enough to take to a trade show and a client whose lead stakeholder — reserved throughout the engagement — was visibly enthusiastic at the final meeting. On the healthcare project, success was a design that remains live in 2026, four years after launch — in a regulated environment where bad design gets replaced quickly.
I track both leading indicators during the process — usability testing results, where users stall, what they misunderstand — and lagging ones after launch. If 6 out of 8 users struggle at the same point in testing, that's not a user problem. That's a design problem, and it gets fixed before anything ships.
Let’s work together
Working on something complex? I'm currently open to product design roles in Berlin and remotely.