The scenario we chose was the Dungeons & Dragons session. Dungeons & Dragons relies heavily on the player’s story telling skills, imagination, and note taking skills. Thus, it is almost a purely informational game. The cultural probes and our informances inspired this scenario. The probes, as a whole, showed us that the Roll to Hit Club can be extremely focused yet very casual about their games. When engaged by a game they often forget other important elements such as our “Rule Changing” probe or their homework. When specifically looking at some of our more successful probes for inspiration we turned to the “Key Moments” probe. Players not only noted down their moves and the outcome but actually created somewhat of a basic narrative story out of it. Surprisingly this was common to almost all members of the group showing their wealth of creativity.
It was because of this creativity that we chose some of our more abstract informances and we realized how difficult facilitating the creative process can be after doing our white board informance. The probes and informances reinforced what we had observed and learned from our group; they try to include each other in activities whenever possible. Our prototype will therefore be an application that can be integrated into some of the club’s games in order to smooth out and streamline information consolidation and distribution.
Final Reflection and rationale throughout the project
After our first meeting with our group we realized they were highly creative and playful wanting to focus on having fun and escaping reality more than anything. This has always been the central focus for our team as we tried to improve the gaming experience for the Roll to Hit club.
The majority of our cultural probes were playful in nature and the playful ones were the most successful. We didn’t want to box ourselves in to one style of thinking so we explored other options in our scenarios and journey frameworks. We looked at the groups scheduling problems but felt that these needs could be met through other applications that are currently available today. Also we didn’t feel like that would be that excited about a scheduling app. We learned from our previous interaction with the group that in order for them to be helpful to us they needed to be 100% engaged. That is why we decided to key in on their most recent and current favourite game: Dark Heresy. Dark Heresy is very similar to Dungeons and Dragons. They are both role playing games facilitated by a Dungeon Master or Game Master. The two main inspirations for our decision to pursue a Dark Heresy app were 1: the group’s excitement when playing the game. 2: their inexperience with the game and how slow and inefficient parts of the game play was for them. We knew they would be excited and thus, more likely to participate. We also felt that they would more readily include us in the learning process since it was new to them as well.
Most of our data was gained through direct observation and interviews. Our first observation of a Dark Heresy session only solidified our decision. When in battle phases of the game the group had to flip back and forth between map pages and battle action pages. To keep their characters’ positions on the map they would tear up scrap pieces of paper and hold them in place with their hand while flipping the pages with another. This was quite comical to witness and was an obvious choice to try and improve.
We felt that technology could easily emulate a map and with simple drag and drop code we could mock up player position as well. It was brought to our attention that the group may not want technology to interfere with the gaming process. After a quick interview over the phone with a few of the members they said that wouldn’t be a problem for them. The only reason why they don’t all bring laptops is because the table is too small. This bit of information although subtle was incredibly important to us. The form factor we chose would have to be small such that all of them could use it in the limited table space. We had several ideas. We thought about a smart phone app that could simply hold textual information the GM would send out. Another idea was to have a central app on a tablet that could be shared among the club members. As a team we felt the latter was more appropriate because we wanted to foster the community of the club and felt that sharing something was better than having them all face down in their phones. We began to think more about the battle phase and came up with a list of problems they were having:
The battle actions list is large and complicated – impossible to memorize for new players.
Item stats and equipment is also hard to memorize.
Turn order is often forgotten and needs to be re-stated multiple times.
The map is difficult to use in the book due to page flipping.
Player positions on the map are hard to keep track of.
Custom maps are hand drawn.
When maps are hand drawn they are done quickly and often poorly.
When the map grid is very small, player position is even harder to keep track of.
Information is not always accurate between all members due to note changing and game developments.
While we identified additional problems such as note taking, we felt that an app that would solve that problem would not be as fun or as useful to them.
Our first low fidelity prototype tried to address most issues mentioned above. As we began to user test our prototype in class we realized that it was far too complicated. We had the individual screens made up but did not have a process in place for the user to actually take advantage of them. Even our testers were learning the prototype during the testing process which was not good. The in class testing was not exactly valid because only role players would understand the interface. That being said we did learn how people would attempt to use the interface as they were guided through it. Our biggest take away was that it may be too complex and we needed to revisit the process behind Dark Heresy to really see what was going to be cut out. We decided to test our low fidelity prototype with some of the members of the group and they had a tough time as well.
The data we were looking for in our early prototype was mostly subjective data. We looked at facial expression, how many questions they asked, what questions they asked, and gave them a post test interview. Comments we received during the test were
“okay but I don’t understand what I’m doing. I’m not a role player so this really is tough for me to understand.”
“I like the map but I feel like there’s a lot of set-up involved and I wouldn’t want to do this much.”
“I don’t know where to start. I think I would start at my character screen?”
When we took this concept to our participatory design workshop we wanted to see how the club members would design the app. Interestingly enough they came to the same general conclusion we did. They began to add more and more features to the application such as inventory, player profiles, monster pages, etc. But because of this we noticed that they stopped using their created prototype in the game. When asked why they said “well we’re trying to use the app as we would normally but going to these other screens is making us think too much. I know the page in the book I need but I can’t remember how we thought it should work in the app. Rather than look stupid, I’m just gonna flip to it in the book.”
This quote confirmed our earlier finding that we were trying to do too much with the app. The effect this had on our prototype was that we decided to cut out: inventory lists, character profiles, and monster pages. We wanted to focus solely on making the battle phase more efficient. When we asked our group what would help the GM told us that he would need a quick map generation tool for custom story lines (ones that are not straight out of the book). With this information we decided to add: Random map generator, map editing features, and a lock function to prevent erroneous editing. Elements we kept from the low fidelity prototype were: map as the main focus when it is on screen, turn order of players from a pull out menu, and drag and drop functionality for player and monster positions.
At this point we had focused down to what we wanted to accomplish: A mapping application that would reduce page flipping while displaying helpful information to the players and would facilitate the GM’s role in controlling the game by keeping track of turn ordering. We created the medium fidelity prototype from the feedback using Flash and actionscript because we were mostly concerned with the interaction with our program rather than the looks of it. Also since we were not going to address note taking problems we finalized our decision to implement on a tablet. The galaxy tab was available for rent from the library and supported flash so we chose that to implement our prototype for testing. We decided to stay away from catalyst because we felt that program did not support interaction as well as flash actionscript.
We conducted a simple usability test to test our main features, the map generation and battle phases with the book. We were looking for a rough page flip count and errors they would make. We also followed up with some simple questions. We asked them to generate a map, edit the map, and then go through a quick battle with us. Map generation was simple enough and users did not have a problem with this since we made it so simple. We were happy with how this section went. The prototype was fast and easy to set up a battle field and did a good job at visualizing all the necessary elements. One suggestion was that we also visualize the direction that the characters and monsters on the map are facing. This element is very important for surprise attacks and line of sight combat mechanics. The GM also told us that he needs to be able to manually edit the turn order since it is not always set in place. There was considerably less page flipping and less repetitive questions being asked of the GM by the players. Players did not need to ask how far away monsters were and did not need to flip back and forth between the map page and actions page. Now all they had to do was flip between action pages which was much less of a problem. We were very happy with the app and so were our club members.
If we had to do our usability testing over again it would have been nice to get more quantitative data. A better test design that looked at precise number of page flips without and then with the interface. We could then have a solid number or % improvement which would look really good for our findings. We definitely improved the process and our club is satisfied with it but we can’t say by exactly how much we improved which is unfortunate.
We were pleased with the entire process. Reflecting on it we could have saved ourselves a lot of trouble by basing a lot of our early design decisions on direct observation like we did later on. We fell in to the trap of trying to do too much and added in too many “cool” features that were really unnecessary. Additionally we felt that we should have met with our group more than we did. This is partially due to their scheduling problems and motivation but also because we didn’t force the issue with them. This left us in the dark too often and forced us to make some of the poor decisions we did. In the end we felt we corrected our mistakes but could have done more formal usability tests as mentioned above. As designers we learned a lot. The participatory design workshop was probably the most valuable section for us as we got to see non-designers design an app. We took their feedback and made the appropriate adjustments to it and because they were part of it they were more ready to accept what we produced. Our non-conventional approach to most of the sections were very fitting for this type of club and as stated first in this reflection keeping a playful mind set really allowed us to have fun during the entire process. Having fun with the club really broke down the designer participant barrier which was key for getting our type of club to commit to the process. If they had viewed it as work they would have surely contributed less. In the end we produced a fairly good usable prototype that we plan to develop further for our group.