Doom and doom II
Trailer
Responsibilities
-
Provided UI/UX menu design for Doom and Doom II multi-platform re-releases and subsequent DLC
-
Authored and maintained a collective Game Design Document
-
Assisted production with pipeline design and agile implementation
Development info
Role: Designer / UI/UX Designer
Team Size: 10
Genre: FPS
Engine: Proprietary / Unity
Release Date: July 26, 2019
My Role as a designer
Serving as the Designer for the Doom and Doom II releases involved juggling a few responsibilities and wearing multiple hats.
-
Designing in-game and out-of-game menu flow and interface features from initial pitch to client approved Feature Flow Charts and Mockups
-
Working in conjunction with Engineers on game feel, accessibility features, and UI/UX implementation
-
Creating and maintaining a updated Game Design Document and all associated documentation
-
Working with Production to improve our development pipeline especially in regards to Quality Assurance
-
Creating Product Backlog, Epics, and User-Stories for Feature Updates based on Client and Internal Stakeholder Requirements
development sTORIES
UI/UX design for Update 3
For our 3rd Update, our team released a wide variety of quality of life improvements, and the much desired Add-ons feature for all platforms. My task as the Designer was to fully design the interface and functionality of the Add-on feature, in addition to providing the designs and documentation for many of the quality of life features we shipped with, including Level Select, and QuickSave/QuickLoad Feature.
Here you can see the Available Add-ons menu from the XBOX perspective.
Here we have the Installed Add-ons menu from the PS4 perspective. Note the differences in controller iconography.
Here you can see what changes when a Add-on is activated. An toast icon indicating an Add-on is active, along with a menu graphic relevant to the Add-on itself.
Here you can see the Available Add-ons menu from the XBOX perspective.
My primary goals for the Add-On feature for Doom and Doom II, were to ensure that we:
-
Achieve core feature parity with many of the more popular WAD-Loaders available on the market
-
Ensure that the Add-On feature-set was accessible to players with less modding experience
-
Provide a modular design that could be made to work on multiple platforms, including mobile interfaces.
Examples of the Add-on menu in game
By baking these design pillars into our Release Planning, we were able to plan for and implement some of the most popular features of the release:
-
Custom Sounds and Music
-
The Background Graphic for the Main Menu when an Add-On was activated
-
Formatting for Pulling Level Names out of the Add-On for our Level Select Feature
-
Ensured Custom Add-Ons based on the core games could be read and parsed by the game with Add-On formatting for the PC version
-
Streamlined Add-On Menus with only two major tabs
-
The same primary user flow and feature set in Console, PC, and Mobile offerings.
-
Quick Weapon Select
With the Level Select and QuickSave/QuickLoad features, my intent was to ensure the fewest clicks possible, the most available features, and cohesion with our other menus.
For Level Select, I achieved these goals by combining our chapter and difficulty menus into a single menu with slider choices, allowing for Players to select: Chapter, Level, and Difficulty before jumping straight into the game.
Here you can see the 3 selection windows for Chapter, Map and Difficulty.
For Console versions of the game, we needed to show the buttons needs for QuickSave and QuickLoad, in addition to Save Info.
For PC we used a more minimal Quicksave scheme, opting for the more classical F5 and F9 controls Doom fans were used to.
Here you can see the 3 selection windows for Chapter, Map and Difficulty.
For the QuickSave/QuickLoad feature, I ensured that a single button press in the pause menu would rapidly save or load the previous Quicksave, while showing the current Quicksave on file. Additionally, I expanded our Save and Load menus to include a QuickSave Slot, and added color coding to indicate whether that Save was from an Add-On or the Base Game. Additionally, I included an information button to give specific information about a save, including when the Save was made, whether an Add-On was Loaded, and what Difficulty Setting was applied.
For ease of use, I designed a separate interface for Console and Mobile Offerings that benefited the use of a controller with Button Hints, or Touch Buttons on mobile, while going for a more minimal interface for the PC offering, operated through the more traditional F5 and F9.
Examples of Level Select, and QuickSave/Quickload
All in all, as a Designer my goal was to ensure that we put together a solid offering for the Doom community, that not only addressed many of the community's concerns, but exceeded their expectations.
I feel that we were successful in this regard.
Digital Foundry Review of Update 3
feature and Interface Design Process
As the only Designer for the Release, it was often the case that I would come to wear many hats during different phases of the release cycle. As the team was in the tail end of development of the previous Update, I would begin the initial development phase of the next release, starting first with collecting stakeholder requirements and developing quick whiteboard pitches.
Here you can see how the Add-ons Menu was initially developed, by taking into account the requirements of stakeholders and producing an initial interface and feature set.
After initial stakeholder feedback, I would then focus on the interface. Here you can see the Content Cards, Menu Tabs, and Contextual Button Bar coming into being. (With a cameo of Level Select).
Here you can see how the Add-ons Menu was initially developed, by taking into account the requirements of stakeholders and producing an initial interface and feature set.
Examples of Whiteboard Pitches
My team and I preferred a visual medium to discuss feature sets, so I would sketch quick whiteboard pitches of feature functionality and interfaces to get buy-in from the team and our stakeholders before devoting real resources to the feature. This process saved a lot of time by narrowing down my later mockups and getting the team on the same page early on, in addition to providing me with high level feedback to improve the ideas.
Once the general design concept was approved, I moved onto digital mockups of the interface and documented the feature set with design notes, including a functionality flow-chart. When greenlit, I broke each feature-set into User-Stories with Conditions of Satisfaction for our Product Backlog, and partnered with the Programming Team throughout each sprint as each feature was implemented.
Here you can see the initial interface mockup of the Add-on menu with design and feature descriptions, as it appeared in our documentation.
Once a feature-set, interface, and user flow had been greenlit by stakeholders, I would then develop a functionality flow-chart for our team to use as reference as we began to implement features.
While mockups of new menus required a great deal more fidelity to sell the idea, for menus that used our established conventions, wireframe models would suffice.
Here you can see the initial interface mockup of the Add-on menu with design and feature descriptions, as it appeared in our documentation.
Examples of Mockups and Functionality Flowcharts
Here is an example of a quick visualization I did of different selection highlight schemes to settle some stakeholder feedback that our Content Card selection was too difficult to notice. [Tap or Click the Picture for a bigger version!]
After presenting the visualization, I preferred the yellow highlights, as it conveyed the selection states the best across all devices, especially mobile devices.
Here is the Save Menu in the actual game.
Here is an example of a quick visualization I did of different selection highlight schemes to settle some stakeholder feedback that our Content Card selection was too difficult to notice. [Tap or Click the Picture for a bigger version!]
During full production phase, my role transitioned into a Vision-Keeper, providing guidance and adjustments to design, while coordinating with our internal stakeholders and QA Team to ensure each feature was tested, and available for stakeholder feedback.
Often when collecting feedback, I would develop mockups visualizing directions we could go to answer hard questions that would arise during the implementation process.
Feature Mockups and their Final Incarnation in the Release
By taking initiative and being flexible to the needs of the project in wearing many hats, I was able to add significant value to our Update releases and develop a cadence with my developers that raised our quality bar as we continued to update Doom and Doom II.
Doom and Doom II Initial Release and Design
When I was brought into Nerve as a Designer, our development team was already deep into production of the initial Doom and Doom II release. As the first Designer to work on the project, my first role on the team was to assess the UI/UX of the game and identify where we could get as much bang for our buck in improvements before release.
My approach involved applying what I call the "Big 3"as a good baseline to judge what changes took priority when improving the UI in the time we had provided, while staying in keeping with the original game's look and feel:
-
Readability
-
Do I understand what this menu or feature does?
-
-
Accessibility
-
Do we account for different players in our design (Color-blindness, Text-Size and Font, etc.)
-
-
Cohesion
-
Do all menus look like they were made for the same game in the same style? (Spacing, Coloration, Header-Placement, Menu-Conventions etc.)
-
I then coordinated with my production team to begin documenting my feedback, and began working on a common design language for our UI. As I continued to work with the team, I began to greatly expand and edit our internal documentation into a more accessible and organized GDD, developing a change-log with page links so that everyone on the team could keep up with the changes during the end of the production cycle.
Flow Menus borrowed from the design of the original game in being composed of stacked text buttons. My add was a anchored larger header and highlight skulls to indicate selection and activation.
End-plates were where mlow menus ended up if they didn't lead to the main game. This convention allowed for a visual difference between menus that led somewhere (flow-menus) and menus that contained features (end-plate menus).
A good example of a small add with a lot of value: I designed a black opacity layer in front of the game demo and menu background graphics to aid in menu text readability.
Flow Menus borrowed from the design of the original game in being composed of stacked text buttons. My add was a anchored larger header and highlight skulls to indicate selection and activation.
My greatest contributions during this period were:
-
Establishing cohesion in our menu flow (All flow menus lead either to the game itself, or a "end-plate" menu with features.
-
Establishing menu-design conventions as concerns headers, font-sizes, spacing, and mobile touch conventions
-
Ensuring that all interactive buttons had highlight and activation feedback
-
Working in partnership with my production team to improve our QA Testing process
Examples of my Initial Adds during the first release
By focusing on priorities and developing better communication pipelines with the team, I was able to add significant value to our development processes, and improve the final product. This relationship I developed with the team would go on to shape our process for each additional update, helping to raise our quality bar and spend more time on polish and quality of life features.
Lessons Learned
-
Acting as a player advocate in product design can greatly enhance product quality.
-
Taking ownership of improving processes can spur others to do the same.
-
Tailor your documentation towards the needs of the team. If it's usable, they will use it.
-
Clear and candid communication with stakeholders can solve problems before they start.
-
Always shoot for a more elegant solution when designing interfaces. What needs to be there?