Usability is the ease of use of and learning curve associated with an object, and Hadley Bellam works to ensure these are optimal for all PikPok games.
The PikPok team includes talented designers and as easy as it would be for us to rely on their instincts we endeavour to make our titles as user-friendly as possible from day one. This calls for testing, reporting, discussion of issues, and devising and selection of solutions, from early in the development process right up until the day the game goes live, and sometimes beyond.
Rather than engage external consultants we have our own in-house usability lab, run by Hadley Bellam. Hadley may be involved in the design process as early as preproduction, sharing his thoughts on the possible pitfalls he sees in the design document. A kickoff meeting to get the ball rolling may see him present, discussing the likely UI elements, and higher level issues associated with the title in question.
I asked Hadley what involvement the lab might have early in production:
“Outside of UI considerations, early usability is usually focused on input methods and camera/orientation, which are closely related. Whether the game uses landscape or portrait orientation will affect how the user interacts with the device. We need to consider left and right handed players as well as players who play with their finger(s) or thumb(s).”
“Will the game require users to play with multitouch or will it be playable using only one digit? Will input work as well on tablets as it will on phones? These are accessibility questions we aim to answer early to ensure playing the game is not uncomfortable for users. You may notice many PikPok games can be played with a single digit, thumb or finger, on either hand.”
“During frantic moments in Monsters Ate My Condo we wanted players to be making game decisions and creating strategies, not thinking about how to control the game or making accidental input mistakes. Input should be learned quickly and then feel natural.”
In some instances Hadley may not have a substantial role in the title’s development until later, when particular questions need to be answered. To address some Hadley is able to take advantage of the fact that we have several teams in the studio, using our own staff as testers for the lab.
Under which circumstances might you use PikPok staff to test?
“Testing on our own staff can be useful for quickly answering design and usability questions about specific issues. I’ve used this type of testing for paper walk-throughs of screen flows to assist designers with menu naming or ordering, or when trying to determine the friendliest terminology for a tip or tutorial step.”
“We sometimes use this testing for HUD item appearance and positioning. We might ask players an unexpected question such as “now pause the game” to see how efficiently they can carry out the task. We’d then move the pause button to a different corner and change its size or colour, and observe the results on new users. This process was used for HUD elements in Slam Dunk King such as the mascot power button, which requires good visibility and easy access during chaotic gameplay moments.”
Additionally, Hadley has a pretty good idea of the studio staff’s biases as a sample source, and can work with those:
“Testing difficulty balancing on our staff can be useful too, as their skill tends to skew towards being high. We know a game is too hard (or not communicating something correctly) if our own team really struggle with the difficulty in their first few plays.”
Other questions require members of the general public fitting a particular demographic to come in.
I asked Hadley to tell me about external test subjects:
“The bulk of our usability testing work is carried out on real world users; I recruit users as close to the title’s intended demographic as possible, puzzle fans for puzzle games, kids for kid’s games. However the skill of these users can vary greatly. We have users who play games every other month and users who play for hours each day. I test users who are new to mobile gaming and users who have been gaming for years. We ultimately want our games to be intuitive and usable by everyone.”
“For a test cycle I’ll bring three to six users into our lab, one at a time (unless it’s multiplayer) for each milestone of a game. By milestone we mean a significant stage in the development, e.g. Prototype, Alpha, Beta etc. This allows us to follow up on the success of implemented solutions from the previous test round as well as testing new content.”
Of course, testing doesn’t always turn up the results you’d expect. Hadley has a lot of knowledge about what will and won’t work, how to test for particular information, and how to interpret data, but sometimes entirely new phenomena are found in a sample group, and completely new design questions may develop.
“I ask users to complete a questionnaire at the end of their test to uncover additional understanding of issues I may or may not have noted during gameplay. These results can surprise in the sense they sometimes contradict the observations from the test, but often unknowingly so. A user may write in the questionnaire that the game was easy to learn, even though they totally missed a key gameplay function during the test, never noticing. This is why we can’t rely exclusively on feedback or mail out test copies to users for their comments – we must watch user’s interactions first hand in a controlled test to make neutral observations.”
“In terms of total surprise – I have seen users literally “Flick” the screen in our Flick Kick titles, I have seen users get stuck and comment “I would have quit by now...” on what we thought were the simplest of tutorial steps and users who pause and restart levels because they believe they’ve done something wrong or failed (when they haven’t).
“Of course the most pleasing finding is when a user asks if they can continue to play when the test session has ended. ”
***Interesting in partaking in usability testing? We want you to come into our studio and play our games as part of our regular usability testing, we’ll even pay you in vouchers for it!
No experience is required, but you must fit the following profile: • Aged 6 + (a parent’s signature may be required)
• Like PC, console or mobile games - but you don’t have to be good at them!
• Available for an hour between 9am - 6pm in Wellington CBD
• A good communicator Interested? e-mail firstname.lastname@example.org with the words “Usability Testing” in the subject and we’ll be in touch.