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