← Trevor Waldorf

UX cases from The Builder

The Builder had customers across teams within the Decentraland organization. As product manager, my role was to use data to advocate for the needs of the user and to apply my product intuition about 3D editors to ship a best-in-class editor experience that was responsive to the organization's business and platform needs while still being a delightful and capable creative experience that encouraged users to accomplish platform content production goals.

Personas

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 in addition to refocusing user interview efforts on Artists. Our understanding developed as follows:

Players

Players are the core Decentraland audience who would, after launch, occupy the world. We understood Decentraland to compete within a player’s entertainment time, not work or social reproduction time. Players skew younger than other personas age at 16-30 and are from all regions of the world, including China. Players are most likely to engage on mobile, are not onramped into crypto, and are socially active on Discord and social media. Most of the players who interact with the Builder would do so by exploring the world of Decentraland instead of creating and publishing scenes.

Artists

Artists are skilled community members who are drawn to Decentraland because of its potential as a creator-friendly 3d platform and community. We understood artists to be open to using Decentraland to accomplish professional aims: finding new, lucrative mediums for their art and finding productive tools to express ideas about what the virtual world should look like. Artists had previously been shut out of the Decentraland ecosystem because the SDK required basic game engine development skills. The Builder resolved pent-up demand and unlocked a large portion of the talent in the Decentraland community, allowing artists to contribute directly and permissionlessly. Artists have experience with some 3D tooling, such as Blender, SketchUp, AutoCAD, Maya, 3DSMax, or Unity/Unreal.

The Builder is expressly designed for Artists but should be legible to Players. Players should understand that the Builder is not the main play interface even while engaging with the builder is entertaining and may meet their play goals for 1-10 minutes.

Cases

Much of the challenge of the Builder was feature discoverability. The least experienced users (players) need easy access to a small set of simple features. More experienced users (artists) need quick access to powerful features in the same interface. Us learning about this interplay led to most of the UX movement from my first wireframe to post-launch iteration.

1. Drag-along-plane

In the first iteration of The Builder, 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.

2. 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.

3. 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.

Distribution of placed items by 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: ask a batch of users to find a series of items and note where they travel the wrong branch and must doubleback. In the Builder this led to only a few small patches – moving trees and other nature items out of decoration and into their own category.

4. Scene Resource Limits and notifications

Resources are limited in shared environments. For Decentraland, this means that each scene had strict triangle, texture, and entity limits. Texture limits were rarely present due to fantastic atlasing work by Art (thank you Shibu you beautiful genius).

As a user, I want to know when I have gone over the limit. Instead of being blocked from adding objects over the limit, I want to be notified so that I can negotiate in real time with the limits and my creative vision.

In user tests, when users hit scene limits, they took their time to finish their current arrangement task then re-evaluate items they had placed earlier for deletion, bringing them back under the scene limits. It was also important that this limitation be signaled early in the process instead of hidden until the user hit the limit because users would begin “spending” their triangle budget with reckless abandon before feeling defeated–their original vision was never even possible but they had no way of knowing.

To inform users early, we implemented a little info pane that shows the current resource budget and highlighted it at first object addition. Still, scene resource limits were a thorn in the side of new users and all were thankful when the resource limits were globally increased due to performance negotiation with the client engineering team. Sometimes big UX wins like this lay outside of your tile, which is why it pays to have good communication with other teams.

Summary

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. Tens of thousands of scenes have been created using the Builder, spanning extremely impressive static exploration and jumping puzzles to sculpture art to cute knolling. It was the highest traction product that we launched by user session time and I think it had more impact on the player world experience than any other product because of how it cleverly augments the LAND token product.

Authoring environments are one of the highest leverage product categories that designers can engage with, along with markets and communication clients, and I think The Builder is a strong supporting example to that case.

Wireframes

Although I am not able to share my original wireframes for the core of the Builder, because the zero-rent leasing feature is no longer part of the Builder I have included its artifacts here.

Zero-rent leasing was a feature to match LAND owners with creators and was superseded by the opt-in Scene Pool (another feature I ideated and led) for volume purposes.

← Home