Visual Merge Design

Design Manager and Senior Designer

Project Summary

While many games are created by individual developers, some studios devote large teams to developing a game. Team development for a game involves many roles that each have different skillsets and tools. The larger the studio, the larger the project, and the more complex the collaboration. This project was intended to solve one of the key issues encountered during team development of a game – how to deal with a conflict in a 3D asset.

This is an incredibly difficult problem to solve from a design perspective. Assets in Unity can have conflicts in an almost infinite number of ways. Resolving these conflicts is very time consuming for a team. Typically, a technical artist or engineer would need to open the raw YAML file for a 3D asset and diff it in the same way they would diff code. However, it’s very difficult to find a conflict in a visual artifact by only looking at the code that represents that artifact. The goal of this project was to develop a visual way for a creative to try to solve a diffing issue.

Process

Development of this feature began as an intern project. Many months of engineer work had already been invested into a prototype before it was decided to convert it from an intern project to a real feature in Unity. When I was first assigned to the project, I reached out to the PM to get an understanding of the project status, the users, and the problem space. I learned that the prototype was developed based on the assumption that creatives would want a visual way to solve a conflict in a visual asset. This assumption had yet to be verified with the intended audience.

Developing a prototype before discovering how creatives work collaboratively in real-world situations created some challenges for the project. I felt that we needed to interview users. To convince the project team to pause for a bit, I created a schematic of the double diamond process to illustrate how we had skipped both the discovery and the definition phase. We agreed to block out a month of time to do these interviews.

The first step before doing any customer interviews and validation was to make sure the team was aligned. I and the PM decided to set up a workshop with key team members and do a user empathy and story mapping exercise. The goal of this exercise was two fold. One was to bring more design thinking and processes to the team since most had never done a rigorous discover phase. The second goal was to bring out any assumptions people had so we could align as a team. It ended up being a great experience for both and helped build team collaboration.

Design Challenges

The existing diffing feature in the product was designed specifically to support code conflicts. Users would open the YAML file and manually edit it to resolve each issue. The prototype applied existing patterns for solving conflicts with code to the experience of solving visual conflicts, but these were two very different problems. We did not yet understand the needs of users who were creating and managing 3D objects. Established patterns for this type of visual comparison experience did not yet exist, because there were no competing products that handle merging changes in a 3D object.

To develop a better understanding of the problem space, we conducted external interviews with 18 users from various roles in the gaming industry, including artists, technical artists, engineers, and managers.

The first 20 minutes of each interview consisted of key questions around how they currently worked as a team.

• What techniques does your team use to work together efficiently?

• How does your team deal with conflicts on a game object?

• Does your team use source control? If so, which one, and how do you use it?

The second part of each interview consisted of walking the interviewee through two prototypes. The interviewees were asked to perform the same tasks for each prototype. We switched the order that the prototypes were shown for each test to avoid ordering bias.

One prototype was a full screen experience that we called “Visual First”. The Visual First prototype was based on the assumption that creatives would want to navigate differences visually and would want to solve them in a visual way. The second prototype was a more traditional diffing approach where we used side by side inspectors so that users could see the values that were in conflict. Both prototypes were based on many hours of sketching collaboratively with engineers and other team members. We wanted to respect the work that had already been done on the engineering prototype, so this collaboration was important.

As a result of these interviews, we discovered crucial information about how people collaborate on games and 3D objects. These discoveries directly affected the outcome of the project.

Outcomes

The visual merge project ended up being put on hold as a result of the design work, and more importantly, the user interviews. The conclusion was that we were trying to solve the wrong problem for our users.

The initial prototype was built with a goal of enabling users to deal with conflicts in visual assets after they arise. However, in the interviews, we discovered that users preferred a workflow that kept them from having conflicts in the first place. The interviewees gave surprising examples of how far their teams would go to avoid visual conflicts occurring in the first place, including:

• The Wait Your Turn method. Teams would use a spreadsheet to track and “check out” objects. If you needed to work on something, you had to wait until you could check it out.

• The Branch-Madness method. The engineers would create branching structures to separate the creative work. The engineers also had to merge branches and manage any differences.

• The Plushee method. They would use physical objects to determine who could work on an object. Whoever held the physical object owned the visual object.

• The Trash method. They were used to just throwing out one person’s work. If someone had done more work on an object they might “win” and get to keep their work.

The net outcome was both a lesson learned and an opportunity. As we move forward building out a DevOps suite, we know that we should plan for preventative measures such as soft locking and hard locking to help people collaborate better on 3D artifacts. We captured the process, learnings, and conclusions from this project in a retrospective deck that was presented to the whole design organization at Unity.

This project also led me to do "North Star” explorations around how creatives might want to collaborate in real time on Unity projects in the future.