If Minecraft was like digital Legos, 3Scape would be like digital erector sets.

3Scape and its Goals


3Scape is an open-world desktop app for building 3D models and landscapes created by Kevin Curry.

Kevin’s vision was part 3D modeling app, part PC game. Its closest comparitor would be Minecraft but instead of survival mode and Endermen, the challenge would be in the act of creation and working against realistic physical constraints like gravity to build anything you can imagine.

The core user group would be 8-14 years old, but like other games, it would probably appeal to some adults too.

The most immediate goal was to get 3Scape ready to sell to users.Based on feedback about the initial design, Kevin wanted to completely revamp the game’s UI.

The challenge of designing the new UI

Kevin wanted to strike a balance between a complex 3D modeling UI (like Autodesk’s Fusion 360) and a super simplified interface like Fantastic Contraption.

3Scape should combine the control of Autodesk Fusion 360 and the simplicity of Fantastic Contraption.

He wanted kids to be able to use the app with minimal instruction, but he did think a quick walk-through would be helpful for first time users.

My Roll

In February of 2015 I joined 3Scape as the UX Designer. Though I contributed to designs involving the user’s profile page and landing pages, my main task was to re-design the UI for 3Scape’s creative space – the space in which you would actually build and interact with 3D objects.

Some of my contributions included

  • researching the needs of kids and teens who might be 3Scape users
  • designing and helping to build versions of the creative space UI
  • forcing feature constraints
  • designing and building 3D physics demos and a 3D mini-game using XML, CSS, and Javascript inside the 3Scape framework

So many of these were big and exciting challenges for me. I had a blast making the 3D mini-game. It taught me a lot about Javascript, physics engines, game design, working within tight constraints, and I even learned to use Blender because of it.

But I think the most important contribution I made to the project was the least sexy: forcing feature constraints. You’ll see why in a bit.

The Team

The design team included myself and visual designer Michael Lucas.

I would research user needs, then define structure, interactions, and organization of elements within the app’s main creative space. To communicate these ideas, I made sketches, wireframes, storyboards, and interactive HTML prototypes. Michale would then take those designs and make them aesthetically coherent.

There wasn’t a strict division of labor though, and we often worked together on ideas. He’s a gamer, so I could pick his brain not only about graphic design but about game interface standards. And we worked together on ideas for the custom button icons that are used in the app.

Everyone at 3Scape worked remotely – from home, co-working spaces, and coffee shops.

We used

  • Google Hangouts for weekly stand-up meetings
  • Slack for constant short-form communication
  • GitHub to push code, track tasks, and log bug reports
  • Google Drive to share and collaborate on documents
  • email for longer written communication

Guerrilla UX Research

Before I was hired, Kevin asked usability expert Alex Proaps to do a testing session with 3Scape – but it would only be done after we had a design up and running. I didn’t have a budget or time allowance to interview or observe any potential users myself, and was asked to move forward with designing as quickly as possible.

I knew next to nothing about gaming, Minecraft, or game design before starting at 3Scape. I couldn’t draw a line without first doing some research, even if I had to do it in a less direct way.

Self Reporting

Fortunately, gaming can be a social activity even when the game itself isn’t multi-player. Gamers talk about their experience in forums, in blog posts, and they even post videos of themselves playing games on YouTube.

Even though I couldn’t talk to gamers in person, I could get a sense of their biggest joys and grievances through these forum threads, blog posts, and videos. The videos turned out to be especially good for understanding how PC gamers use an in game interface and their own hardware to play a game.

Published Studies

I needed to balance out this self reporting with something a little more objective.

So, I read reports about how kids and teens use the internet. This article by Nielsen Norman Group was particularly helpful.

There’s this myth that kids just know how to use technology. But according to the NNg study above, that’s not true. Kids are more confidant when using technology, but they also get frustrated and quit more quickly than adults. It’s dangerous to assume kids can figure out any design we throw at them because we think they’re “tech savvy”. With this study to point to, I was able to nip those dangerous assumptions in the bud.

Proxies for Users

Luckily, some of the interns on the project were PC gaming college students. Not exactly our demographic, but closer to it than I am.

I talked with them about their experience playing with 3Scape and other games. I even ran an impromptu task analysis session with them when we needed to see if a major feature idea was working (it wasn’t – more on that later).

That process was absolutely invaluable for seeing that some versions of the UI wouldn’t work while others might.

The Initial UI

3Scape already had a UI when I came on board, but it needed an overhaul.

Screen Shot 2015-02-10 at 1.32.39 PM
3Scape’s UI when I came on board

A cursory overview of this interface revealed problems like hidden features, less than ideal organization and grouping of features, and unclear labels.

But taking a step back, the biggest problem was that there was too much on the screen. In fact, every interaction happened by clicking an non-diegetic element on the screen.

Context Menu Fail

Through my research I learned that on-screen buttons and menus took gamers out of the flow of the game. I wanted to let users work more directly with the the 3D objects in 3Scape and remove the layer of buttons and menus between the user and the 3Scape world.

The first attempt at this approach was a context menu of tools that would be activated by right clicking the object you wanted to change. I thought users would have to click to select the object in question anyway, and activating a radial menu around that object would mean they didn’t have to move their mouse as far to get to the controls they needed.

An early sketch I did of the context menu controls – it’s getting out of hand quickly.

As I sketched, I realized this was going to be difficult at best. I didn’t have a concrete list of user editable properties for objects, and as requests for new controls came in, the context menu got more and more crowded. I tried thinking of ways to take some controls out of this menu, but other than space limitations I didn’t have a good reason to include some features here and have others elsewhere.

Once we had a version of the context menu working, I was able to set up one-on-one task analysis sessions with a couple of the coding interns over Google Hangouts.

One thing became clear very quickly: they didn’t even know the context menu was there.

I knew we would need to point out the context menu in a guided tour, but these guys had been involved in conversations about the context menu. If looking for right-click options wasn’t on their radar, I worried it wouldn’t be an interaction our users would expect – or even remember once they were told about it.

That coupled with its inherent space limitations and the fact that we were still just giving users buttons on the screen meant we needed to try something else.

One Document to Rule Them All

Remember when I said the least exciting contribution I made to 3Scape was probably the most important? That unsexy contribution was a single boring document that I compiled before I started working on the new, post context menu design.

Up to this point I didn’t have a complete list of user editable properties for objects in 3Scape. The software behind the scenes had hundreds of properties that could be changed or applied. The physics engine we were using added more options, and we could also add custom-built options. Kevin was rightfully reluctant to rule any of these options out because we didn’t know what users would really want.

On the other hand, we also didn’t know that they would want any of these hundreds of options. Even if it was arbitrary, we needed to narrow down the list of what would be in this interface for version 1.0.

So I asked Kevin for a full list of features the behind-the-scenes software was capable of (it’s a long list!). From that, I compiled a much shorter list of features that seemed remotely relevant. Then Kevin and I went through my list, marking each item as either must have, nice to have, or don’t need.

With my newly groomed list in hand I started organizing features into groups that made sense.

The document that helped me understand 3Scape better

This list helped me see there were entire groups of features I didn’t need to worry about.

More importantly, it helped me see how we could organize features in the UI. Until making this list, I thought the control for an object’s color had to be grouped with things like position and rotation. But organizing this list made me see they didn’t necessarily belong together.

Soon after, I made a similar document that grouped and defined animation behaviors a user could apply to objects.

Looking back, I wish I had pushed for this kind of clarity a lot sooner.

The Current State of the UI

The Current 3Scape UI
The Current 3Scape UI

I learned from my guerrilla UX research that users didn’t need an on-screen button for each and every manipulation. In fact, those kinds of controls were probably going to get in the way. Keyboard, mouse, and trackpad gesture controls would work, and even be expected for something calling itself a game.

I hypothesized that since this was a building environment, spacial properties of objects would be changed more often than properties like surface color or opacity so they needed to be easy to change. Luckily, they were also the properties most suited to be changed with keyboard, mouse, and gesture controls.

I took a gamble and decided all spacial properties would be changed by directly manipulating that object. I chose gestures and keys for those manipulations that I thought would be intuitive for users based on my research.

Click/tap on the object to select it, then use your scroll wheel or a pinch/spread gesture on your track pad to make it shrink and grow. Use your arrow keys to change the position of an object, and use a modifier key with the arrows to rotate it. WASD keys – a set of keys most PC gamers would recognize – move the user through the space.

For non-spacial interactions that didn’t have a well established or intuitive shortcut, I chose to use non-diegetic elements at the bottom of the screen.

A color picker is both the icon for itself and the interface to change colors at the bottom of the screen. It’s right next to the opacity control, which is the other surface property adjustment.

The rest of the circles along the bottom are button/dial combinations for object animations. The selected object is animated by pressing the button, and the animation’s speed is adjusted by rotating the inner circle like a rotary phone dial or a jog dial on a stereo. For example, if you select a sphere then press the cow button, the sphere will “roam” around kind of like a cow would in a pasture. Turning the dial on the button would make the sphere roam faster or slower.

Using dials instead of sliders saved screen space, and better definitions of the animations meant we didn’t make their controls too complex.

Usability Results

With this design in place, Kevin enlisted usability expert Alex Proaps to do some testing with a few users ranging from 8 to 38 years old.

This is my favorite line of the report:

Overall, 3Scape is consistent, easy to use, not too complex, well-integrated.

But, that’s not to say there weren’t problems.

The main suggestion was that we needed documentation for using the app.

Fortunately, we already knew this would be necessary. I built an interactive prototype for a guided tour (see it in the video above) but we scrapped it because it was designed for the failed context menu based UI. I suggested we hold off on making a new guided tour until we knew we had a design that could work. I also wanted to see if the usability testing had any insights for what should be highlighted in a guided tour of the app.

Aside from that, there were two notable design issues in the usability report.

  1. I was asked to make the menu bars open and close on hover. Testing showed that kids had difficulty with these menus. I hypothesized that giving the users a way to explicitly open or close the menus would be preferable, and eventually I’d like to test that hypotheses.
  2. Kids didn’t recognize the inner circle was a knob for a dial. That may be a flaw in the presentation of the knob. I would want to test different visual designs with users to see if any were more obvious.

These aren’t the only problems with the app, but even with these problems, I’m happy with the strides forward we’ve made from a UI that was confusing, complex, and frustrating, to one that us “easy to use” and “not too complex”.

3D Physics Demonstrations and Mini-Game Design

The most recent projects I’ve worked on for 3Scape were the design and implementation of two physics demonstrations and a mini-game. I mention them here not as examples of great UX, but as demonstrations of how much I learned on the job while working for 3Scape.

I used XML to set up the scenes, Javascript to trigger interactions, and CSS to make stuff look good. I used Blender to make the 3D jewel model that’s used in the mini-game. Each physics lesson took roughly a week to complete. The mini-game took about two weeks.

I had never worked with XML prior to this, and my Javascript skills were “light” at best. I hadn’t even used Blender before. But I love learning, and working with code is weirdly gratifying, so I actually had a blast making these things.

Lessons Learned

There’s no substitute for really talking to people, and really trying ideas. If I could do again, I would have made better and more regular use of the interns working on the project. I might have asked permission to talk with each of them weekly. If that worked, I might have been able to push for a small budget or time allowance to get some actual face time with users.

There’s also no substitute for having a process and sticking to it. I should have pushed for a more constraints sooner and insisted on a more defined process.

On a happy note, I’ve learned that I can work remotely with few if any issues as long as I have a stable internet connection. I’ve learned more than I can describe about coding, design, games, and I’ve even learned new software because of this project. And I’ve learned that game design is really fun. I would absolutely jump at the opportunity to work on another game.