2012 - 2013 / A startup dreams of bringing mobile fun to the masses
Mobile games
Threadbare was an Agile startup in San Francisco. The studio wanted to create a line of tablet games, focusing on the turn-based strategy genre.
As with most startups, they had very limited funding. The goal, therefore, was to produce MVP versions of games as quickly as possible in order to find a winner and start generating revenue.
The process
We generally followed the approach shown in the corner, but the process was considerably shortened compared to non-Agile environments.
For the first couple of weeks, the development team learned iOS, while I studied research on what makes games fun. I produced several lists of game elements that we could build into our designs.
After that initial period, the work was a series of sprints. The first would involve the dev team starting on the core code while I laid out the basic UI.
I was brought on as a UX consultant. My main job was to ensure that the games we created were fun, playable, and something on which people wanted to spend money. However, I also ensured that they were usable and learnable.
My role
I was brought on as a UX consultant. My main job was to ensure that the games we created were fun, playable, and something on which people wanted to spend money. However, I also ensured that they were usable and learnable.
...and the results
One game released. It got favorable reviews but was not a commercial success.
One game that made it to mid-stage development, but which had to be put on hold because of technical challenges.
One game that made it to early-stage development, but which was canceled by the company shutting down.
The activities
Page flows (Google Docs*)
Storyboards (Google Docs)
Wireframes (Google Docs)
Mockups (Google Docs and Axure)
Prototypes (Axure)
Game tutorials
Usability testing (remote)
User stories
Design principles
* Google Docs was the main creation tool, because it provides good collaboration capabilities at no cost. Axure was used for prototypes.
Very limited resources meant development considerations tended to have higher priority than UX ones.
This issue was difficult to overcome, and we were unable to fully address it. We made good use of Skype and Google Docs for sharing and collaboration, but it was clear that my full-time presence with the rest of the team would have increased the efficiency and efficacy of our work. The main lesson here is that co-location is best for Agile work, but there are ways to do it with a distributed team.
Challenges, strategies, and lessons
I worked remotely from Norway with an Agile development team in San Francisco.
This is an issue in many Agile environments. It worked out well enough in this case because, despite the distance, I had good communication with the dev team. I understood the constraints that they were under, and they understood the need to prioritize essential UX issues. Communication is the lesson.