Survive various levels based on your in-game activity!

Poro Survivor

overview
Problem

Rainmaker’s Challenge of the Day metagame was for League of Legends players to join our daily hosted challenges and compete to win cash prizes. Although this iteration resulted in revenue increasing due to users paying entry fees more often, user acquisition cost was still too high due to a few reasons:
‍

  • We marketed ourselves as being a platform where you can make money.

  • Our free challenges and referral program gave too much RC (our in-game currency) for users to begin participating in paid challenges.

  • Players bought lower-ranked League of Legends accounts to play against beginners to inflate their scores (AKA smurfing), which frustrated other users, who eventually left the platform.

Solution

Shift Rainmaker’s positioning to attract the gaming audience we want. Users play free games like League of Legends or Valorant because they are genuinely fun and not because they promise cash prizes. We created Poro Survivor, a single-player metagame that acts as a naturally fun companion to your favorite game you already play. It’s a 100% free-to-play game with optional purchases.

The purpose of users earning RC shifted to buying in-game items/skins instead of making money to cash out, so user acquisition cost was reduced. Due to the nature of Survivor being a single-player metagame, smurfing wouldn’t negatively affect the experience of others, so players wouldn’t quit.

We also decided to update Challenge of the Day to be a self-serve platform and package it with Survivor to be within an arcade platform.

Team

Michael Cho

Senior Product Designer

Alex Daniels

Lead Designer/Product Manager

Jonathan Kennell

CTO

Jim Matheson

Lead Software Engineer

Sara Aous

Contract Artist

Scope

Mobile responsive web app

Timeline

3 months

Tools

Figma, Flow, Linear, Mobbin, Midjourney

My Contribution

As the Senior Product Designer on the team, I conducted a competitive analysis on similar products in the market, designed mockups, created new and updated existing design system components, animated graphics, and iterated based on feedback from testing.

Choose a World, Choose a Poro

Your Poro’s survival is based on your in-game performance!

A Challenge Every Level

Achieve the objective in your next League of Legends game to advance.

Progress and Reach Valhalla

Fail and fall back!

Our Process
Research
Brainstorm
Mockups
Animations
Development + Pivots
design
Research

I worked with Alex, our Lead Designer and Product Manager, to gauge users’ interest and to guide the product roadmap of our Survivor concept. We made 2 barebones figma prototypes with differing visions for what Survivor could look like.

Version A - An immersive side-scrolling adventure where your character progresses through a landscape of various levels, similar to Super Mario Bros.

Version B - A vertical scrolling path your character jumps through levels as stepping stones, similar to Duolingo.

Super Mario Bros. Wonder

Version A

Duolingo

Version B

Ten participants watched demo videos of each version. We wrote up a brief survey for them to take afterwards. Feedback showed a majority were interested in the Survivor concept with an even 50/50 split on version preference.

Due to our limited runway, we decided that Version B would be a lower technical lift while still achieving key points found from our analysis.

Brainstorm

Our goal was to create a metagame that users would truly find fun to play. Alex spearheaded the project as the Product Manager role, so he outlined his vision for the game’s many features and use cases through writing his product spec. Based on survey results and suggestions from participants, we wanted Survivor to achieve a few things:
‍

  • Graphics need to be compelling or else the game becomes too boring over time.

  • Unlocking random chests or bonuses throughout progression kept things fresh.

  • Earning in-game currency is fun even when it isn’t tied to real money. Its utility would be to buy extra lives/powerups/skins to help your character survive.


We already see these ideas in many games today. Even looking at Duolingo, all three points are represented in some form. Creating the graphical assets for this metagame would normally be a large time investment, so Alex leveraged generative AI through Midjourney for backgrounds and outsourced items and character illustrations to our Contract Artist, Sara.

AI Generated Images

Midjourney

Alex's Images for World 2

Alex's Images for World 1

States for Each Poro

Rough Sketches by Sara

Poro Characters

Iterations

Sara's First Draft of Items

Mockups

I researched different apps that had similar flows and components to Survivor. I used Mobbin to analyze flows from Duolingo, and I took screenshots of UI from games like Legend of Zelda for inspiration.

Jim (Lead Engineer) and Jon (CTO) switched over from using MaterialUI to a new CSS framework, TailwindCSS, and DailyUI as our component library due to offering more complete features and simple integration with NextJS, our current react framework. While this required engineering to recreate components from scratch, in the long run, the team could build much faster than before. DaisyUI came with many plug-and-play components that we could use, and this was a great opportunity for me to create newly styled components since they had to be rebuilt anyways.

Item Rewards

New "Tactile" Buttons like Duolingo

Level Complete Screens

Shop Experience

Level Screen

This was also a great opportunity to improve some basic screens such as the Sign In/Create Account flow. Instead of switching between the two, we just ask to continue through social sign-in or input your email, a much more straightforward process.

Old Sign In / Create Account Flow

New

Animations

The final part of the designs was for me to add animation to all the characters and items in order to bring more life and excitement to Survivor. After making some edits to Sara’s illustrations, I used Flow to create and export these new animations as Lottie files, which have lightweight file sizes and quick to implement by engineering due to easy copy-pasting of exported code.

Items

Poros

Development + Pivots

Due to our switch to Tailwind and DaisyUI, Jim was building much faster than before. However, since this was a tremendous amount of front-end work for one person, we made some tradeoffs based on level-of-effort/benefit and technical limitations we didn’t foresee.

Reusing Older Button Designs

Many new custom components needed to be built, so for now we deprioritized smaller items like our button redesign to favor pre-styled components from DaisyUI that easily matched with our previous button design.

Redesigned Buttons on Homepage

DaisyUI Buttons

Mobile Drawer Technical Constraints

The original mobile drawer design was inspired by Sleeper. However, we were a web app that is limited by the browser, and Sleeper was a native mobile app. We weren’t able to make the drawer behave the same way due to its complex inputs, so we had to expand it by click/tap and use tabs. This solution also consequently hid our primary CTA within the drawer, which was not ideal. We planned to design a fix after launch due to a tight deadline.

Sleeper-Inspired Drawer

Alternative Drawer

Survivor as its Own App

We initially designed an arcade that contained both Survivor and Challenge of the Day, but shortly into development, we thought about launching Survivor as its own product. We had a tight timeline, and it would be quicker and more efficient for development due to less compatibility issues with older frameworks used in Challenge of the Day.

We decided to build Survivor as a separate app. The consequence of this was repurposing the already-built left navigation of our metagames to instead link to pages within Survivor, which was not ideal, but engineering was able to develop much faster.

Left Navigation of Metagames

Repurposed to Survivor Only

launch
Launching Poro Survivor in Beta for our Discord

We launched the beta test to our Discord users! They tried out the metagame and gave us immediate feedback for the next few weeks as we worked to fix any crucial bugs that were found.

Sudden Layoffs

We were in the middle of planning iterative improvements and fixing bugs based on early analytics when, suddenly, Rainmaker announced that the company would not be able to continue due to funding. While it is unfortunate that in the end we couldn’t give Survivor the full marketing and product push it deserved, there are at least some analytics and designs that I can point to that displayed Survivor’s impact and future.

Tracking Success

Jon created our Amplitude dashboard to measure KPIs, and along with promising metrics, there were areas in need of improvement.

Activation Funnel Low Conversion

We only saw a 36.5% conversion of users from the homepage to the next (world) page. Given that the rest of the funnel had around 80-90% conversion rates, improving the percentage between these two pages would naturally our activation numbers. This was the most actionable item that we saw through our early data.

N-Day Retention Success

We measured out of users who completed Level 1, how many remained active in N days. Our goal was that by Day 10: 30-40% and by Day 30: 20-30%. We found that by Day 10, 38.6% of users were active, and by Day 30, 20.5% were active. These were better retention numbers compared to Challenge of the Day, which would help contribute to our push for positive Customer Lifetime Value.

Planned Future Improvements

To try significantly improving our 36.5% conversion rate on the homepage, we designed out some mockups that would give a clearer understanding of the metagame above the fold and further encourage playing the first level.

Current Homepage

Mockups for possible Improvements

Tradeoffs and Possible Improvements
Starting Out Smaller

While the decision to launch Survivor as its own product helped speed up development speed and quality, the decision came at a point when development had started. Ideally, we would have made the decision before designing, which would have made it faster to design and ship. Also, the navigation would have been optimized for just the metagame, itself.

Mobile Drawer Technical Constraints

Had I known the technical constraints of the drawer, I would have taken a different approach to our design. It may have been better to remove expand/collapse features altogether to keep both the Poro and primary button visible.

Support For More Games

We started with support for League of Legends because we were experts on it, and we knew the community around it. However, Riot’s API did not support Wild Rift, which is League of Legends on mobile, so we were limited to the desktop version. One match also generally took 20-40 minutes.

It would have been interesting to have support for Teamfight Tactics (Desktop + Mobile). Though it is a game we were not as familiar with, we could see potential differences in engagement between desktop and mobile users. We also talked about games with less time commitment like chess.com (Web) that could increase accessibility and engagement.

conclusion
Final Thoughts

Although in the end Rainmaker unfortunately had to close its doors before an official launch, we were able to release a beta version that felt more like a game in itself compared to any previous product we built. Our outstanding team created a product that turned players’ League of Legends games that felt like a grind into an adventure with a fun companion. This new game proved to be even more engaging than or previous product, Challenge of the Day, and helped solve its user acquisition problems.

Figma Mocks + Live Site

Take a look through the actual file! Things can get pretty messy as always. You can also check out the current site online here.

Loading
.
.
.
other projects
Designed and developed by Michael using Figma and Webflow