My role:
Worked with:
Overview:
In 2015 I took over the design of a tool focused on helping users install Lumberyard, a AAA game-engine. Another designer did the first round of design, and these designs were live in QT (the programming language the engine was written in). This tool was a separate app that game developers downloaded and installed when they were ready to install the engine and it walked them through that process. Lumberyard was a branch of Cry Engine, which had a super complex, heavy-handed install process, so this tool aimed to simplify that installation process for customers.
Process:
When I joined this team, the tool was already designed by another UX designer, was in preview for our internal game studios, and was set to launch with the engine in a little over 2 months. So I decided to start by applying visual styling to it so it looked more professional when it launched. I assumed that it was going to work well, since another designer had been working on it.
Once the styling was updated, I created a usability test plan, and I moderated a usability study that included 8 participants. I discovered a number of issues with the tool’s workflow, instructions, and organization. The team was concerned they wouldn’t be able to integrate all my feedback before Lumberyard launched, but I thought it was critical that this first experience that customer’s had with our tool was a positive one, so I escalated to ensure that we were able to make the most important updates to the Setup Assistant prior to launching.
Some of the key findings in the study included confusion among participants for why they were logging into Amazon instead of Lumberyard, and about half of the participants mentioned that they were concerned about the privacy of their Amazon account information. Another important finding was that participants found the folder structure after unzipping Lumberyard to be strange, and they didn’t trust .bat files, but expected to see an .exe to launch the Setup Assistant. Participants also mentioned being confused about what was optional and what was required. And most importantly, they were confused by the SDK installation instructions, which were often wrong. The last finding was the most critical one to resolve before launching. It required our technical writers to spend a lot of time ensuring the correct SDK instructions were present at launch. Long-term, we worked to eliminate the need to install all the SDKs manually, as this was an extremely onerous process.
I updated the flows and the visual design patterns used, and then I worked with our technical writers to normalize the instructions within the tool, based on all these findings. Then I ran another round of usability testing, which performed significantly better. We were able to resolve all the issues discovered during the first study.
Outcome:
The Setup Assistant was included with the first public release of Lumberyard. Once it launched, customers were frustrated with the size of the engine that was downloaded at the end of the process. Once all selections were made, it was installing a set of files that equaled 60+ GB. Customers were unhappy with the size of the engine and how long it would take them to go through this entire setup process. Even though we had significantly simplified the process as compared to the installation of Cry Engine, customers wanted it to be even simpler, like Unity was.
The team worked tirelessly to include a lot of the SDKs in online libraries and to remove unneeded add-ons. I also encouraged the team to allow customers to install ancillary items, as they needed them, rather than in bulk up front. Many improvements were made to the experience over the next year, and the download experience ultimately got down to under 10 GB.
At the same time, I hosted some collaborative brainstorming exercises with the team to completely redesign this product before I switched teams within the Lumberyard org. I provided them with a clickable prototype of these designs, but major changes had to be made to the back-end systems before they could be implemented. (The changes that needed to be made were multi-year changes. You can see the long-term vision in the second prototype included below.)
Prototypes:
