Roles and Responsibilities
During this live project I was primarily a feature designer, but also worked on level design and design processes. Within those roles I was responsible for:
- Greyboxing and level design
- Budgeting and breaking down design workloads
- Communicating design needs to art teams and finding solutions which were compatible with Quantum
- Designing new obstacles and working with client code teams to actualize them
- Understanding the needs of other designers and creating best process and practices for the whole team
- Improving and refining level creation pipelines to reduce the turn arounds on creating new levels
- Maintaining communication between feature teams and tech art, audio, live ops, environment art, and level design teams. Within this, communicating and budgeting the needs of the feature team I was championing
- Feature design
- Creating, and templating for future use, high quality design documentation to be used by multiple disciplines
- Delivering a flagship feature and acting as team champion on this feature
- Level and feature testing
- On boarding the rest of Tag Games to the project
Level Design
I was one of the first six members of Tag Games to join the Stumble Guys project. Upon joining I was briefed on the feature I would work on in the future, but to learn the internals of the project I was initially placed into a level design role.
Within that role I was tasked with creating a mash up level which utilized existing content, and had very low art and client code demands. I took the design space on this level as an opportunity to learn as many of the requirements, restrictions, and processes on the project and document those for both the benefit of future team members, and to have a record of any project challenges which could be referred back to for addressing at a later date.
To create the mash up I looked at all existing levels, the obstacles and their set up, and held short one to one calls with the existing level design team to understand all of their personal processes.
Once I had gathered the information needed, I began ideating level combinations in a MIRO board. I created a range of pitches which targeted different play styles and player archetypes and took those to a discussion session with level leadership to green light the one I would take into development.
During development I worked in a series of passes on the level, each pass establishing further confidence and finesse in the final level. This allowed me to work quickly, fail fast and iterate, and turn out a level in the shortest time frame seen on the project at that point in time.
As I worked I accounted for possible routes, mastery paths, timing, predictability of obstacle behaviors, signaling, and threat density. Once each of these elements were balanced out appropriately in a first pass I held wide play tests to gather feedback through a MIRO board which stayed live until the level released.
Post launch I continued to use my experience from making this level to improve the overall level creation process, solidify ownership of workloads between disciplines, remove dependencies and unknowns from the process, and ensure all levels could be tracked in a repeatable future proofed format.
Process Improvements
When I joined the project it had a large focus on content delivery. This meant that tasks which would future proof the project were backlogged when unexpected set backs occurred. I made it a part of my process to document any work I did as a part of the task itself, and document work in a way that was duplicatable in confluence for other designers allowing them to create their own documentation with less time pressures.
The goals of the documentation were:
- Future proof mentally stored knowledge
- Highlight areas of improvement in process
- Create a record of project pain points which could be addressed by client code and server engineers
- Give project wide visibility on the level creation process at any stage of a level's development to anyone who required it
- Align the teams on process and practices
- Track content
- Support cross referencing efforts between our records and analytics data
- Create a better communication line between designers, artists, client coders, live ops, and audio teams
Where ever appropriate I pushed for documentation to provide an overview of its purpose, a point of contact for who owned the document, the functional and experiential goals of the document's outputs, user flows and use cases, and context to requests which provided a "why" to the "what".
Formatting documentation in this mindset meant that any discipline could readily understand the problems the document aimed to address instead of being prescribed a solution without context.
Similarly to my approach to levels, I worked in passes on the document templates and gathered feedback before making them live for use. This allowed me to capture all the requirements and improve formatting for readability and quick access to important information.
The documentation set up improved the visibility, alignment, and speed of teams who used it.
Feature Design
As a feature designer I worked on a flagship feature with a team of tech designers, product managers, client programmers, server engineers, and UI/UX teams. As well as a feature designer, I was the product owner and team champion responsible for the delivery and quality of the final feature. The feature was targeted at mobile, PC, Xbox, Playstation, and Switch.
Within my feature design responsibilities I had to design the user facing aspects of the feature, and define the user experience. Before I could begin this I had to create an experiential pitch for leadership to establish feature goals. Once these goals were approved I began designing.
To achieve the best design possible I performed, and documented, extensive research into competitor products and similar features on other platforms. After collating information on other approaches I began designing how our feature would achieve our goals.
I worked closely with tech design to create design solutions which were efficient, durable, future proofed, and modular for the future of the feature beyond its first release. This process was iterative and balanced in depth user flows against the technical possibilities of Quantum as it stands today, and how it will function in future releases.
Once the initial design documentation, diagrams, and matrixes were created they were reviewed by the team. Feedback was gather from product management and UI/UX to smooth out usability and accessibility even further.
Once the initial designs were approved, my responsibilities switched to assisting in the creation of a roadmap and defining an MVP. I was responsible for providing an MVP which would show that our design solutions were working toward our goals. After this I worked with the other team disciplines to create a backlog of work which would lead us toward that MVP within our deadlines.
After this point I began designing in more depth, the functionality that would be created after our MVP was completed. This functionality was designed in a way where it could easily pivot based upon the outcomes of testing and iterating on our MVP.
Once the secondary features were completed my role included negotiating deadlines and release specifics with leadership, working with centralized resources (tech art, audio, 3D art, and live ops) to budget the feature's needs from each disciplines, communicate the what, why, and use cases of each request made of the discipline, and planning when those teams had time available to support the feature.
During all stages of the feature's development I remained in communication with other design departments and client tech teams to ensure that our feature team had all of the information needed to remain unblocked, and that changes in other areas of the project would not have an impact upon our roadmap.
