What QA Taught Me About Writing Better Game Design Specs

I joined Bigpoint as an Associate QA Analyst. My job was to test live game 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 live systems 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 designed NavEire, this instinct showed up constantly. What happens when live transport data is delayed? The app shows a clear stale-data state rather than pretending everything is fine. What happens when information is unavailable? The experience degrades gracefully instead of leaving people waiting. 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 game balance, player-facing mechanics, and flow problems. And the team noticed.

That transition taught me something I still think about: the path into game design is not always linear. Sometimes it is through showing that you understand how live features 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 game design, 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 game 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 player-facing features, is what makes the difference.