It’s crucial to instrument software with telemetry so a developer or business can understand how their software is used and how it behaves in the wild. Telemetry enables software shops to glean business intelligence and service intelligence. An example of business intelligence is the average amount of time users spend on any particular page, or in what order do users navigate to various pages. An example of service intelligence is the average load time of a page or how often unhandled exceptions are thrown.

The easiest way to approach telemetry instrumentation is to identify all of the unique events that can occur in software. In Squared users can press buttons, navigate between pages, find solutions in the game and purchase game packs. So, I log when buttons are pressed, when users navigate to new pages, etc… It’s important that software shops identify the questions they want to answer. Knowing what questions need to be answered provides insight on which events need to be logged.

Fortunately plenty of software already exists to collect telemetry. I use Google Analytics for Squared. Below is screenshot of data that I collected from Squared beta users, which shows how users navigated from page-to-page.

I let about 15 friends and coworkers download Squared beta builds, it turned out to be an invaluable resource to find bugs, receive feedback and feature requests. A lot of the features that ended up in the game came from friends requests after playing the beta.

I also used the beta distribution as an opportunity to measure how easy my game was to play. Remember my goal was to create a novel game, which has an inherent learning curve. Although I have a Tutorial page I quickly learned that no one goes to the Tutorial page before they play a game. It was an unfortunate experience for the user because they were placed in a game that they didn’t know how to play. However, this helped me validate that investing in a ‘first app launch experience’ was necessary. During the app’s first launch the user is guided through a simple tutorial so they’re prepared to play the game without ever going to the Tutorial section.

I iterated on Squared many times with a handful of mediums. I wrote the original idea for Squared down on paper, I showed it to friends and I described what the user experience would be. As usual I found that it was hard to spur the excitement and imagination of others. The more you show and tell people the more feedback you’ll receive. Clearly, I needed to refine my descriptions and visual aids before prodding for too much feedback.

Next, I created a prototype of just the game. I created a Windows Phone 8 app that had one view that displayed a board made of 2D grid squares. These squares could be [un]selected by tapping them. When the user selected four squares that made up the corners of a larger square the selected squares disappeared, indicating a solution was found. Users didn’t have to match a pattern of any sort, I was shooting for the smallest investment to show off my idea to collect more feedback. The software prototype worked! I noticed that my friends were lead down the path I was trying to describe to them in the past.

Interactive prototypes help peoples’ imaginations flourish. As I iterated on my prototype my friends started to overflow with ideas and suggestions.

Once I felt confident that I had a playable game, I proceeded with more rigid software development practices. My goal changed from fleshing out a prototype to building a reliable and efficient piece of software. This transition isn’t so easy when all aspects of the app haven’t been designed or refined. I found that I polished all aspects of code that I thought were done churning. I left some areas in an ‘exploratory’ stage until I had conviction of what the polished design should look like. For instance, once I had the game completely designed I invested in building common controls, heavily documenting and optimizing everything I could. Meanwhile, I wasn’t sure how I wanted to display high scores, so I had a few source files and views that looked horrible as I iterated trying to lock the ‘right’ design.

I regularly reminded myself that I had to balance prototyping and sound engineering. Prototyping is good for getting quick feedback while rigid engineering is the investment to building a maintainable code base

I was inspired to create Squared after reading about Dots an Android and iOS game. It’s a beautifully designed puzzle that is simple and addictive. I like to think of it as a digital twist of Connect Four. Users need to connect contiguous circles of the same color. I was surprised that a rather simple game became so popular, however, it reminded me that good things flourish regardless of complexity.

Admittedly, I borrowed some of the aspects of their UI design. I’m okay with this because I evolved the design and tailored it for my app. Also, I created a completely different logic game. Lastly, copy-cat apps annoy me because they’re usually not as good as the original app.