What QA Taught Me About Product Design

I joined Bigpoint as an Associate QA Analyst. My job was to test live product updates, document issues, write test plans, and work closely with engineering and design teams to make sure features shipped without breaking things. It was not the role I had imagined for myself. I had a degree in game design and wanted to design systems, not test them.

But QA turned out to be one of the most formative experiences of my career, because it forced me to understand products from the inside out. When you test a feature, you interact with it in every way a user might, and many ways they should not. You develop an instinct for where things break, where flows are confusing, and where the design assumptions do not survive contact with real behaviour.

Designers tend to think about the happy path. QA thinks about everything else. What happens when the connection drops mid-transaction? What happens when the user taps the button twice? What happens when data loads slowly and the layout shifts?

That adversarial mindset turned out to be incredibly useful when I moved into design. Every feature I designed at Bigpoint after my promotion went through my internal QA filter first. I would ask myself: where will this break? What assumption am I making about user behaviour that might not hold? What happens at the edges?

When I built NavEire, this instinct showed up constantly. What happens when the GTFS-RT feed returns stale data? The system serves it from cache with a staleness indicator rather than showing nothing. What happens when the journey planner is overloaded? It returns a clean 503 with a Retry-After header rather than hanging. These are not brilliant design decisions. They are QA-trained reflexes.

After just over a year in QA, I was promoted to Game Designer based on design contributions I had been making alongside my testing work. I had been giving feedback not just on bugs but on product balance, user-facing mechanics, and flow problems. And the team noticed.

That transition taught me something I still think about: the path into product work is not always through a design degree or a portfolio of mockups. Sometimes it is through showing that you understand how products actually work at the ground level, and that you can spot opportunities for improvement that others miss because they have never had to break things apart systematically.

If you are in QA and want to move into design or product work, my advice is simple: do not just report bugs, report opportunities. Every test plan you write is a chance to show that you understand what the feature is trying to achieve and where it falls short of that goal. Frame your feedback in terms of user impact, not just technical correctness.

The people who get promoted out of QA are the ones who make the design team's work better, not just the ones who find the most issues. That shift in framing, from finding problems to improving products, is what makes the difference.