Home / Pley
bringing mobile games to the web.
I joined Trail, later Pley, after they had raised their Series A and were looking to scale. They had built technology that let mobile game developers bring their games to any web browser. This gave publishers a way to sell directly outside the app stores and reach players through web campaigns. A few games had launched successfully, and the next challenge was making that repeatable.
My job was to lead the product design team, but as the company went through the ups and downs of the gaming market, my role grew. I tend to spend my time where the problems and blockers are. At Pley, this meant working in developer relations and customer success to shorten the feedback cycle and help get games launched.
The challenges largely fell into two categories: converting web visitors into returning, paying players, and shortening the time from a signed publisher to a launched game.
For the first, the main issue was iteration speed. We couldn't user test ad conversion. It had to be tested for real, through focused experiments with real ad campaigns.
We needed to adapt the landing page and web player to different .
We worked with the user acquisition teams to adapt the experience to each campaign. An existing mobile player coming back to their game needed a different experience from someone discovering it on desktop. Things like when to ask for registration, whether to play a video while loading, connect an existing account or offer installation as a desktop app could change those first few seconds.
I designed the landing page template to be configurable through URL parameters. Campaign links were already part of the UA teams' work, so they could change the behaviour through the link used in an ad. They could run variations without waiting for a new build or involving Pley each time.
The other main hurdle was coordination. The publisher bought the technology, their studios had to implement it, and a marketing partner might be responsible for launching the campaigns. Getting from a signed contract to the first paying player could take seven months or more.
Me and our lead PM started by mapping the launch process with customers and testing a shared programme in Notion. It made the responsibilities, dependencies and next steps visible. That work changed how I thought about the developer products.
The developer console had become another SaaS tool people had to learn. I wanted it to feel like documentation and collaboration, things they already worked with. I designed pages where integration instructions sat alongside the settings, with a shared launch guide showing what needed to happen and who was responsible.
This brought the product closer to how launches actually worked: people across several companies coordinating tasks, making decisions and following up. By making the products feel familiar to developers and aligning our interfaces with the real launch process, we reduced resistance and cut time to launch to two months.
For the full case studies from Pley, reach out to fred@e2e.design.
The launch guide in the console. It names the marketing, developer and Pley teams on the launch and shows how far each step has come.
The launch program in Notion. Each step of a launch, from evaluation onward, split by team, with a checklist and the decisions the customer had to make in time.
I redesigned a few capability pages as interactive documentation, combining the instructions with the controls needed to complete the work.
A checklist in the sidebar showed which capabilities had been integrated and which remained. Developers could see their progress and move between the instructions and configuration without having to navigate separate sections of the console.
icebound-secrets.com/?connectMobile=true
The game already had a healthy mobile player base, and our data showed that desktop players played longer and were more profitable. The publisher wanted to encourage existing players to play on both platforms. A campaign link could force the link-mobile-progress QR code, so those players could continue from their mobile progress instead of starting again.
zw.deadahead.zone/?promptPwa=true
Some campaigns targeted a more mid-core gaming audience and highlighted that the game could be installed as a progressive web app. The prompt PWA parameter let us offer that option when the page loaded. The param could also be used to increase playtime for retargeting idle authenticated players via email campaigns.
autogunheroes.net/play?forceAuth=true
Some ads brought people into the game without converting them into registered or returning players, which meant they generated no revenue. We added a force auth parameter for retargeting campaigns aimed at people who had played and engaged before but hadn't returned. Without an email address from registration, we couldn't reach them by email. Retargeting gave us a way to bring them back and ask them to create an account.
icebound-secrets.com/play?freePlay=600s
We didn't know how long someone needed to play before they were invested enough to create an account and save their progress. It varied from game to game. A free play parameter let us test how much playtime to allow before asking for registration without shipping different builds or campaigns.
emergency-hq.com/play?showVideo=true
Some games had strong cinematics that appeared after the initial loading screen. We added an MP4 upload so the web player could show that video while the game loaded. A query parameter turned off the same video inside the game, so players wouldn't see it twice.
Image 1 of 9