Trine 4

UX Design, Design Thinking, Team Leadership

Trine 4 was created at an interesting point in the series. The first two instalments were done in 2.5D, with three dimensional environment, but with movement only in 2D. The third instalment went full 3D, which was a fresh take for the series, but not well received. So Trine 4 returned back to the 2.5D approach.

I was, together with the UI artist, in charge of the menus and their flow as well as the HUD.

Most of the menus were fairly straight forward and mostly copies of previous instalments of the game. I made wireframes of them while the UI artist created the art style and assets for them. Before implementing anything we turned the wireframes into a clickable prototype with Adobe XD to give a sense of how the information would be displayed and how the transitions would feel.

Screenshot of some of the wireframes for Trine 4 menus made with Adobe XD.

An interactive prototype made with the wireframes for Trine 4 menus

Early on, we identified two menus that would need extra attention: the level select menu and the skill tree.

Level Selection The level select menu was tricky. In Trines 1 and 2 it had been a list with a screenshot of a memorable moment in the level and basic level info. Trine 3 introduced a full-blown board game that the player would navigate with one of the playable characters. As the game was in 3D, this worked beautifully. The team wanted something similar for Trine 4, but as the game was in 2.5D, a similar map simply wouldn’t work as it would allow more dimensions to move in than the game itself.

Left: The level select screen from Trine 2. Right: The level select screen from Trine 3.

I went through the entire Design Thinking process with this menu.

I started by empathising with the team and users. Both had really enjoyed the visual design, though some players and reviewers felt going through it broke the flow of the story and immersion somewhat. The team felt the map was much better than the list in previous instalments, but struggled to come up with a way that felt immersive and true to the mechanics of the game.

Based on this information, the problem statement became: We needed to create a half-way space between a menu and the game world that did not break the flow of the game and employed a metaphor that worked for the game world and was faithful to the rich visualness and the mechanics of the game.

Together with the team we brainstormed multiple ideas, including tapestries and storybooks, but we kept coming back to the map as the best metaphor for the journey. I got an idea on how it could work and used Axure RP8 to make an interactive prototype for the team to test.

This is what the prototype looked like.

The prototype was a huge success, not only proving the concept, but also eventually cutting down on implementation time as the developers could refer to it to check for desired functionality. While the menu was among the most complex menus created for the game, it was also one of the fastest to implement.

This is what the the level select menu looks like in the game.

Skill Tree The skill tree was more straightforward, but it contained a lot of information and was a central part of the experience, so we wanted to make using it feel extra rewarding. Unlike previous instalments of the game where each skill was optional and could be acquired in any order, the player got certain skills at specific times in the game, while upgrades to those skills were optional and could be acquired at any time after the main skill was unlocked.

Skill trees in Trine (left) and Trine 2 (right).

I designed the layout for it and the UI artist focused on making all the interactions feel very rewarding through small animations and visual effects.

Mockup I made for the skill tree in Trine 4.

An animated mockup of the skill tree to showcase the different microinteractions created by the UI artist.

We had time to do this as we were involved with the project from the start. However, in this instance this came with a downside too. The number of skills grew significantly toward the end of the production and the layout no longer worked. In the end it was changed to a much simpler, grid-like layout to make it look cleaner and navigation work better.

The skill tree the game shipped with.

Close Project

Nine Parchments

Interaction Design, UX Design, Communication

I joined this project a month before planned launch date. My task was to go over the menu functionality, information architecture, and navigation to ensure the game could be played comfortably with PC, consoles, and Nintendo Switch’s handheld mode.

The UI artist had already designed and created high fidelity mockups for the menus, but they had done so with only mouse navigation in mind.

The most complex menu had two sets of nested tabs and two areas that needed to be navigated separately.

I redesigned the menus with the support of the UI artist to accommodate multiple different input devices: mouse only, keyboard only, mouse and keyboard, controllers, and touch. This required minor tweaks in some menus, but some required a complete overhaul of the interaction design and information architecture of the original design.

The redesign addressed the need for multi-input device compatibility allowing us to ship the game on all the target platforms. It also enhanced the player experience by ensuring consistency and ease of use across all platforms.

The screen needed to accommodate some menus such as the skill tree for up to 4 players simultaneously.

Ultimately, the game was launched 4 months after I joined, due to outside forces. Thanks to the complexity of the menus and a lack of proper UI pipeline, he redesign and implementation of the menus lasted altogether around 6 months, well past the initial launch, to the launch of the DLC. During this time, I owned menu design and implementation, creating and prioritising features and tasks, as well as ensured the consistency of menu implementation in terms of look and feel and functionality. This experience lead to me creating a more defined UI pipeline at Frozenbyte during the development of Trine 4.

Close Project

Boreal Blade

UX Design, Facilitation, Communication, Team Leadership, Mentoring, Coaching

I was asked to join the project with the mandate of owning the UI: I would design them and guide the UI artist as they created the art style for the UIs.

When I joined, I quickly found the team had not documented much of anything and as the project was moving toward the end of production, the lack of clear communication was creating mounting resentment among the small team. While everyone could give the same elevator pitch for the game, everyone was also making a game with a slightly different focus, which caused an increasing amount of issues in development.

I sat down with the team members individually and together and facilitated the creation of a game design document. As I helped them define the core audience, core mechanics, main sources of inspiration, and the competitors to measure the game against, the communication and morale within the team improved significantly. After they were aligned on core mechanics and goals for the project, they could set a clear direction for the project and the transition from iteration phase to polish phase was much smoother.

The UI design went fairly smoothly after the direction and focus of the game were clear. I worked together with the Creative Director in designing minimalistic menus for the game and coached a 2D artist as they learned to create icons and other UI assets.

Screenshot of the character customisation menu in Boreal Blades.

Close Project

Creating a UI Pipeline

UX Lead, Process Design, Design Ops, Production, Leadership, Facilitation, Communication

When I first joined a game project at Frozenbyte, I was asked to quickly check the menus and their navigation before they were implemented. Timeline for this entire process (check and implementation) was one month. In reality it took over 6 months to finalise the menus.

When the team shifted to the next project, the UI artist and I decided to ensure the UI pipeline was much more efficient in this and future projects.

The existing process, where each menu screen was treated as an individual feature completely detached from other menus, led to redundant work, inconsistent designs, and inefficient use of resources. This created a fragmented user experience and a general unenthusiasm toward UI development in programmers.

For example, Nine Parchments shipped with over 20 different shades of yellow used for highlights across all menus and changing each needed to be tasked separately.

To avoid this the UI artist and I created a style guide. It ensured consistency in design, reduced redundant work by programmers, and allowed for faster implementation of UI elements and entire menus. We opted to not build a full design system, as the point was to lessen the workload on programmers and we didn’t have their full buy-in for this project at the start.

This helped streamline the UI design and creation process significantly, by improving communication and shared understanding. It not only streamlined our design process, but also provided programmers with clear guidelines, reducing ambiguity, and speeding up implementation across all the teams involved in UI development. The style guide also had the added benefit of improving the accessibility of our games as the UI was more accessible by default as the accessibility features needed to be defined only once for each UI element.

Through this and prototyping efforts introduced in Trine 4 the UI creation process was reduced by more than half from approximately 36 man months for Nine Parchments to around 16 man months for Trine 4.

Close Project

Setting Up a User Research Function

UX Research, Process Design, Pipeline Design, Leadership, Facilitation, Communication, Expert Analysis

While Frozenbyte had a user research process when I joined the company, it lacked ownership and focus, which lead to unfocused insights and missed opportunities for actionable feedback.

The established user research process was this: Once the game was near shipping and almost completely polished, they would invite players over to their offices to play the game and give feedback on it.

The support team would organise and moderate these sessions. They would take the latest build on the day of the test, record the entire session, and inform the game team that the videos were available for them. The more tests they ran, especially on the same game, the better observations they could make during the sessions, and flag issues directly with the team immediately after the playtest session was over.

Over the years they have learned a lot about player perception and thinking through this process.

Over my tenure at Frozenbyte, I improved the process is multiple ways.

As the moderators could identify some issues during the tests, we created a system for them to document their own findings in the tests and share them with the team. The intention was to speed up the flagging of obvious issues, while the designers would go over the entire footage and look for more subtle design and gameplay related issues.

However, due to time pressures, optimism, and lack of clear boundaries on responsibilities, the designers soon started treating the reports moderators handed them, as enough. After all, the issues were obvious enough to be seen by everybody, so they must be the most important ones. But as the moderators were barely interacting with the game teams as their main task was player support, the moderators could never understand design intents or even guess what kind of feedback the designers were looking for.

During this time we also tried to bundle more test sessions into one, as previously each playtest session was analysed in isolation. This time also coincided with the pandemic, so we trialed remote playtest sessions internally.

While these steps were all in the right direction individually, put together into the process they resulted in the same issues the teams were facing in the past. This time, however, the issues were more hidden from everyone, as the team did more, but the results were as unreliable as ever.

I understood that the biggest issue blocking us from getting more out of our playtests was the lack of clear research questions. The moderators, and myself, had anticipated one, but often defaulted into “we’ll log everything we see”. As a research question was never required, the teams didn’t know to pose any, thinking they’d “know the issues when they saw them”.

User research had effectively become a checklist item to be crossed off, not something the teams put a lot of conscious effort into.

So, working together with management, designers, artists, writers, and developers, I set out to understand what people wanted to know about our users at any given time.

I trialed several initiatives:

• Concept tests for art and writing internally to see how we could feel more confident in our narrative structure and character concepts
• Launched large-scale surveys for an MMO in beta-testing and shared findings with the entire company with infographics
• Compiled ad hoc data collection efforts into a more concentrated and mindful one for an MMO in beta-testing to help the dev team to understand their players’ actions better and to help them find synergies between data across different features
• Established and documented expert reviews so internal experts could give feedback to dev teams in a more structured manner
• As part of expert reviews, got the rendering team to create colour blindness filters into our engine, so the game teams and QA could play the game in black and white or with different kinds of colour blindnesses to see if contrast between gameplay elements was ever an issue.
• Created a template for user tests, to help game teams identify the research questions each user test could focus on as well as the question’s effect on the entire test. This also helped facilitate communication within and clarify the division of responsibilities between moderators and designers.

These initiatives had several company-wide benefits:

• Increased confidence in design decisions
• Enhanced cross-team and cross-discipline communication
• Actionable insights from player data
• Improved research efficiency
• Streamlined internal processes for feedback

By the time I left the company, the teams had the capability to think about why they ran user tests, communicate effectively across different teams about the needs and capabilities of every person involved, and the tools to glean actionable insights from playtests within days or even hours after the playtest was over.

Close Project

Facilitation

Team Alignment, Culture Building, Roadmapping, Post Mortem, Workshops

The larger the team grows and the longer they work together, the easier communication breaks apart. While best practice is to communicate early and often, there are times when you taking a deliberate moment to focus on seemingly non-urgent things such as team alignment, culture and ways of working, building a shared vision and a roadmap to the future, or looking back and learning from mistakes and successes already past.

I’ve shepherded multiple teams through discussions like this and would love to help yours. Below are some examples of sessions and workshops I’ve run.

Team alignment The more team members there are and the more time passes, the more likely it is that there are breaks in communication and misalignment within the team.

I’ve designed and run custom made workshops to realign teams, surface and address any frustrations the team is harbouring, and build momentum within the entire team.

For example, the Boreal Blade team was completely misaligned on what kind of game they were making and frustrations were mounting as the team was moving from the iteration to polish phase of development. After guiding them through the creation of a Game Design Document, they had a shared language and understanding of what they were doing, and a way to address any changes that were not communicated clearly.

Team culture building Team culture consists of the values, goals, and ways of working that the team has.

I have designed and run workshops to allow teams to define and codify their cultures. This has improved the team’s communication, efficiency, and overall satisfaction from the end of the workshop long into their future.

For example, as a young studio, the team at Bitmagic found itself in a place where the team was split into small factions with mistrust and even hostility growing between each. After a half-day workshop, the team felt more connected to each other and safe to proceed with their work.

Roadmapping Even when teams are aligned, it is sometimes difficult to prioritise all the tasks at hand. Especially when the team is diverse, the amount of tasks brought to the table can feel overwhelming.

I’ve run Design Sprints and other workshops to clarify team vision, goals, and the way to reaching both.

For example, the design team at Bitmagic had grand ideas, but struggled to gain momentum. I ran a weeklong workshop to help the team solidify a shared vision, clarify goals based on that vision, define milestones for the next six months, and build a roadmap to them. This helped the team and management regain confidence and rebuild momentum that had been lost.

Post Mortem All too often teams feel the project is completed once the product or phase is finished. This thinking robs the team and company from learning from the project and its successes and failures.

For example, I was in charge of two internal projects at Redhill Games. After they ended, I ran a post-mortem for each team. I gathered information from them with a survey beforehand and designed the content of the half-day workshop based on the main points that arose from the survey. One team focused on a sense of ownership and communication in their session as they had struggled with both. The other team focused on defining the structure and guidance future projects would need, as these were the things that had caused their team the most issues. While the topics were difficult, both teams gleaned many insights valuable both on the individual and company level. One participant told me: “I have never been in a better organised or thought-out post-mortem, and I’ve seen and even run quite a few.”

Workshops I have created multiple interactive workshops to teach teams and groups new skills. These include design thinking, accessibility design, and how to use specific technical tools. After each, the participants have walked away with tangible skills or practical ideas to take back to their work.

For example, I ran a half-day workshop on Game UX that covered what UX Design and UX Research are, why they matter through practical examples and hands-on exercises for game developers and students. Feedback stated they learned new concepts and mental models with which to approach design as well as a newfound appreciation of the discipline.

Close Project