Research on top app store games indicated that casual players who engage (and spend) the most prefer to play in short bursts, like during a commute. The same players tended to value attainable progression within those limited windows of time.
Dragonfire's hypothesis is that, if those complexity-curious players could be spared the friction points common to our market competitors, they would be more likely to engage with the deeper progression offered.
The core design challenge of Dragonfire revealed itself: Bring the depth of the 4x strategy genre to a casual mobile player base.
Three basic player personas were established by the product and UX team early in pre-production. These basic profiles would provide guidance for usability decisions throughout development.
Our primary audience. The complexity-curious casual player appreciates strategy and depth in their mobile gaming, but might struggle with the complexity and information density typical for the genre.
Fans of the popular Game of Thrones book and TV series, and/or gamers with a passion for strategy and RPG games. This player values robust social features and is likely to bring their friends along.
Casual mobile gamers who enjoy engaging with top app store games. This player will have high expectations for accessibility.
Dragonfire follows the classic 4x strategy loop with seasonal content, allowing the player to build on their legacy.
The UX team established these pillars early on, which would inform our decisions going forward. They were tested and tweaked throughout the course of development.
The complexity of the genre can be learned over time, introducing the player to new game mechanics one decision at a time.
Multi-step tasks are a common point of frustration and drop-off, especially for casual players. To avoid overwhelming the player's cognition, complex tasks should be broken down into smaller steps.
Decide what information or decision should capture the player's attention first using principles like size, value, color, and proximity. The eye should flow comfortably over the screen layout.
Immersing the player in the world of Game of Thrones, as well as inviting them to be a part of it, requires a UX that doesn't intrude on the experience.
The strategy genre requires a large amount of learning in a short time. When players demonstrate their learning, reinforce that learning with rewards.
In fast-paced strategy games, players need to be able to assess another player at a glance. Our main player personas, casual and mid-core players, had to be able to access the information they needed quickly and consistently.
End-game combat can be fast-paced, and decisions regarding other players must be made quickly.
Early wireframe explorations of the throne room.
I shepherded the user experience of the throne room from early preproduction to after the feature shipped. I worked with the product owner and game designer to understand the player need, the business KPIs involved, and explore solutions with them. Once a direction is decided on, I sought input from engineers, QA, 3D and tech art to understand and work with the implications for their teams.
Screenshot of the interactions in the Figma prototype.
I began defining the player need by looking at how our market competitors approached this need. I interviewed team mates who had experience with the titles, and watched some of them demonstrate how they use the screen while thinking out loud. I interacted with them myself, paying attention to how my brain processed the information and how accessible it felt.
I observed that the more successful examples were ones that surfaced relevant information only, nesting other information behind taps. Screens that centered character art had a clear, consistent information hierarchy with helpful icons where needed.
A collection of player profile examples from various market competitors.
Early in preproduction, it was unclear what kind of stats and information would populate this screen. Thankfully we had several market competitors to refer to, allowing me to make some educated guesses with my placeholder stats. It was a reminder that uncertainty and ambiguity in a design is OK! As long as the goals of the feature and the product are in focus.
An early pre-production wireframe of the Throne Room. Stats and other relevant info were invented to be replaced later on with more accurate reflections of the final product.
After some exploration, I went ahead with this version, which centers the beautiful character art. Important player details are arranged on the left side of the screen, with cosmetic details at the center, and social details and account options on the right. Centering the avatar would showcase the character art and their custom banner. An immediate impression of the player's identity would be made, from which the player's attention would go to either important stats or social signals.
A screenshot of the final shipped version of the Throne Room.
In preproduction, I researched our prospective players and our competitors to understand this feature and what it would look like for our game. I worked closely with the product owner and other stakeholders to create a clickable prototype to prove my approach, with supplemental documentation to make implementation needs clear and accessible to developers.
When the feature was developed, I participated in playtesting and collected feedback to inform future improvements. Each stage required the product owner and stakeholders to sign off on the direction of the feature. When the feature was developed and in testing, I received a lot of feedback about the color picker in particular. Color options had originally been shown separately from the sigils and the background of the banner, but players wanted to be able to review both at the same time. The result was a pivot to this more approachable color picker solution.
A screenshot of all the documentation created around the Throne Room, spanning from preproduction to post-launch.
I interviewed the product owner and game designer on their priorities, and defined UX's particular goals for dragon feeding. I then examined similar solutions from market competitors like Whiteout Survival and LOTR: Rise to War. I proposed an approach with visuals and a clickable prototype, checking in with stakeholders frequently along the way.
.png)
