Trevor Waldorf

The Builder

A 3D web editor for Decentraland


Overview

Summary

The Builder is a 3D what-you-see-is-what-you-get web editor for building environments (“scenes”) in Decentraland’s virtual world, Genesis City. It’s digital LEGO. The user selects a plot size, adds terrain and items, and uploads the scene to the world of Decentraland.

Objective

All platforms are subject to a chicken-and-egg problem before launching. The world of Decentraland was empty, but in order to attract users, it needed content, and in order to attract content, it needed users. To overcome this in part, Decentraland would allow any user to create content for the world before launch using a what-you-see-is-what-you-get (WYSIWYG) editor and then fill the world with this content before launch.

Users

We focused on solving the casual and artist persona use cases in the first version of the Builder. I developed our understanding of these personas through continuous user interviews throughout my time at Decentraland, and when we started with the Builder, we had a backlog of knowledge to draw on to inform our UX decisions.

Players are the core Decentraland audience who would, after launch, occupy the world. Artists are skilled community members who are drawn to Decentraland because of its potential as a creator-friendly 3d platform and community.


Process

Initial research

I played with every 3D editor product I could get my hands on, from the Sims to Unity and web-based tools, noting interaction paradigms and getting a sense of the state of the art.

Product Requirements Document

The PRD is where the majority of my initial work took place. This document detailed the user journey, the product capability, and the interaction paradigm. The bulk of the user experience was established here by me and passed to the designer for detailed UX and UI production. The design and engineering team added their opinion and then the sum of that work was folded back into the PRD and signed after review by stakeholders.

The PRD also plugs into a larger product roadmap, so while I had strong opinions about the Builder UX, I had to balance my opinions with the organization-level goals and downstream projects that the Builder would feed into.

Build, Test, Iterate, Repeat

Once the first build was usable I ran five tests in person with our target personas then edited the recorded footage into a highlight reel to show the team. From those sessions, we made deep dives into the interaction design, talking to experts across the organization. I worked with Mat, Decentraland's brilliant UX/UI designer, to define the next iteration and then ran a round of user tests after implementation using a popular user testing tool. This iteration loop repeated several times.

QA

I ran QA in three phases. First, through extensive user testing during the first UX iterations. Second, I sent core community members through an exhaustive array of test cases and surfaced bugs through google surveys. Third, we ran an open beta and used Hotjar and manual A/B testing (paired with analytics) to surface and solve small UX problems and microservice snags. These phases allowed us to catch and triage most (but not all) bugs before launch.

One of the great joys of product work is running a lot of users through your product for the first time and seeing some workflows explode but getting glowing feedback from users regardless. The Decentraland community is extremely loving when new products are released and The Builder was no exception—people would even approach me at conferences to mention how much fun they had building.

Launch

The launch had a big snag: serving web apps behind the firewall in China is not like serving web apps in the rest of the world, and our CDN was not able to serve assets in a reasonable amount of time. Engineering battled that until realizing it was something of a lost cause without meeting the legal and filing requirements set by the Ministry of Industry and Information, which would be a longer process.

Despite this, the launch was a success, and not only did the product launch on time, we also surpassed our key results significantly.

Following the launch, we shifted to live ops mode and began negotiating the roadmap for the coming quarters.


UX cases

Drag-along-plane

In the first iteration, gizmos controlled all object movement. During user tests, every user would try to click and drag on an object to move it, so I defined and prioritized this as “drag-along-plane behavior”, allowing users to click and drag while locking an object to the XZ plane.

When implemented and tested, this dragging behavior was tremendously intuitive to new users and allowed all personas to create scenes in a shorter amount of time, increasing user productivity (which feeds directly into a quantitative KR). Drag-along-plane is a great example of how UX directly impacts business goals.

Gizmos, orbits, and handles

Gizmos were the defining feature and core debate of the Builder. Gizmos are the little handles that users drag to move an item along an axis.

The least experienced users (players) need easy access to a small set of simple features—drag and drop to create new items, drag to move those items around, publish what you’ve made. More experienced users (artists) need quick access to powerful features in the same interface—precision position adjustments on all three axis, rotation along three axis, instant item search, etc. The balance between these features constructs the learning curve and controls the content of the Decentraland world.

After significant discussion, we opted to make the simplest and most limited tools intuitive, using only the mouse and sidebar, while making the most complex and powerful tools discoverable through labeled icons and hotkey hints. Adding these complex tools allowed users to create scenes with amazing creativity, far beyond what we had intended, and is what ultimately made the product a smashing success for the world of Decentraland and the community.

Item taxonomies and discoverability

I took a deep dive into taxonomy and folksonomy construction in order to provide users with an intuitive catalogue browsing experience. Users can search for specific items or browse through the catalogue. LEGO was my reference point for this, and I think the Builder handles this better than most editor products because we made the contents and the taxonomy simultaneously.

So what makes a good taxonomy?

The first category should be the first thing a user needs, and the last category should contain only finishing touches and rarely-used things. In the Builder, the first category is Ground, because the first thing every scene needs is terrain, and the last category is esoteric special event decorations.

For a user, a node in a taxonomy tree acts as a filter: show me only the things in this branch. Branches should be balanced in both breadth and depth so as to provide equally-granular filters for any number of node traversals. No one wants to click four categories down only to see a single Barrel object, but be presented with a hundred Tree objects after clicking into a Nature category.

In the end, nothing beats testing with users. Card sorting and task running are an easy way to tell if your taxonomy is good or bad.

Conclusion

The Builder was a successful product for users and for the business. It’s fun to use and it sits directly upstream from the Decentraland client. Users can build and publish an idea in a massive, social virtual world, from their brain to the metaverse, in under an hour—that’s pretty cool.

I spent a lot of time working in 3d editors as a kid and I think that authoring environments of any kind are high-leverage products, so I’d like to work on more in the future. Check out the pattern system designer project to see another authoring environment design case.