Designing a VR Content Creation App
Groundwork for something huge
This is the full case study!
Skills demonstrated
UX Leadership
UX for VR
Affinity Mapping
Feasibility Evaluation
Priority Mapping
Competitive Analysis
Ideation Brainstorming
Mockup
Prototyping
Storyboarding
Intro
In late 2021, the execs decided that the company's new focus will be to build a modern standalone 3D modelling solution, entirely run on the VR headset as opposed to requiring tethering to a powerful computer like our current suite. As I write this in mid 2022, our current suite of creative apps works wonders, but it has its limitations and has been the source of various learning opportunities. Needless to say, I was quite excited for the possibilities a fresh start would open up for our users.
For a company in our position, it is simply impossible to fund a project like this without 3rd party stakeholders - big ambitions require big investments. With these investments, however, come expectations. Thankfully, in this case, it meant that they wanted us to ensure that some of the features we promised definitely made it in for our premiere launch. Problem solving is the bread and butter of this career, and I had to make sure that these features got a prominent enough spotlight in the design process without compromising on the usability for what our app had to be.
My first step was getting familiar with the requirements from our stakeholders, and keeping those in mind as I took on this hefty task of laying the design groundwork for our project. I had some time while the developers created the back-end required for a headset-only app.
Research: Personas
Being that this will ultimately be a 3D model creation and sharing platform, it had a huge overlap with our current suite. In that sense, we already had a lot of the research done. This time was different, however, as we hoped to reach a much wider audience.
With that in mind, we got together to create a few proto-personas based on our existing knowledge of users, some interviews our QA conducted, and secondary research metrics of creative/3D/VR/metaverse enthusiasts. We ended up with about 9 proto personas, each with some demographic, behavior and desires to keep in mind as we designed our product.
At this point we had a pretty clear idea of who we were designing our solution for - it wasn't just one convenient title, it was a group of content creators, artists, educators, students, developers, metaverse users. Ultimately, it was for a group of humans who were, or wanted to be, engaged with an immersive and productive creative experience. From here on out, I will call them "to-be users".
Research: Competitive analysis
I've always advocated for competitive analysis, and now was the perfect time to conduct one. There weren't that many VR, 3D content creation apps out there, but the competition isn't between what labels your product is defined by, but rather what problems it is solving.
At our core, we were allowing people to be creative and productive with 3D. In that sense, we had dozens of competitors. One of our team members had already compiled an absolutely huge list of such competitors. My team, which included myself as the primary UX designer and a mix of 3D artists, graphic designers and developers, got together and assigned a few of these apps to each person to look into.
Based on the list of requirements we had to fulfil for the app we'd be building, we evaluated each app's ability to accomplish certain tasks. This initiative resulted in a huge table of apps, and their strengths and weaknesses. This information would be used at various points in the future, including competitive analysis.
Believe it or not, there are 9 more rows and about 10 more columns I didn't show here.
Research: Organizing ideas
The research we had done so far, as well as the information we had from our existing app, meant we had a huge pool of knowledge. Now we had to make it useful. This is where a prioritization matrix comes in. We have plenty of ideas and research, but knowing what to prioritize is key. A prioritization matrix allows us to organize our ideas by what is most beneficial versus how much effort it takes.
We filled out a lot of virtual sticky notes with every idea or point that came up during our research, including what our current users had been asking for in our current product. I put all of these stickies into buckets based on where it was asking for new features, takes on existing features, preferences, compatibilities with other workflows etc.
For a prioritization matrix, we need to know how useful a feature is. I got the design team together to conduct an impact evaluation of each. I guided them through what we had so far, and after getting familiar with the ideas, they voted on which ones seem the most useful based on our user personas and what users had told us from past user research.
To evaluate the feasibility of each idea, the developers were the most qualified to answer as they would be the ones implementing them. I guided them through a similar process, but this time they were voting on how feasible each idea was.
At this point, all the ideas had a rating for impact and feasibility. I organized them into the largest prioritization matrix I've made in my career so far.
At this point, we had a good sense of who our users were, a solid set of ideas that our users wanted, which ones to prioritize, and a list of requirements to fulfil for our stakeholders. We had everything we needed to start designing.
As an aside - there are many benefits to including so many teammates in this process. It lowers bias, diversifies voices, but also allows them to understand and engage with the user research that not all of them were necessarily aware of. The spread of this kind of information within a company is crucial to everyone being on the same page and working as a greater whole. This is immediately valuable in the next phase, which is our first designs.
Design: converge and diverge
Iterative design is a core tenet of any UX designer worth their salt. Every design must begin rough. But designing such an ambitious project alone is not only difficult, it is also shortsighted. Multiple minds means more ideas, less bias, and faster turnaround times. While I had done my fair share of low-fidelity designs, my teammates (who had recently become very familiar with our requirements and list of ideas) were also in a perfect position to create designs of their own.
For diverge/converge design, a team diverges and each member creates a solutions as they see fit. Then their ideas are converged into a cohesive whole. As such, I suggested everyone create extremely rudimentary low-fi designs - these should be a very basic (not even complete) vision of the app and incorporate ideas which stood out to them, prioritizing the most feasible and high-impact ones. Between myself and the 4 other minds doing this, we came up with lots of cool designs.
.png)
.png)
.png)
.png)
After a show-and-tell of our designs to each other, I combined them into an amalgamation of all the ideas as suitable to our research as possible:
This would be the first rudimentary storyboard of our main flows.
Design: low-fi prototype and testing
After a long research phase, it was finally time to dive into Figma and create an interactive prototype. While most of this was re-iterating the amalgamated low-fi's we had created as a team, it had to be understandable to external testers. Given how little time and resources we had to work with, for this project, we decided to outsource testing to a trusted third-party.
I created a prototype which, while being low-fi, went over the main flows that our users hoped to be able to accomplish in our app.
Each flow had a clear objective. I would not be conducting these tests, so I made sure that there was a followable guide for the users.
On top of this, I made a moderator's guide for the testing service to follow, which would ensure that all necessary questions were asked.
.png)
.png)
.png)
.png)
Conclusion
8 test participants evaluated the low-fi experience and we got lots of useful insights. We finally had something tangible to base our initial engineering off of, and this is where the story ends for now.
The theme of this case study is less about the specifics of what we did, and more about navigating the messy, realistic world of stakeholders, time constraints and knowledge organization. This project is still in development and a lot of it is under NDA. Regardless, I hoped that I was able to communicate the various problem solving strategies I could employ here. By leveraging existing knowledge, discovering new knowledge, guiding team members to help out with ideation and reducing bias, we were able to found a solid base for our upcoming solution.
A lot more has happened since that low-fi prototype. There was a whole web component that I did not get into, and lots of case-by-case instances of VR design. Some of the designs have taken drastic turns, while staying true to the research we had conducted, while others have persisted. This is the nature of iterative design in the real world. Here are some out-of-context images of some of these developments.
.png)
.png)
.png)
.png)