The summer has flown by, and we’re now only two weeks away from launching version 2 of the game. And, remarkably, nobody’s panicking! We’re very much on track for our launch date, and that’s due in large part to our learning from our mistakes.
This year, we took on the task of fully redesigning the technology, content, and interface of the game in a single summer–that’s nine weeks to encompass planning, development, and testing. Given that very small time frame, we spent what might have seemed to some people to have been an inordinate amount of time on planning before we ever wrote a line of code. As we come into the final stretch, that emphasis on front-loading the design and architecture (of both the back-end technology and the front-end user experience) is really paying off, as we watch pieces click nicely into place with no last-minute realizations that we missed something critical. So this post is devoted to the topic of what tools and processes we used for that design process, and how and why we used them.
We began the old-fashioned way, by locking all the key faculty and staff from last year’s game in a room for two days and doing an in-depth breakdown of what worked and what didn’t from a game design perspective. What pieces did we want to keep? What pieces were clearly broken, either technically or from a user standpoint? Were our core ideas of what we wanted the game to be still solid? Were our core mechanic for delivering that experience solid? During that retreat, we sketched out the basic structure of how the game could change this year, retaining our core goals and objectives but retooling the presentation and mechanics. Without those two days of intensive thought and planning, we wouldn’t have been able to move forward. That kind of deep-dive design work requires sustained attention, not a meeting here and another there squeezed between other obligations. This was not a high-tech process, either–we relied on whiteboards, notebooks, and piles of index cards (for card-sort exercises). The one technology tool that was valuable during that process was Evernote, since it allowed me to take photos of our white board diagrams and be able later to search for them based on the automatic text recognition.
Once we had a clear sense of direction, the next step was to write detailed functional specifications for the new system. Who were our users, what were our use cases, what content would we have, how would it be presented, and what functionality needed to be supported? This document was primarily my responsibility, because writing specs is not something that typically works well by committee. However, it was an iterative process that required regular input from other members of our team. I wrote the specs in Google Docs, granting read and comment permissions to the rest of the team, and encouraging them to add comment in areas where things were unclear. At the same time, our technical architect (Chris Egert) began creating a data model for the new site, taking into account both what I was drafting in the specs and the need to better record data for ongoing analytics.
As the specs took shape, I worked with Elouise Oyzon, our design lead, to mock up the pages of the site in wireframe form, focusing on functionality rather than aesthetics. We chose to use Mockingbird, an excellent web-based tool for creating application mockups, both because the tool itself worked well for our purposes and because as a cloud-based app it allowed for us to work collaboratively. We paid for the $20/month version, so that we could maintain separate wireframes for the public version of the site, the logged-in version of the site, and the administrative interface. All members of the development team had access to the wireframes, which helped enormously in clarifying the functionality in the specs. As we mocked up pages, I updated and clarified the functional spec to match what we’d determined. Eventually, the mockups became the definitive design document for the whole team, since the visual representation of the functionality was very effective for communicating requirements. Here’s an example from the administrative interface wireframes:
Once the mockups and the data model were largely complete, our dynamic developer duo of Chris Cascioli and Ben Snyder began work on the actual application engine, which was built using the .NET MVC framework. (We looked at a few other web application frameworks, including Django and CakePHP, but ended up going with .NET because our development team had strong C# coding skills.) Because that part of the project was outside of my expertise, I’ll leave it for our devs to talk about that side of the project. While they toiled in the code mines, though, Elouise and I went back to work on design issues.
To manage the many aspects of the content and visual design production process, we chose to use Trello, a free web-based project management tool made by Joel Spolsky’s company Fog Creek Development. Trello provides a flexible and very visual framework for representing tasks as “cards” that can be moved between lists. Here’s what our “front-end” Trello board looks like today, as we near the end of the process:
Trello is wonderful for tracking to-dos, and for maintaining an at-a-glance sense of what’s happening and needs to happen in a project, but I found when we tried to use it for organizing achievements and quests in the game that its limited search and sort capability made it less effective for large amounts of structured content than a spreadsheet or database. I finally ended up moving all of the achievements and quests into a single Excel spreadsheet, which I’ll eventually move into Google Docs.
Our final go-to tool for the design and production was Dropbox, which I have a love-hate relationship with. I love the ease of being able to share documents with a group, particularly for things where there’s little confusion about who can modify the documents–like the folders of icons we need for both print and online representation of achievements. The inability to restrict access in any way in Dropbox is consistently frustrating, however. Any person with access to the file can move or delete it, making it unavailable to other users. There’s no way to make a file “read only.” I’ve begun investigating Microsoft’s SkyDrive as an alternative, but the challenge is getting a large group of people to all be willing to shift their tools and workflow, and that wasn’t a challenge I wanted to take on with this project.
While this particular project was a game, the process and tools I’ve described are applicable to any complex web-based application (and probably non-web-based applications, although I’ve got less experience in that domain). I get asked often enough what’s involved in building a complex website that it seemed worth outlining our workflow in details for others to learn from. If you know of other tools or resources that are helpful in collaborative design and production processes, I’d love to hear about them!