Last week, we had our tool be able to make adventure games with simple navigation puzzles (like opening the doors with keys, password, and switches). We wanted to find out if our progressive puzzle modules work in the digital form. Thus, we planned a playtest on Friday to figure that out. Before the playtest, we would like to enhance the usability of the tool first so that the frustration during the playtest would be caused by the progressive puzzle module design itself, not the usability of the tool.

The Sprint

After halves, we had a discussion in the team to figure out what is the best way for the team to develop a project. Though the project is a design-heavy project, we have several programmers but no designers. We all believe that instead of having a design approved before development, developing the tool and iterating according to our daily use is a better way for our team. Thus, we changed our production mode to be more sprint-focused.

Focus

In this sprint, we were focusing on making a usable tool to create games with collecting, using and navigation. After the sprint, we would like to use the tool to find out whether the progressive puzzle design works in the digital form. More specifically, we would like to find out if the options in the progressive puzzle module meet the users’ expectation and they can select the right option with little confusion. Also, we would like to observe the user patterns when they are creating the game: what operation they would like to do in the tool but we cannot?

Assessment

To iterate on the tool, we were building our tool daily and using the latest build to create simple adventure games snippets. When using the tool, we made notes about the frustrating parts of the game creation process. Every morning, before the core hour, we had a quick meeting to view all the frustrations and prioritize them. Also, we planned a playtest inside ETC on Friday to see if naive users can use our tool.

The Playtest

In the playtest, we had 9 playtesters in total with multiple disciplines. During the playtest, we let the playtesters play the target game first to have an overview of the game they would build (let them have a game in mind). After that, we let the playtesters have the game and our tool opened side by side so that they can create the game and reference back if they need.

All of the playtesters managed to create the target game in around 30 minutes.

There are several things they love:

• The ability to build the puzzles step by step
• The feeling of dragging puzzles around
• The ability to experiment with the puzzles by previewing the game

Of course, there are something they feel frustrated:

• Playtesters need time to understand how puzzle making works
  • Usually, they use the first two rooms (puzzles) to experiment with the options and adjust their assumption
  • Once they figured out how it works, they can build the rest of the game fairly quickly
  • Some of the playtesters would like to see all the options before they choose anything
• There are some usability issues when building the game
  • Delete, undo features
  • Adding object descriptions
  • …

All of the feedback is definitely useful and we will keep on iterating our tool. In the end, here is the screen capture of one of the playtesters.