Watching Strangers Touch Your Stuff

Making consumer products is hard. Making games is even harder. Quite a few people play games and have so much fun that they can imagine making games is some kind of super easy dream job. It’s not. Today I am going to talk about one of the things I learned to help me craft more enjoyable products, whether they are games or just applications.

I want to talk about watching strangers touching my stuff.

Half of the fun I have at work is finding irreverent ways to describe things, and this is certainly no exception.

I will start by taking us on a trip back in time to 2001 when I started making early mobile games for feature phones. Making phone games in this era was a wonderful experience. You had some of the user constraints of early computing platforms from the 1980s and early 1990s, with all of the tools of convenience of modern-day software development tools.

During this era I had the pleasure  of meeting many of the early game industry pioneers who crafted game experiences that helped propel me into a career in games. Developing experiences with input and output constraints is one of the experiences I really came to enjoy during this era. It was also one of the places where I learned a great deal about the craftsmanship needed to create top-selling software.

It goes without saying that I was having a lot of fun quickly making multiple end-to-end games. Some of the development cycles were only weeks long. Some of them were months. Starting a game project and quickly shipping the end product was a nice feeling. It was also a great opportunity to learn how to make things better.

I had my own little studio in the middle of nowhere when I was building my games. I would frequently talk to people in coffee shops and at conferences about what I do. I was The Invisible Man of the games industry. “You made which games?” people would ask me as well as “Where can I buy them?” I was eighty percent product developer and twenty percent salesperson and trainer. I was curious about the consumer side of the business I was working in. I would shamelessly ask people in meetings or on commuter trains what game they were playing. There was a nonzero number of people who were playing a game I was somehow responsible for putting into their hands. Some of my games came preinstalled on phones, and others were even featured on the front box of the handset. I checked off quite a few of my bucket list items for professional game development in the span of half a dozen years.

There were also some awkward moments. Early on, people had no idea how to play games on their phones. I was often in the process of trying to have an excited conversation with a complete stranger about making games, and I would put a test phone into their hands to give them something to try. Half of this was me looking for some sort of validation, the other half of this was me doing some super cheap focus-group work on products I was building.

I learned something very interesting doing this. People would subconsciously recognize that I was looking for some sort of positive feedback from them, and then figure out the fastest way to provide that. When confronted with a feature phone game, there was generally a lack of a clear path to a “oh this is cool” reply from the moment I thrust the device into their hands. So the vast majority of people naturally did the same thing—they did absolutely nothing.

It was disappointing and sometimes awkward when it happened. I realized that it was a pattern of behavior and that there had to be something I could do about it. I began to experiment with the initial user experience and learned some very important things that are more design related than engineering related. I am going to go over them here because it is valuable to have some of these guidelines if you find yourself building software for other people, especially if it is consumer software.

Jiggle the gems

One of the first problems that early mobile phone games possessed is the introduction screens. Many games just sat there with a small assembly of words and maybe if you were fortunate there were some images.

While “Start the game” was presently the selected menu option, hardly anyone could figure that out the first time they were experiencing this, even if it was outlined in an ugly, green, two-pixel box. Early casual games suffered from a variant of this phenomenon too.

The best way to get people to do something within a digital experience is to intermittently give them a nudge towards action. I think that Bejeweled was one of the first games where I witnessed this. If you were frozen long enough on a screen, it would subtly jiggle the gems to let you know that you had a valid move you can make. I did a variant of this in many of the mobile games I worked on, including having the start of the game being a wobbling “PLAY NOW” banner that generally gave enough reinforcement to the average complete stranger that it broke through the freeze reaction.

Get them inside quickly

Any of you UIUX types out there are probably snickering by now. I am somewhat going through “Product Experience Design 101”. Your guffaws are merited. I started doing this early enough with small enough teams that we ended up lacking formal designers. We had to make up a lot of this stuff as we went along.

While the first game I ever shipped met the modest goals I put in front of it, it failed to really thrive as a product. I think one of the cardinal sins I had there was that I put in a massive 10 page intro story without a skip option.

While “Portals of Arnak” was planned out as this first game in a three game series that told an interesting story, the subsequent sequel was massively scoped down and the ultimate conclusion was never developed or released due to a lack of sufficient demand.

The more buttons you have to push before you get to do something fun, the more likely you will lose a player. The industry term for this is “friction”. My first product had excessive friction. Some of my best-selling games were ones where you had as few clicks as possible between “start the game” and actually, you know, starting the game.

It is important to get people started on doing things fast. If you do not engage with them very quickly, they are likely to wander off and start thinking about something else or, even worse, start doing something else.

Play though the tutorial

I attended a GDC presentation one time where the developer started off talking about how you start playing World of Warcraft and you essentially have one button to hit at level 1, and your first job is to Kill Six Wolves. You jump into the action and start mastering the verbs and nouns of your play experience in this new space very quickly.

He then put up a picture of the UI for an endgame raider, with all of its tricked out add-ons and rows upon rows of buttons, juxtaposed against the cockpit of a commercial aircraft.

Players are so subtly ramped up into sophisticated endgame players that you do not realize that the tutorial for World of Warcraft is wedded into the game itself. You learn to do simple things quickly and your mastery of new skills is curated and broken down into bite-sized chunks of mechanics that are layered in on the leveling path.

This is counter to some of the frustrating social games tutorials. Many of them create a tour guide of the experience that is largely driven by an arrow that shows you where to click for each thing you are supposed to learn. The “follow the arrow” tutorial generally goes on to do this several times, increasing your speed at clicking on the desired button without necessarily increasing your knowledge of the reasoning or the outcome.

Eventually you get really good at “follow the arrow” and really good at clicking on stuff quickly. Generally the “follow the arrow” game disappears completely at this point and you are left in a foreign game with minimal retention of all the stuff crammed into the tutorial. This is a suboptimal outcome for a consumer. I had to evaluate ten to twenty games like this each week for part of my job once. Doing this many “follow the arrow” tutorials was an inescapable circle of hell I would not wish on anyone.

These are some good rules that apply to all types of application software development: Games, consumer applications, and tools. Maybe they now teach that to the kids these days. I hope that they do. I had to figure these guidelines out on my own and you might notice that these principles are at work in some of your favorite software applications.

This is coming up because I run into these issues on a daily basis at work. I am also working on some web-based applications for consumers and prosumers as a weekend hobby. It stands to reason that other people might have some of the same problems, and should consider some of the same guidelines and approaches.

If you are building software for other people like I do regularly, I encourage you to give it to strangers and to watch to see how they touch it. If you learn anything interesting I would love to hear you talk about what you learn!

Thanks again for reading along. The bucket of unwritten articles continues to empty at a steady pace. I will do my very best to refill the bucket with verbal chum so you continue swimming along with me.

I also want to thank those of you who do reach out to me directly for deeper dives into these topics for your own education or benefit. It does happen and I do love the dialog immensely. For the rest of you, I hope you can reciprocate the time you spend absorbing this vast assemblage of vowels and consonants with a like, or a share, or a retweet.

Heck, I will even take one or more emojis in the comments if that is all you have time for!