Complex products are my favourite kind of problem.

I’m Svetoslav Obretenov, a UX architect and product designer with a technical background.

I work on product structure, research, journeys and interaction design, and I’m comfortable following an idea all the way into implementation.

I’ve spent most of my career somewhere between design and software. Lately, AI has made that middle ground particularly interesting again.

  • UX Architecture
  • Product Design
  • Research
  • AI-assisted Development

A few things I’ve been working on.

Giving UX research somewhere useful to go.

Research often ends its life in a document or a presentation.

I’m building UX Craft to keep it active. It turns research, business context and product evidence into personas, user needs, priorities and other UX knowledge that can be used throughout product development.

The current work goes a step further: giving AI coding agents access to that context while they build.

  • UX Craft
  • Product strategy
  • UX architecture
  • AI
  • Design
  • Development
View project →

Splitting a restaurant bill should take less time than paying it.

smyat.ai started with a familiar problem: several people, one receipt and an unnecessarily long conversation about who had what.

I designed and built a mobile-first product around the moment people actually care about: finding their items, seeing what they owe and getting on with their evening.

  • smyat.ai
  • Product design
  • Interaction design
  • Research
  • Development
View project →

Sometimes the problem is already ten years old.

Products accumulate things.

New sections. New terminology. Workarounds that became permanent. Navigation designed around an organisation that has changed three times since.

A large part of my client work has been untangling products like these through research, information architecture and product structure.

  • Selected client work
  • UX architecture
  • Information architecture
  • Research
  • Product strategy
View selected client work →

I spend a lot of time with the messy bits.

Research that contradicts itself.

Navigation that grew one feature at a time.

Two teams using different words for the same thing.

A workflow everyone understands until somebody tries to draw it.

A product with dozens of screens and no obvious answer to a simple question.

This is usually where I come in.

I like figuring out how the pieces relate before deciding what the interface should look like. Sometimes that means research and diagrams. Sometimes it means taking apart an existing product. And sometimes the quickest way to understand a problem is to build a rough version and see where it falls apart.

I’ve always been more interested in why a product works than in producing another polished screen for it.

AI has brought me closer to the code again.

That part feels strangely familiar.

Before UX became my main job, I studied Business Informatics and spent a fair amount of time programming. Later, while working as a designer, I also built substantial parts of real product frontends.

For a long time those skills sat slightly to the side of my design work.

They don’t anymore.

I now use AI to move between research, product thinking, prototypes and working software much more freely. I can test an interaction instead of only describing it. I can inspect implementation decisions myself. And I can keep an idea alive for much longer before it has to be handed from one discipline to another.

There is a downside too. It has become remarkably easy to build the wrong thing very well.

That makes the UX work before and around the interface more important to me, not less.

With UX Craft, I’m exploring how the knowledge behind a design can travel with it: personas, research, user needs, priorities and the reasoning behind product decisions.

I want AI coding agents to have access to that context instead of seeing only the final mockup.

A surprising amount of my work now happens somewhere between a UX document, Figma and a terminal. I like it there.

I need to understand it before I can design it.

My background probably explains some of this.

I studied Wirtschaftsinformatik at TH Köln, so I never learned to think of design, business and technology as completely separate subjects.

When I design something, I want to understand what the system is doing underneath it. When somebody says a solution is technically difficult, I usually want to know why. And when a prototype can answer a question faster than another meeting, I would rather build the prototype.

The same applies at the other end of the process.

Before drawing anything, I usually try to explain the product back in plain language.

Who is using it? What are they trying to do? Where does the current product get in their way? Which complexity is unavoidable, and which complexity did we create ourselves?

From there, I use whatever helps answer the next question.

Research. A diagram. A rough flow. Twenty ugly wireframes. A working prototype. Occasionally some code that should never see production.

The medium isn’t particularly important to me.

Getting the decision right is.

Design, product and technology have always overlapped in my work.

I have more than 12 years of experience in UX, working across research, information architecture, interaction design, product structure and design systems.

My background in Business Informatics and earlier frontend development means I’m comfortable working close to both product and engineering teams, especially when a problem sits somewhere between user experience, business logic and implementation.

I’m Nielsen Norman Group certified and spent more than a decade working on digital products in Germany before starting my own practice and products.

More about my experience →

I like changing the perspective.

I split my time between Sofia and wherever work and life happen to take me — often the coast, the mountains, coworking spaces or a good café.

When I’m not designing or building something, I’m usually taking photographs, travelling, or finding an excuse to get on a skateboard, snowboard or surfboard.

That change of environment tends to be good for the work too.