I was brought onboard to ideate on minigames and test the game for usability and compatability with our audience.
Copy of Hiro-Gameplay-Trailer-2.mp4
ROLE | Game Designer & Quality Assurance
STUDIO | Hiro Technologies Inc.
TOOLS | Unity, Miro, Mural, Trello
DURATION | 6 Months
Designed all minigames based on physiotherapy research and requirements.
Iterated designs to remove pain points from playtest, and to meet constantly-changing physiotherapy requirements.
Created and maintained Core Design Documents.
Research Reports on Systems from other games to ideate on how we could implement live-service models in the context of physiotherapy.
Researched physiotherapy needs to better understand how I should iterate my designs to satisfy our players.
Hosted live playtests during events to create actionable items to iterate on our designs.
Maintained playtest data to keep it referenceable and easily actionable.
Prototyped potential minigames in Unity to discuss if it would be beneficial as physiotherapy to our players.
Acted and put myself on video to help introduce audiences to the wonder of HIRO!!! Yippee!!!
This was the minigame that pushed me as a designer. I had to shift a lot of my design and the things I wanted to better match minigames that our players would actually enjoy and benefit from. I had to find the sweetspot of fun, interesting and healthy.
The way I found this out was through heavy experimentation and breaking my design down to the bare essentials that can meet all requirements. If I saw that players would get too bored, my design was too simple. If it was too hard, it wasn't simple enough.
I listened to feedback as much as I could, listening to the pains and praises of our playtester and sifting through and implementing feedback that would help the design reach the high point it needed to in order to satisfy our players.
My initial design focused on a round of play being varied through different object types affecting the stack of 'Scoops' on your Cone. It was a good foundation but didn't adhere to the requirements of the exercise: maintaining a stiff neck to train the spine and back muscles. Once we learned of this, I quickly shifted my design to gamify stillness.
Another requirement came when I was iterating on my design: players who stood still for too long began to feel pain, and we wanted to introduce movement in intervals as a break from the stillness.
This was my first attempt in gamifying stillness with breaks of movement. You can see a similar style of design from my previous iteration, where I try to introduce different mechanics on top of a base system.
I don't think this approach is inherentley bad, but it forgoes simplicity which is what this game needed.
After feedback and distaste on my designs, I realized that the problem was the design not reflecting the requirements; players needed to have fun standing still while needing a break to relax from movement. The game needed to be split between 2 different states, so I split the game into 2 states.
Children had training and motivation in standing still, while having fun in either dancing themselves in the dance phase, or watching their Gaurdian do silly moves in dancing. The design finally fulfilled the requirements asked of me, and I found it not through genius innovation but having the design reflect what was asked in an interesting or visually funny way.
Due to the Camera-Based nature of our game and limited resources I had to go out on the field and scouted for families to test the game. Most of my tests were conducted in libraries, with moderate success of getting children to play.
This didn't reach our target audience of disabled children, but having a child's perception on our game still helped in judging if our design is communicated to our players.
During these playtests I would bring a list of questions to asks, some questions are direct and some being vague to encourage the player to introspect on their experience more. And of course, I asked questions during and after play.
Typically I'd make a report on the playtests I hosted and create actionable items to bring up to the team. We meet everyday so I was able to have these concerns addressed immediately. I'd then write down the report on our Trello following guidelines in reporting changes.
For a project like HIRO, I tested if the design would work under as many physical contexts as possible. I'd handicap myself in either limiting my physical capabilities or playing in an unideal environment (like a cluttered office space).
This led to the team looking to solve these problems through onboarding processes leading players to better environments, balance changes in our game or adding mechanics to help mitigate likely issues to appear (for the soccer minigame, my testing led to the implementation of objects on the screen that players could move, creating safe zones for areas you couldn't reach).
I would also bugtest our minigames, this happened in conjunction with design testing. I'd just mess around testing our game's capabilities, which was usually me flailing my arms around.
Any bugs or unintended interactions I found I would bring up for our next meeting. This led to a lot of design discussions on what should be cut and kept, which is something I like to see in a design team.
A lot of the testing procedures I did didn't feel "official". Knowing this I went ahead and embraced the rusty testing style I was doing.
Testing in Chaos allows you to reach a broader range of potential findings in the games I work on, whether that be design insights or the most outlandish bugs possible.
Designs don't need to innovate or add something new. Once the core of a game is designed, adding onto that with only what's necessary still makes interesting or engaging designs.
This helped with some of my confidence as a designer, because I finally learned I didn't need to make masterpieces at every turn.