R6X live tests
How we built a new app to monitor cross-platform matchmaking activity.
.brief
problem
Our client is currently working through the last validation procedures before a new game mode is released to players. The end-user is a team of roughly 10 testers located in Eastern Europe who are currently struggling with an unstable matchmaking service. They have pointed out a lack of visibility on some data which is critical to their workflow.
solution
I was approached by a team from our partner studio in Sherbrooke - we had previously worked together on configuration screens for the matchmaking service. After the first round of interviews, we assembled a small squad featuring a product owner, another project manager, and a few engineers from both teams, to quickly mock-up, build and iterate towards a solution to expose this data.
I started contributing early in the project with research and wireframes to throw some ideas on the table in quick iterations. We skipped high-fidelity mock ups as our engineers deemed there was enough content to start building the MVP straight away.
year
2023
timeframe
Q3 Q4
tools
Figma, Miro
category
product design, wireframes, user research
How might we… display information in a meaningful way?
During interviews, I observed this team power-up consoles, login and set-up accounts, join & leave game matches, basically interacting with our services through their actions in game.
Some scenarios where they made sure the ranking/scoring algorithms couldn’t be abused made the system unstable and we started seeing discrepancies between our apps and the games running. The service occasionally didn’t recover as expected and a few zombie sessions appeared. When I asked the users about these, they replied this information was “hard to interpret”.
I realized this team was testing not only if matchmaking was functional, but also made sure that all the features around matches did work. R6S is a game about playing 5v5 matches online, now testing 6v6 is essentially the same game loop with 2 additional players, and services involved leader boards, rewards, sanctions, stats, challenges, friends, and much, much more. An astronomical amount of data spread across inter-connected services, and these users want one simple information: a snapshot of the matchmaking activity.
To achieve that, we considered a slice of requests from two services: Matchmaking Queue and Player Sessions.
Together, we highlighted which values of the JSON metadata were relevant, how to match, group, sort and compare these values.
→ Our strategy needed to embrace and promote metadata, so I explored a few possible ways to turn this pattern into a company guideline.
How might we… build a MVP within a few weeks?
After some discutions with the dev team, we agreed on delivering a new monitoring app. A flexible solution - which integrates well in the existing interface and does not break the existing service API or mapping conventions - surely the safest path to meet the short deadline.
This initiative revealed a blind spot in our processes when pushing / removing features - which we fixed by tweaking how we communicate when projects reach specific milestones of their software lifetime.
While the MVP was being assembled, I turned around to build a short list of suggestions to remove friction when replacing legacy software with newer tech, as this scenario was likely to happen again soon for an entire batch of apps of the same generation.
This list is divided into 3 categories - comm, doc, traffic - and notifies our support team of the scheduled changes, so they have time to onboard with the new product or features, and that users have a transition period with notifications based on their recent activity.
These suggestions turned into a process upon agreement of our stakeholders, engineers and support teams.
Roadmap and delivery
The app was simple enough that only a few demos were required to gather early feedback and start onboarding users.
By the time the product was officially released into the matchmaking surveillance toolkit, the client was already using our MVP actively - the roll-out was streamlined by early adoption and only a few additional adjustments were required. The app reached maturity after a few more updates, and is now the most used of the toolkit.
01
.final thoughts
Final thoughts - (。・・)ノ 。。。(~￣▽￣)~*
This project went really fast, the end product was shipped within a month of me sharing the first wireframe.
The test team was operating with short deadlines and was ill-equipped. We met their expectation by delivering value fast: the POC was showcased by the end of week 2. My wireframes facilitated the user interviews, technical breakdown and exec-level scheduling of the project.
Also, we relied on the org design system purely as an accelerator for aesthetics, which turned out to be a time-efficient strategy and gave engineers some space to breath, while I turned around and documented new patterns and components.
I like this project because it was both a very social type of investigation and a deep dive inside our services and organizational processes, bottlenecks and blind-spots. Also, because it reminds me that what matters in the end, is the end-user's satisfaction.
