top of page

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. 

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. 

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.

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.

Examples of Mockups and Functionality Flowcharts

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.

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?

bottom of page