As a product owner I was responsible for making sure the team understood our product goal(s) and their place within our overall business strategy. I was responsible for setting up and communicating product backlog items and their order. I organized and hosted meetings where I showed the team the product backlog and explained the reasoning behind the items and their order and priority. The team was able to give feedback and express the stories they personally preferred working on or that fit their knowledge and skillset the best.  At the time the development team consisted of four developers, three designers (myself included), two artists and a game-designer. At this time, the company (Flavour) HR responsibilities were designated as part-time functions to different members in the company. This meant that the team also relied on the product-owner for some HR related tasks. While this was not ideal, I did use my experience in education to facilitate these needs whenever and wherever I could.  

In august 2022 we the team got the go ahead to redesign the UI and menus in HackShield. My role as the chief UX designer was to lead this process and deliver an improved design. My first move was to get data and do research about the old menu that was currently in use. The next thing I did was to use my experience of user-friendly design practices to set up design guidelines and rules for the new design.

The goals we established are: 'Improve efficiency (for the most important tasks the user wants to achieve)', ' 'After discussing that with the team and receiving a go-ahead I made a list of existing and new user stories for features we wanted our new menu'’ to support. I created a (black and white) wire-frame and flow in order to establish the core screens, buttons and features that we would be planning.

In this process I applied my knowledge and experience as a usability expert to make sure user-friendly design principles are a part of the new designs. Some examples of this is to maximize the efficiency with which a user can accomplish their tasks. I prioritized the list of user-stories based on frequency and importance. To minimize the amount of clicks and/or screens I went for a spider-web design where the main menu acts as a central hub and most other screens are always only 2 screens away.

The next step was for me to translate our recently established style guide for print to a digital visual design style guide. One important aspect of the design is the principle of '’recognition rather than recall'. This principle facilitates accessibility. Some examples of the means through which the design facilitates this is by setting strict guidelines for interactive elements.

Buttons always have to have one pair of three possible color gradients. The font for buttons is consistent. And finally: if there is enough space, buttons should contain both an icon as well as text in order to explain their effect.  The result of these endeavors is now fully playable at https://joinhackshield.nl

‍‍Jump/Stomp Mechanic
‍The way players could interact with HackShield was rather limited before the introduction of the jump mechanic. The only way players could have an impact in the game world was when a level-mechanic facilitated them to do so. Enemies could only be avoided, not beaten. As a designer I tried to come up with a way to allow the player to feel like their actions have an impact on the game world and to facilitate player agency. I did not want this new mechanic to sacrifice accessibility or change the core-experience. I realized the character could respond differently to a click or a tap when the player performed the action on the tile they are standing on. I figured a downward stomping motion would feel empowering. The jump-stomp would stun new enemies in the game that the player could then beat by jumping on them, rewarding them with in-game currency. Another goal of introducing this new mechanic was to allow my colleagues to come up with other cool ways in which the player could have an impact on the world.

Game Design Framework
The core HackShield experience had been established in a short time-frame of about 6 months. Once the first few levels had been created the team mainly focussed on creating more content. When I joined the team there was an opportunity to reflect on the design and perhaps rethink the core principles. The goal was to enable the team to create gameplay and content that would both entertain and educate while satisfying our current player base as well as reach potential new audiences.

The game-design framework is a tool to help designers of HackShield game content create great quality content that satisfies the needs of multiple player-types. The team could use it as a tool during testing and review sessions in the scrum process.

‍Class Quests
‍The core-gameplay 'HackShield in the classroom' facilitates the educational experience for teachers and their pupils. We based it on our single-player game. However, as a designer I realized the context in which the game is played is very different. That means we should not challenge our players the way we do in the singleplayer HackShield game.

One of the key differences for this experience is that there is one player who is actually interacting with the game (usually the teacher) and there are 5 to 25 pupils watching. An implication is that for most people direct engagement is not happening. As a designer that means we need to grab their attention and entertain them in a different way. When designing the quests I tried to create key moments where teachers could ask the class what they think they should do. This could mean big crossroads where the player has to choose a direction. Or maybe choices in dialogue that could have big consequences for the rest of the story.

Teachers are often not very competent gamers. A lot of teachers see themselves as an authoritative figure which means that publicly performing a task that they know they are not as qualified in as their pupils poses a risk for them. It could also be boring for the people watching the player to see them fail and play the same part of the game multiple times. This is why we did not include enemies in the quests.

Another feature I introduced in the game are class activities. This is where the teacher can ask a class a question or it is a moment where they can partake in a class activity together. These proved to be very popular as it can be an opportunity for pupils to stand up, engage with each other on the topic the game presents. This also enhances the educational value of the experience.

One of the demands of the stakeholders was for the HackShield development team to increase the quality of the game experience while also increasing the output of game content. As a designer working on content (levels and class quests) I realized our toolset was severely lacking in some key areas.

The level-design toolset was very error prone. The toolset did not allow for much creativity: in-game level mechanics were built to support very limited use cases. A terminal (lever-mechanic) could open a gate or activate a lift. A terminal could have a quiz or not. For our team to create more interesting experiences, we needed a more modular toolset that would allow all kinds of combinations. On top of that we wanted it to be easily debuggable in case the intended behavior did not happen.

Together with my colleague Joris Dingelstad I came up with a level-object architecture in Unity C# that would allow modular use (by designers) and be easy to debug. This meant re-thinking some of the core code structures and convincing the team of the benefit of our new architecture. We realized we could benefit from refactoring our code from an inheritance pattern to rely on a composition pattern instead on many occasions. This meant splitting up a lot of huge monster-scripts into smaller scripts so that each component would have their own responsibility. Odin and the use of scriptable objects were also instrumental in allowing us to optimize the transparency of the workings of the code.

I was mainly responsible for mapping out the current code and visualizing its functionality and connections. I also visualized the new flow and basic functionality. On top of that I set up meetings with our colleagues to discuss and agree on the new patterns and solutions. Joris has been instrumental in actually writing most of the code while feedback from the team helped us come to the optimal solution for a lot of the smaller problems we identified while writing the new architecture. We also heavily relied on the plugin ODIN for many of the Unity editor functionality.

It was really fun to witness the impact of the new architecture on the team. Designers felt more freedom to create levels which in turn entertained players in new ways. On top if that, time spent debugging went down and we were able to not only create but also ship new content more rapidly than ever before.