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

3Scape and its Goals

3Scape
3Scape

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. 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. He had done market research and determined that there was interest, but based on feedback about the initial design Kevin wanted to completely revamp the game’s UI.

We needed strike a balance between a complex 3D modeling UI (like Autodesk’s Fusion 360) and a super simplified interface like Fantastic Contraption. Kevin wanted to offer the control and options of the former, with the intuitive simplicity of the later.

The Team

The design team included myself and visual designer  Michael Lucas.

I would define structure, interactions, and organization of elements within the app’s main creative space with sketches, wireframes, and storyboards. Michale would then take those designs and make them aesthetically coherent.

We also 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, from the coding interns to the design team, was distributed. We worked 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

I loved working from home, but I needed to manage expectations properly. So I started checking in with Kevin each evening before I signed off of Slack. I’d let him know what I accomplished for the day, what I had planed for the next day, and if I was blocked in any way. It only took a few minutes, Kevin liked being kept in the loop, and I could make sure I was making the best use of my time.

My Roll

In February of 2015 I joined 3Scape as the UX Designer.

Some of my contributions included

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

So many of these were big and exciting challenges for me. I had a blast making that 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.

Guerrilla UX Research

My first challenge while working on 3Scape was getting to know our users. I knew next to nothing about gaming, Minecraft, or Game UI design before starting at 3Scape. But as a UX team of one with no budget, I wasn’t able to interview or conduct tests with real people. I had to study our potential users in a less direct way.

If you can’t watch your users IRL…

I couldn’t watch kids playing video games in real life, so I turned to the next best thing I could find: YouTube.

  • I watched footage of people playing Minecraft to see how people used our primary comparator, making note of pain points and features that seemed to work well.
  • I watched videos of NPCs (non-player characters) and in-game tutorials to see how to teach the game within the game.
  • I watched videos of kids playing with blocks to try to get a sense of their mental models about building.

While I wouldn’t substitute watching YouTube videos for real interaction with users if I had the choice, YouTube turned out to be a good resource for getting to know kids and gamers without actually talking to kids and gamers.

And if you can’t talk to them…

I couldn’t interview users. The next best thing I could find was reading what people have written in gaming forums and blogs about their own experiences with game interfaces.

I took this and the YouTube portion of my research with a huge grain of salt. Only a certain subset of people will actually rant on the internet about what frustrates them, or swoon over what delights them. Those people weren’t necessarily our users.

It was great to get this perspective but I needed to balance it out with something a little more objective.

So, I read reports about how kids and teens use the internet, like this article by Nielsen Norman Group. This one in particular proved helpful when team mates made the assumption that kids would be able to “just figure out” a design choice.

According to this study, kids aren’t better at figuring out technology than adults. 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”.

And if you can’t test ideas with them…

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 UI Design Process

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

We started with the assumption that none of the non-diegetic elements would remain as they were. Kevin wanted the same features, but they could be completely different from the implementations you see above.

In the beginning I worked on the UI feature by feature. Each feature started with a question from Kevin like “How will they turn physics on and off?” and I would start down the rabbit hole of trying to understand what “turn physics on and off” meant in this context, and how someone might accomplish that in an intuitive way.

Context Menu Fail

At some point, I think I suggested something like making cut, copy, and paste available in a context menu that could be activated by right-clicking on an object in the scene.

This got turned into an request to put all of the controls for an object in the context menu. Options to change color, size, rotation, and position of an object would all be in this menu. We hadn’t even figured out how to turn physics on and off yet, but when we did it was going in the context menu. It was like Frankenstein’s monster.

ContextMenu2
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 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 Kevin got a provisional version of the context menu working, I was able to set up one-on-one task analysis sessions with a couple of the 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 were actually working on the app and had even 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 some technical difficulties was all of the evidence I needed to ask Kevin to scrap the context menu and 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.

A little back story: 3Scape piggybacks on another piece of software and that software has a ton of options available. When Kevin thought a feature would be useful or interesting, he would ask a developer to port it from this other software to make it available in 3Scape. There were also custom built features, and features made possible by the physics engine.

Up to this point I hadn’t been given a complete list of features 3Scape 1.0 should have. There was always the possibility that more features would be added from this giant and mysterious set of possibilities. But because I didn’t know what would ultimately become part of 3Scape, I was starting to design in circles to add in new features as they were requested.

Working on the context menu had eaten up a lot of time, and before I started coming up with a new design I needed to know what was in, and what was out. So I asked Kevin for a full list of features the behind-the-scenes software was capable of. From that list, 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.

UserEditablePropertiesList
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 YouTube 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.

Instead of having buttons on the screen for moving the user through the space, I suggested we use the WASD keys – a set of keys most PC gamers would recognize.

Spacial properties of objects would be changed by directly manipulating that object. You would 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. And instead of buttons to change the position or rotation of the object, you would use arrow keys.

Thanks to my all mighty features list, I realized that the widget to change an object’s color didn’t belong with the controls for its spacial properties, so I didn’t feel compelled to make changing color something you do by manipulating the object directly. Instead, 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 other 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. Using dials instead of sliders saved a lot of space, and better definitions of how the animations would behave 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.

Most of the problems described in the report were about bugs we had already logged as GitHub issues. The main suggestion was that we needed documentation for using the app, and we already knew this would be necessary.

The video above shows an interactive prototype of the guided tour that I build for 3Scape. Unfortunately, we had to scrap it because it was designed for the failed context menu based UI. After that experience I suggested we hold off on making a 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.

There were two notable design issues in the usability report.

  1. Kevin asked that the menu bars open and close on hover, so I built the hover effect using CSS (read about that process here). Testing showed that kids had difficulty with these menus as they opened and closed too quickly. With this feedback, I was asked to build in a delay so that the menus stayed open for 20 seconds after hover ended.  I have a hunch that if we try to think for our users in this case, we’ll get it wrong more often than we get it right and it will make the menus more frustrating than helpful. We haven’t tested the new menu delays with users, but if we do I would like to test an explicit open/close function as well.
  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.

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.

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 had it to 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 and test ideas and prototypes with them before submitting the ideas to Kevin. 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 developing a process and sticking to it. I think some of the trouble we encountered stemmed from skipping steps in haste, and I was just as guilty of this as anyone else. It’s exciting to start sketching as soon as possible, preparatory documents exist for a reason. I should have started doing all of my boring documentation a lot sooner and I should have pushed for 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, and I would absolutely jump at the opportunity to work on another game.

3Scape | 3D Modeling Game