Perforce Helix Cloud

Skills Used: Adobe Illustrator, Sketch, InVision, design research, requirements gathering and synthesis, close collaboration with Product Management and Engineering, remote research and usability testing, agile process



When I joined Perforce, the company was in the process of refining a closed alpha version of a new web-based product, Helix Cloud, to prepare for a beta release. One of the biggest concerns was that the centralized version control software (VCS) made by Perforce was losing its spot in the market to GitHub, which made decentralized version control software (DVCS). As a research-focused UX Designer, I was tasked with understanding the workflows of developers, designers, and artists, and then translating my findings towards UX and UI designs.


Case Study 1: Reducing the Pain Points of Current Users

One of the first things I discovered through research was that in trying to compete with other products, Perforce had inadvertently forgotten about its own users! The alpha version of Helix Cloud did not allow existing Perforce users to import their depot into Helix Cloud—instead focusing on luring people over from GitHub and Dropbox.

Key Findings: In order to migrate to the cloud, Perforce customers were compressing their depot into a .zip file. However, this import method was not effective, since it didn’t preserve the version and file history of their depots—a crucial feature of a version control system. This experience made our current users skeptical of the value of Helix Cloud. 

Impact of Research: Based on my research, the team prioritized adding a way to import a current Perforce depot, and informed the users of necessary steps to ensure server compatibility.


Case Study 2: Prototyping and Testing Before Developing

Soon after I joined Perforce, the team was planning on developing a new feature that would allow users to switch between branches on the UI—again, to mimic the design of GitHub. However, based on research I had been conducting within the gaming industry—home to our most loyal clients—I had a hunch that this branch switching feature would not be very important to them at this point in time. I quickly created a UI design that allowed for switching branches, and tested it remotely with our clients.

Key Findings: Through user testing, I learned that indie gaming studios tended to develop on one branch, and only created new branches in special situations—for example, when they needed to put together a demo or when occasionally syncing the development branches of multiple offices. In larger gaming shops, only developers would be expected to switch between branches while artists might be given their own branch to work from.

Impact of Research: Based on my findings, the team decided to hold off on developing a branch-switching feature for the UI—saving the company thousands of dollars in precious development costs. We decided that when we did eventually develop this feature, it must be released alongside a more robust set of user permissions that would give only the appropriate roles within companies the ability to switch between branches. This would prevent our customers from inadvertently making disastrous changes through our UI.

Case Study 3: Conducting Exploratory Research to Drive Innovation Strategy

After successfully tackling smaller projects, I was trusted with independently planning and undertaking exploratory research that would inform the long-term strategic agenda of the company. One of the biggest questions that remained unanswered was: How do technology professionals want to store their work, communicate, and collaborate?

Goal of Research: Until this project, the company had been focused on understanding why software developers were switching to GitHub. However, our customers didn’t only employ software developers—their teams included designers, artists, animators, and more. I decided to conduct a study with non-users of Perforce in order to understand the following: How do people in less exclusively “technical” roles prefer to communicate and collaborate on deliverables with each other? What tools do they prefer? Why?

My Approach: First, I sent out a survey on SurveyMonkey to the network of technology professionals I knew in the SF Bay Area.

Picture of

I sampled purposively from the pool of respondents in order to recruit a variety of industry verticals and business sizes outside of the gaming industry, which already knew we had a strong hold in. After conducting 10 semi-structured interviews, I held open synthesis sessions in which anyone at the company could drop by to see what I was doing.

Important notes were organized using three levels of categorization.

Key Findings: Through my research, I uncovered that it wasn’t simply the rise of GitHub that Perforce should worry about. Professionals in less technical roles were flocking to other tools that facilitated a combination of storage, communication, and collaboration—most notably, Dropbox, Google Drive, and Slack.

Socializing My Research: In addition to the open synthesis sessions I held, I constructed a short document outlining the key findings of my research, written from the perspective of research informants. I circulated this document throughout the company, so developers and product managers could have this information as a quick reference on hand. Below is a sample from my findings document.

Sample findings about communication and relationships at work

Impact of Research: In a presentation to executive leadership, I argued that more attention needed to be paid to building tools for communication and collaboration, rather than simply storage and version control of files. It wasn’t enough to give people a robust engine to back up their work—the biggest opportunities were in successful integrations of storage and iterative, collaborative digital work. Ultimately, the company made the decision to make a united web interface for cloud storage and collaborative code review, for which I was responsible for designing.

Mock up of web interface