Skip to content
Fedor Molot
Fedor Molot

Head of Design · Valencia, Spain

Consistent product
design thinking

Head of Design at Mobupps, an 80-person B2B advertising technology company — thirteen years building the design function from zero: the design system, the brand, a small team, and the products the business runs on. My craft is turning dense, data-heavy software into interfaces people can move through without stopping to think. And I work across the whole product — strategy, design, production code, analytics — so my design decisions are grounded in how products are actually made, and judged by what they change for the business.

  • 13 years

    One company, one design function

    Built the design function at Mobupps from nothing — the design system, the product work, the brand and a small team — and still hands-on in every part of it.

  • 3 – 6h→ 2min

    To rebuild a client deck on-brand

    Designed and built the internal platform that does in about two minutes what used to take a designer half a day, and took the designer out of the critical path entirely.

  • 2 products

    Owned end to end — strategy, design, production

    The Mobupps website and the internal AI platform are mine end to end — what ships next, the design system on both the design and the engineering side, the production code the engineers review, and the analytics that show whether it worked. Understanding every layer of how a product gets made is what turns a designer into a product owner — and that is the level I work at.

Selected work

An internal AI product I designed and built, a fintech concept researched and usability-tested, and a brand-led interface exploration. Each is written up the way I would explain it to a team — the constraint, the options I turned down, and the decision I got wrong.

How I work

One philosophy runs through everything below: work out how much of a problem can be settled by rules, and spend the expensive thing — a designer's attention, or a model — only on what is left. I have now made that call three times, on three unrelated products, and it has been the right one every time.

  1. 01

    I design for the person who has it open all day

    Nobody opens a reporting dashboard for pleasure. The people I design for have a job to finish and my screens stand between them and finishing it, so the win is never a first impression — it is the four hundredth use, when the interface has to be invisible. That single framing decides most of what I do: remove a step before adding a feature, and stop when someone gets through the flow without thinking about it.

  2. 02

    When the same request keeps arriving, I remove the reason for it

    Most of what lands in a design queue is not a new problem. It is the same problem arriving again because nothing upstream changed. Rebuilding a client deck by hand cost a designer three to six hours every single time, and no amount of staffing was going to fix that. I would rather spend a month removing the queue than a career servicing it.

  3. 03

    A design system is a contract, not a request

    A component library people are asked to remember is really a rule someone has to enforce, and enforcement is where design leadership quietly disappears. On the internal platform, layouts are chosen and filled by code against fixed rules, so being on-system is the path of least resistance instead of an act of discipline. Consistency stops being something to police. Judgement is what the team gets paid for.

  4. 04

    AI is the last resort, not the first idea

    The interesting part of the AI product I built was not adding a model. It was working out how little of it the problem actually needed. A deterministic scorer resolves the overwhelming majority of decisions at zero cost, and the model is consulted only where the rules genuinely cannot decide — and even then it may only move the author's own words, never invent new ones. Knowing where AI does not belong is now part of the craft. I have since made the same call twice more: on the assistant answering questions on this page, and on a tool I use daily. The cost and the failure modes both live in the part you hand to a model, so hand it less.

  5. 05

    I prototype in code, because that is where the argument ends

    A static mockup produces opinions. A working thing produces evidence. I build the real version, hand it to the people who will live in it, and let them tell me what is wrong — which is faster, and considerably less political, than defending a Figma file in a meeting. Certified by Anthropic in Claude Code and Agent Skills.

  6. 06

    I would rather have one honest number than five flattering ones

    A crashed build, a failed export, a dropped edit — those vanish forever if nothing records them, so those are the things I instrument. Everything else can be found out by asking someone. And at a small user count I report names rather than percentages, because a percentage of a dozen people is a lie with a decimal point in it.

Tools I work in

  • Figma
  • Claude Code
  • Claude Design
  • ChatGPT
  • Contentsquare
  • HTML & CSS
  • JavaScript
  • Python

Get in touch

I like talking to people living in the same problems: dense B2B interfaces, design systems that hold without being policed, and what changes when a designer can also build.