Unity engine - UI/UX case study & redesign
This is an analysis of the game engine Unity. I work a lot with different game engines and Unity is the one I work with the most. I wanted to go over the engine and analyze part of the engine’s usability from both the workflow and interface point of view.
Below I present my thought processes and conclusions: What worked well and what can be improved?
I’ve described how those improvements can be done and implemented and I’m supporting those proposals with design mockups and explanations on how I would approach testing these changes with users to secure their validity.
For this assessment I timeboxed myself and set a time limit of 6 hours.
What Unity does well & who are we making these improvements for?
Unity is one of the most well known engines available for game creators. It is free and can be used by anyone with a computer powerful enough to run it.
Unity is very flexible and allows users to customize almost any part of the editor through custom scripts. The Editors windows can also be moved and resized to create a custom layout for the user. Unity has robust documentation that is continuously updated and the engine has a large community of developers that create guides, answer questions and help improve the engine.
This means that there is a wide range of users with different levels of experience in game development. Unity is also an engine that caters to a wide range of disciplines, and there does not need to be an overlap in disciplines for a user to work in Unity.
This width of users is one of Unity’s strengths and is vital to take it into account when designing solutions for the user experience. the experience should not be impaired for one type of user when it is improved for another.
Understanding different levels of experience & their pain points
New users tend to need the most help. New users can find the engine overwhelming to navigate. There is a lack of feedback and signs to the users input, and it is not always apparent to the new user if what they are doing is a valid action or not. Documentation is not approachable, and doesn’t always relate to what the user is currently working on.
Experienced users know the ins and outs of the engine and don’t face the same problems as new users. They want improvements to their workflow, and to cut out any steps that cause friction in their process.
The Hierarchy panel, Scene View and Project Browser have to be used by anyone who wants to use Unity effectively. Below I’ve outlined potential improvements to these areas of the engine's experience.
Improvements to Unity
Hover states & tooltips
Hover states are when the user hovers the cursor over an element in the various interfaces or the scene. If a user is hovering over a specific element we can help them gather more understanding about this object. By incorporating tooltips in these hover states, new users can find information about the hovered object and how they can interact with it, while experienced users can find information about objects in Unity that they might not work with often.
Tooltips are a flexible solution that can be context specific depending on what object is hovered. Hovering in the Hierarchy panel can let users know that double clicking the object will center it in the Scene view, and vise versa. In the examples below I decided to focus on showing the potential functionalities that the player can do with the object they are hovering over.
With the flexibility of tooltips, documentation could be incorporated here as well, creating discoverability of the documentation for that specific object. If a user is hovering over a Sprite Object for example, the tooltip can be context specific to allow users to open detailed documentation regarding Sprite Objects. For new users this lets them know that documentation for Sprite Objects exist. For experienced users this allows them to quickly look up the specific documentation they need.
Examples of tooltips, linking the panels together and allowing for context specific information.
Customization of the Hierarchy panel
The Hierarchy panel can get very bloated on larger projects so allowing users to personalize their Hierarchy can allow for greater ease of navigation and a reduced cognitive load. Below are some examples of how the Hierarchy panel can be improved in terms of customization.
Hierarchy details
Hierarchy details is a potential feature that allows users to add additional information and functions to the Hierarchy panel. The mockup below is not an exhaustive list of what could exist within this feature, but it is scalable and allows users to pick and choose between different details and functions they want to display.
Object type sorting
In the below mockup I’ve added a hierarchy detail called “Object Type” to the hierarchy panel. Object Types are descriptors added to the individual objects in the hierarchy. Users can then also sort the hierarchy similarly to the “Pickability” and “Visibility” top tab buttons.
Color coding - The problem
Color coding allows users to put colors on the objects in the hierarchy, which is a great feature for visibility on large projects. This is doable using scripts, but requires the user to click on each individual object and change the color through the inspector. It’s also not friendly toward new users and people without scripting knowledge.
In this picture I’ve created a custom script that allows me to customize the hierarchy panel. Here I’ve added color to three objects in the hierarchy. This can become very time consuming to add to every object in the scene of larger projects.
Color coding - The solution
By using the same drop down menu of “Hierarchy Details”, users can easily add this feature to their hierarchy and change colors. By centralizing these features under one menu, it also helps with the discoverability of this feature. I experimented with an icon here but this could also be text like the “object type” feature above.
Filtering
Filters should be applicable to all elements in a specific Unity window. New users can reduce the cognitive load that is presented to them, while experienced users working on large projects can filter out what they deem unimportant and speed up their workflows.
Improving the filters in the Project Browser
A basic filter functionality exists within the project browser through the search function. To improve it I would remove the dependency of the search function, as the filters are strings typed into the search bar. This functionality is good for experienced users, but should be optional for new users who might not know all the search terms.
I would also allow several filters to be active at once, as users do not always only look for one type of object.
Custom Filters
A certain set of filters does not work for everyone. Game projects can differ greatly simply by how a team is working or by what type of game they are making. Adding custom filters can help developers create a workflow that works for them, and these can then be shared to others within the project. Users can opt in or out of certain filters depending on their preference, as well as add useful information about them.
The “hierarchy details” feature, here highlighting the “object type” feature.
Custom script enabling objects in the hierarchy to have colors.
Hierarchy color picker mockup and flow.
These changes make the filters easier to use and find. Users can filter independently of the search function, and can then search inside of the filters they have set up.
User testing & research
After finding the pain points and designing potential solutions to these problems I would perform research tests to check their validity. Tests should be done at every stage of the feature process, but different methods should be used depending on the state of the feature.
Testing early & often
If it is early in the process, flow tests can be done on paper designs with mockups and wireframes. That together with discussions with users, issues can be found quickly and be iterated upon and the issues can be found before heavy investments in the feature have been made.
Having testers work out the flow on a white board or using printed out paper designs can quickly help establish a baseline understanding for what works and what doesn’t. The data and feedback acquired through these tests are not to finalize a design, but to help the team working on the experience make informed decisions when working on high fidelity wireframes, or technical prototypes.
With the quick and iterative process the team can use the findings as a foundation for a prototype. Early testing will not only help the validity of the experience, but also help the team working on it get a greater understanding of what they are making, and who they are making it for.
When a prototype has been made we can perform more intricate tests. Using tools like eye trackers, we can collect raw data on how users navigate the feature. The same testers can then be asked directed questions about the feature. For these more intricate tests it should be the aim to triangulate the data found. By incorporating several methods of testing for a specific experience we can more easily assure the validity of the experience.
Reflections
Looking at the Unity engine which already does so much for so many different developers and trying to improve it was both a fun and challenging task. With Unity having a well established and functional interface, it was hard to find these pain points that could be improved.
Looking back I realize that I should have taken more risks with my approach and not have stuck too much to the “one size fits all” way of thinking. I feel that it limits the creative type of problem solving that can create great solutions. It’s fine if certain features are made for the power users, as long as it doesn’t impact the overall experience of the engine.