My role:
Worked with:
Overview:
Lumberyard (a desktop application) lacked a centralized asset browsing experience. There was a file browser for opening scenes, a separate browser for pulling in materials, yet another for particles, etc. Users wanted one central place to find their assets and apply them to different entities in their scenes. This Asset Browser case study was part of a 2-year project to improve the entire asset pipeline, which I owned. Here, I focus on one large piece of the pipeline, the Asset Browser.
Process:
I started with customer interviews to understand the use cases that were relevant to our different personas (artists & game designers). Once I understood these use cases, I began sketching with members of the team. I took these sketches and turned them into a clickable prototype using Axure and did a first round of concept testing. This round of testing focused on whether we should utilize the editor’s property pane to display asset properties or create a new property pane for assets inside of the asset browser. The study led us to utilize the main editor’s property’s pane.
Once we determined this important step, I began working on high-fidelity mockups. I put together another clickable prototype, this time in Framer so I could test drag and drop interactions. We were looking to see how well people understood the relationship between source and processed assets, as well as general usability. We discovered some potential confusion with a couple of users surrounding the relationship between source and processed assets, so I continued to iterate on the designs, and then proceeded with a third round testing.
We ultimately landed on a direction that customers understood, despite the great deal of complexity involved with the way assets are processed inside of Lumberyard.
Outcome:
The development team was actively implementing pieces of these mockups when I left the team. We were surveying our internal game teams monthly, and had an NPS score of 73 for the entire Asset Pipeline. NPS had begun at 27, as the original experience we inherited from Cry Engine, involved editing an XML file to import assets into their project.
We had positive feedback in usability testing with this audience, so I expect that number improved after I moved on. At this point, we had already implemented 4 different ways to import assets, and provided multiple ways for customers to access asset advanced settings. These changes reduced the number of clicks/interactions from greater than 10 to 1 for importing assets. Users no longer had to use individual editors for importing assets, modifying materials, editing textures, browsing for files, etc. so this reduced time on task to edit assets from 10+ minutes to less than 1 minute through sane defaults, easy importing, and one central asset browsing experience.
Prototypes:
