Fortnite Save the World
Player Experience QA · Epic Games · 2017

Inside the storm
before the world
knew its name.

In 2017 I was embedded on the QA team for Fortnite Save the World before Battle Royale launched and changed everything. What I learned about design at that scale changed how I think permanently.

Role: Player Experience QA Studio: Epic Games Product: Fortnite Save the World Year: 2017 Format: Remote
01 Context

The original Fortnite.
Before everything changed.

In 2017, Fortnite was a cooperative survival game called Save the World. Players built structures and defended against waves of enemies. It was complex, deep, and not yet a cultural phenomenon.

Three months after my engagement ended, Epic shipped Battle Royale as a free add-on. Within 90 days it had 45 million players. The codebase, UI systems, and interaction patterns I had tested were all underneath it.

I was not on Battle Royale. But I was inside the engine, the design vocabulary, and the live-service philosophy that made it possible. That context is irreplaceable.

2017
Year of engagement
Pre-Battle Royale launch
350M+
Players on the platform today
Every one touches systems I tested
STW
Save the World the original mode
Cooperative survival, base building, wave defense
Remote
Fully distributed
Embedded directly with the design team
02 The Work

What player experience QA
actually looks like inside Epic.

QA at this level is not finding typos. It is systematic pressure-testing of design decisions against real player behavior, then translating what breaks into language designers and engineers can act on.

🎮
Deep Play Sessions

Extended sessions across STW's core loops: base building, hero loadouts, mission structures, and progression systems. Not surface testing. Hours-deep, edge-case hunting.

🔍
UX Issue Identification

Flagging friction in the player experience layer specifically, not just crash bugs, but moments where the UI communicated the wrong thing or where player intent and system response were misaligned.

🤝
Designer Collaboration

Direct working relationship with the design team. Reproducing issues, providing player perspective, and translating observed friction into structured feedback that designers could act on.

📋
Structured Documentation

Every issue documented with reproduction steps, severity classification, and player-impact framing. The difference between a bug report and a design insight is how you frame what is broken and for whom.

Patch Validation

Validating that fixes shipped correctly and patches did not introduce new friction elsewhere. Live-service games move fast. The job does not stop when a fix ships.

🧠
Player Behavior Modeling

Developing an intuitive model of how players think, what they expect, and where they get lost. At Epic's scale, a single misread affordance is a support ticket for millions of people.

03 The Arc

A few months at
the right moment.

Timing in the games industry is everything. I joined Save the World during its final pre-launch development phase, when design decisions were still being stress-tested before they shipped to the public.

Being inside a product at that moment, when no one outside knows what it is yet and the team is still discovering what works, is something you cannot get from a post-launch engagement. You see the decisions in the making, not the decisions already made.

Early 2017
Embedded on Save the World QA

Remote engagement begins. STW is in late development. Cooperative survival, base building, wave defense. Complex systems, deep progression, ambitious UI serving wildly different player types.

Mid Engagement
Deep into hero systems and mission UI

Working directly with designers on player-facing systems: hero loadouts, inventory, mission select, progression feedback. Every system has to communicate correctly to players of every skill level simultaneously.

Late 2017
Engagement concludes. Battle Royale launches.

Three months after I finish, Epic ships Battle Royale as a free add-on. It reaches 45 million players in 90 days. The foundational systems I tested are underneath all of it.

The Lesson
What scale actually means

A UI decision that is 95% right at 10,000 players is a crisis at 350 million. That gap between good enough and right is what Epic taught me to see.

04 Design at Scale

What I learned about design
when the audience is everyone.

STW had a broad player base: young players, veterans, casual players, hardcore progression chasers. Designing for all of them simultaneously, across different platforms, with no ability to ask questions in the moment. That is the design challenge at Epic's scale.

350M+
Players today

Every design decision in a product at this scale has to survive contact with every type of player simultaneously. There is no edge case. The player who reads nothing, the player who reads everything, the 9-year-old and the player with 3,000 hours they all hit the same UI at the same time. What breaks for one person breaks for millions.

📐
Affordances must be obvious, not clever

At scale, clever UI is a liability. If a button's function is not immediately clear to a first-time player, that is a design failure, not a player failure. STW's complexity made this lesson impossible to ignore.

🔁
Feedback loops are load-bearing

Players need to know what happened, what it means, and what to do next. In a wave-defense game with deep progression, missing any of those three is catastrophic. I evaluate every interaction against all three simultaneously.

🌐
Platform assumptions kill products

What works with a mouse does not work with a controller. What works on a monitor does not work on a TV from eight feet away. Cross-context testing was not a checklist item at Epic. It was the whole job.

Speed of decision is a design variable

In a live-service game, the team ships constantly. Design quality is not just about the decision it is about making the right decision fast, communicating it clearly, and validating it before it reaches 300 million people.

05 What It Gave Me

The permanent changes
to how I think.

Being inside Epic during that period did not just add a credit to my resume. It fundamentally changed the lens I apply to every design problem since.

01
I validate with the same rigor I design

At Epic, testing was not the thing that happened after design. It was how you knew the design worked. I brought that mentality into every project since. The design is not done until it has been stress-tested.

02
I think in player types, not average users

Fortnite does not have an average player. Neither does any real product. I stopped designing for a fictional average and started designing for the full distribution: the novice, the expert, the rushed, the lost.

03
I speak both languages

Working with Epic's designers while producing structured documentation gave me fluency in both worlds. I can translate between design intent and engineering implementation in ways most people on either side cannot.

04
Live-service is a design discipline

Products that ship continuously require a different design posture. You have to design the system, not just the screen, to absorb continuous change gracefully. Epic taught me that posture.

A design decision that is 95% right at 10,000 players is a crisis at 350 million. That gap is what Epic taught me to see.
Angela Clemons on designing at scale
Angela Clemons
Angela Clemons
Senior UX/UI Designer · Game UX · Enterprise · Mobile

10+ years designing and shipping products across AAA games, enterprise software, and healthcare. If you need a designer who has been inside the room at Epic, Amazon, Rockstar, and Mayo Clinic, let's talk.