Gianina Burca

My Path

From academic research to product strategy

My background isn't the typical designer origin story. I came into this field through research and behavioral science, not through art school or coding bootcamps. I studied Psychology at Alexandru Ioan Cuza University of Iasi and built my early career around understanding how people make decisions, what frustrates them, and where products fail to meet expectations.

Before UX had the label it carries today, I was already doing the work. Sitting with users, watching them struggle through interfaces, documenting the gap between what product teams assumed and what actually happened on screen. I ran usability sessions where the findings contradicted every assumption the team had. Those moments are uncomfortable. They're also the ones that end up mattering most.

Over the years I moved through roles that gave me different lenses on the same core problem: how do you make complex things usable without dumbing them down? I worked on SaaS platforms, mobile applications, enterprise tools, and consumer products. Each category has its own pressure points, and that range taught me to avoid one-size-fits-all solutions.

Work

What I actually do at Product Rocket

I lead UX strategy and research. In practical terms, I'm the one who figures out what the product should do before we start deciding how it should look. User flows, information architecture, interaction models, research synthesis, usability testing. The stuff users never see but immediately feel when it's wrong.

On the Signals project (a research integrity platform), I had to reconcile two opposing needs. Compliance officers needed to see dense, auditable data. But they also needed to find specific risk indicators quickly across hundreds of reviews per week. Users reported spending 45 seconds just locating a single risk level. We got that down to 10 seconds. The fix wasn't removing data. It was restructuring the hierarchy and sequencing when information appeared so the important stuff surfaced first.

For Anylyze, a data analytics platform, the challenge was different. The backend was powerful, the interface was not. Users described it as "drinking from a firehose." I ran the discovery process: session recordings, user interviews, task analysis, heuristic evaluation. We found that 71% of user errors came from interface confusion, not data misunderstanding. The redesign cut errors by 71% and sped up task completion by 38%.

I also lead client workshops and stakeholder alignment sessions. Getting a room of people with conflicting priorities to agree on what "success" looks like for a product is hard. What helps is having data. When everyone's looking at the same research, there's less room for opinion-based arguments, and projects move faster.

Approach

Research isn't a phase. It's the foundation.

Too many product teams treat research as a checkbox. They run a few interviews during discovery, compile a report that gets skimmed, and then build whatever was already planned. I've watched that pattern produce expensive products that solve the wrong problems.

My approach is different. Research runs through the entire project, not just the first two weeks. I identify what users actually need (which is rarely what they say they want). I test assumptions with prototypes before anyone writes production code. And after launch, I check whether the changes actually moved the numbers we predicted. If they didn't, we figure out why and adjust.

I use whatever methods fit the question. Five-person moderated usability tests for some things. Analyzing thousands of session recordings when I need behavioral patterns at scale. Card sorting when the information architecture needs rethinking. I pick the tool based on what I'm trying to learn, and I'm skeptical of teams that always reach for the same method regardless of the problem.

One thing I won't do is design by committee. I listen to stakeholders, but when their instincts conflict with what user data is showing, I'll present the evidence and make a recommendation. I'd rather have that conversation early than watch a product fail slowly because nobody wanted to push back.

Beyond Work

What drives the way I work

I co-founded Product Rocket with Vlad because we think about products from opposite ends. He starts with how something should feel on screen. I start with whether it should exist at all. We argue about it constantly, and the products are better for it. A bigger team would probably smooth out that friction. We'd rather keep it.

Working internationally (Romania, Europe, the US, Israel, UAE) changed how I think about user needs. I ran research sessions where language barriers forced me to pay closer attention to behavioral cues instead of relying on what people told me. Watching someone hesitate before clicking teaches you more than a survey ever will. Cultural context affects everything from reading patterns to trust signals, and ignoring it is how products fail in new markets.

I care a lot about accessibility and inclusive design. Not because someone told me to, but because I've noticed that the constraints accessibility introduces tend to make everything better. A clear information hierarchy that works for a screen reader? It also works better for someone distracted on their phone on the bus. I've started designing for edge cases first on most projects. It raises the floor for everyone else. I also keep investing in my own growth: I completed the Dribbble Product Design Academy in 2023 and the Product Psychology course by Growth.Design in 2025, both of which sharpened how I connect design decisions to real user behavior.