What is UX Design?
User experience design is about understanding the design intent and intended audience of the game that it is supporting, and ensuring that this intent is properly received by that audience through their experiences with it. This can encompass all experiences a player has with a game, inside and out, but it is primarily focused on those experiences had within the game. A UX designer works closely with the design and creative teams, as an advocate for the player, using a variety of methods to visualize and communicate solutions, while functioning as a bridge between development and the players. It is important to have a solid understanding of what the design intent is (both high and low level), who the audience is, and what their expectations are, so that the experience that is intended is the one that the player actually has.
If you are interested in learning more about UX design, especially as it relates to games, I highly suggest checking out a great primer on the subject; The Gamer’s Brain by Celia Hodent.
What about UI Design?
User interface design is an important facet of user experience. It is concerned with supporting the UX of the game through the interactions players have within it. Often this means ensuring information is accessible and readable, while decision making is seemless and efficient. However, I believe that UI design should never be at odds with the intended player experience, and unlike UI design for applications, this means that the primary focus is not always on accessibility. Friction is an important aspect of design, and is sometimes necessary to enhance the player experience. An example of this would be a more difficult control scheme for a horror game, where struggles with these interaction systems enhance the tension that is desired by the designer and player alike.
Analysis is about understanding the design intent and how the work ahead of me relates to it, as well as understanding the audience and how this work will affect them. To understand design intent, I first consult any available and appropriate documentation, gather questions, and have conversations with relevant team members. Next, if the intended audience is well understood and documented, I will refer to this research, and consult the User Research team, if they are available. Otherwise, I set about defining who the audience is, creating personas, and using other methods to visualize and communicate this with the team. Market research is frequently critical to this process. I look to see how other games tackle similar issues, and the related player response. I will also look at how comparable games in the genre approach this, how their audience has reacted to past decisions, and how designs have grown and evolved with the audience. This research will expand beyond the game industry as appropriate, especially when dealing with unique aspects of the game I am working on.
Based on the findings of analysis I will conceptualize a solution, or a set of solutions. This can include sketches, wireframes and other tools to organize and visualize them. Whenever possible I will translate the most promising solutions into an interactive wireframe or prototype, as I find this provides far better feedback and leads to better decision making. During this step, I will approach these designs from as many appropriate perspectives as possible. It is highly iterative, I am looking to identify flaws early and improve on designs quickly. Once a design holds up to my internal scrutiny, I am ready to show it to others.
I gather feedback from team members and other internal resources first. I will observe internal tests (tailored to the needs of the design) and gather feedback through conversations and surveys. I will move back to the design step and iterate further as needed. Once the design holds up the scrutiny of the team, the evaluation will progress toward gathering feedback from players (working with a User Researcher to achieve this, if that is an available resource.) This will include different methods of testing in controlled environments, observing how the players perform, and gathering feedback through interviews and surveys for additional details. Surveys will be tailored to the size of the test group, with small groups asked short-answer questions, and large groups asked questions that are answered on a 5-point Likert scale (to make reviewing of this data easier.) The results of this evaluation will inform whether iteration or a re-design is needed.
When a design is found to be acceptable, I will move on to implementation. Here I will present the design to the relevant team members, taking care to understand who I will be presenting it to, and tailoring the presentation accordingly. I try to make these presentations as inclusive as possible so everyone feels welcome to ask questions. From here I will follow-up with those in charge of implementation and be available for any clarification questions, and support them accordingly. Most of the time, an implemented design will loop back to at least one more round of evaluation, and often design iteration, before sign-off. Upon sign-off and integration into a release build/update, I will follow how this design is received by the players. I am always prepared to re-design or re-evaluate it, as needed.
A Practical Balance
How deep into this process I go will be dependent on the size and scope of the design at hand, time constraints around delivery, and the impact it has on players. Development is, after all, about careful compromises, and I always weigh every decision I make accordingly. Also, just because a design is implemented and signed-off, doesn't mean the work ends there. There are always improvements to be made, and advancements in player expectation and technology. I will continue to follow up with the design and gather audience reception from a variety of sources. I'm perpetually prepared to revisit a design as needed. After all, it is my job to provide the best user experience possible.