WVS Flows – A platform for game creators

WVS is a cloud platform for interactive creators and metaverse builders to manage, build and collaborate on projects. 

Overview

The Problem

Game creation and building is a time-consuming and tedious process. Most interactive teams consist of many different team members who upload assets and iterate on multiple files at once. And due to the binary nature of art and 3D files, this process makes it hard to collaborate on a project without using anywhere from 3-10 different tools to complete a project. This creates a couple of issues:

1. It takes a lot of work to track where all files are and what state they are currently in. Some files may be in a repo, some in Dropbox, and others in Google Drive.
2. Your repo doesn’t build the game. Another tool would be needed to compile the game, which would hold a whole computer hostage for hours to complete the process.
3. Games also need to be deployed on all different platforms, such as Mac, PC, your phone, and Oculus, to name a few. This manual process could be timing consuming.

Is it easier to do all of this on one platform? We thought so. 

My Process

Users and Audience

WVS has four key target users. Artists who would be uploading 3D models, textures, and sounds into the repo, Technical Artists who bring those assets into the game engine, developers who code the game, and producers who keep the project on task and budget.

What do they all have in common?

They all need a way to build the game and a way to view it.

Introducing Flows

In come flows, WVS’ unit of automation. They’re used to compile builds and deploy your games—simple scripts to automate the complicated tasks of building and deploying a game using your game files in the WVS Repo.

Discover The Usage

In the early phases of discovering more about how interactive teams use builds and deploys in their workflow, I utilized discovery interviews via zoom to gain insight into their needs and pain points.

I learned the following:

1. Everyone wants to see their work as a build for different reasons.
2. It’s essential to know the state of the game via build. Is it working? Are levels running okay?
3. What content was added? Who contributed to the changes?
4. How can I easily view or download the build?

Mapping Out Features

Automation, in general, is a complex subject to tackle. Add on the interactive/gaming layer, and the complexity doubles. So my first line of defense to wrap my mind around flows was to take my research and map it into a user flow. It provided me with a solid starting point for the navigation and functionality needed.

Working with the CEO, Co-Founder, and CTO, I mapped out what our first iteration of flows could be—starting with our outputs viewer. My goal was to make it functional yet straightforward for all our personas. Included in the wireframe was the build or deploy, who contributed to that build, comments and a way to download the build.

The concept was successful based on a round of 5 user tests. Only a few minor changes to what we would display to the user would need to be made. We also found that the table format and filters worked great for our needs and gave the product the ultimate flexibility for multiple types of users.

Creating A System

In the early stage of design and development, it was essential to have the beginnings of a design system that could still be very flexible and easy to change. I used the Flow Outputs as a start and created only the necessities of what we would need to succeed early on. Some of our main components that would be used across the platform were themes, a table, atoms such as buttons and form elements, navigation patterns, and cards, to name a few.

Hey everyone! Let’s manage our Flows!

With a few components in hand, I was then able to create the management portion of the Flow feature. This feature would be critical to our users as it would allow non-technical team members the ability to set up extremely complex automation independent of a developer.

The components significantly sped up the process of designing, but the most crucial step for this portion of the flows would be user testing.

How Our Users Used Flows

To evaluate the new Flow patterns on the WVS web app, we relied on five usability tests for viewing Flow Outputs and six for Flow Management. This allowed us to gain a deeper understanding through qualitative data since we didn’t yet have much quantitative data to rely on. Although users could view their builds quite easily, they needed help with Flow Management, particularly with Flow Setup. 

Discussions with our users revealed the following fundamental changes: 

1. The language used in the UI needed to be explicit and conversational. Words that they were used to seeing in their daily work. This was a great outcome because the team had been debating the language used, and our users ultimately had the final say.
2. Creating a flow seemed like something other than a process as it stood with pages. The solution was to develop a stepped approach to guide the user through the process instead of having them funnel through pages.
3. With many settings to choose from, placeholder text would be crucial to give the user some cues as to what to add.
   

My Key Learnings & Final Designs

Overall, the Flows feature was a success. With the launch of this automation system, we increased our user base by 80%. My key takeaways were:

• Continue to find ways to guide the user through using Flows. Some solutions for the short term are placeholders and info icons on each section, but long term, the use of guided documentation would be particularly helpful, especially for the less technical and especially as more features are added.
• Break up the information so that a complicated task doesn’t seem so daunting.
• Meeting with our users often and early was key to decision-making throughout this process. Their feedback was the most valuable asset to the process.
• Iterate on the product and always keep striving for simplicity.