PRODUCT DESIGN CASE STUDY
Survey Surfing Product Design
Turning in-game reward moments into a new survey audience
SUMMARY: Survey Surfing was a 0-to-1 product that plugged market-research surveys into the reward economies of mobile games. When a player wanted more diamonds, gold, or lives, Survey Surfing was one of the ways to earn them: take a survey, get paid in the game's own currency. I rebranded a half-built concept, designed the entire experience and the integration behind it, and worked with a founder and a dev team to ship it. It reached about 10,000 completed surveys a month within three months, and then taught us something about this audience that reshaped what the product could be.
POSITION: SVP of Product Innovation, InnovateMR
The Problem
At InnovateMR, we were looking for ways to get fast, high-incidence responses from an audience that research almost never reaches — young adults who don't join panels. One of the team members, though, recognized mobile games were full of them. There's a catch, though: the thing that makes that audience valuable is also the thing making it hard to get them. A game player's whole mindset is "get me back to my game." They'll trade a few minutes for an in-game reward, but their patience is limited, which the fifteen or twenty minutes a typical survey wants pushes. If we were going to develop a successful product for this market, I realized, it needed to work with that tension, not against it.
Beyond generating survey revenue, Survey Surfing was intended in part as a recruitment tool for our main online panel, PointClub. This product had one huge advantage that recruiting for PointClub usually lacked, and that's the fact the game publisher already had identified and engaged users. We could start from a high-trust position with these folks, which meant we weren't fighting the bot-and-fraud problem that usually eats a new panel alive. This gave us the ability to point high-incidence, general-population surveys at them and be much more confident in the resulting data quality.
MY ROLE: Product Design, Project Management
Leading the Team
I owned the design of the product end to end. I rebranded the half-finished concept, then designed every part of it, from the user flows, to the wireframes, to the interactive prototype built in Principle. The prototype was used to show the concept to the sales team. I was responsible for designing every screen of the site and, later, the native iOS and Android apps. I worked directly with one of InnovateMR's founders, Gregg Lavin, on the concept, and then directed our remote dev team on the systems that connected us to each game. In most cases, I wrote the actual HTML and CSS for the user interface, establishing the details of the design style myself. I also ran the conversations with the game publishers about what player data they collected, because the entire survey-matching model depended on it.
MY ROLE: Product Design, User Experience Design, Wireframing
How Survey Surfing Worked
On paper the flow was straight and simple. In practice, every game we integrated with bent the requirements a little.
The game types we targeted were ones with some sort of economy where the player earned tokens to pay for added benefits. These games often had offer walls with ways for the player to do some activity to earn rewards. The connection to our system ran through a native SDK we built, iOS first and then Android, that each publisher dropped into their app. That turned integrating us into a known, repeatable job for a publisher's dev team instead of a custom build every time. A player opens the game's in-app store, sees Survey Surfing listed as a way to earn, and taps it. Our SDK makes the call to us, carrying whatever the publisher agreed to share about that player, and we send back a URL with hashed parameters. Everything up to this point stayed inside the game. The one place we couldn't hold onto was the survey itself. The player was given a warning that they were about to leave the game and open a page in their browser.
That hand-off was the single biggest friction in the product, and the thing I spent the most later effort trying to fix. At the time there was no clean way to keep the whole interaction inside the game, so we had to send players to a browser and ask them to trust they'd come back richer. When a player landed on the Survey Surfing site from a game, an identifier that contained their game ID was hashed in the URL. If they were a returning player, we could pick up right where they left off. If this was their first visit, we ran a short registration and profiling step to gather the data we needed to match them to a survey.
This is where I added the piece I think worked well for this type of player, a profiling survey framed as a short, low-reward instant earn. To the player it looked like an easy first payout. To us it was the data-matching engine that made every later match better. One screen doing two jobs, honestly, with the player getting paid either way. Even better, the tracked return rate of players before and after this survey was initiated showed a marked increase in retention.
From there the player saw their top three survey options, picked one, and was sent to the survey, almost always in another browser window. We tried hard to keep the survey inside the Survey Surfing frame and never could, which matters for a reason I'll come back to. When they finished, they landed back on their Survey Surfing dashboard, saw their reward, and chose when to send it back into the game. Behind the scenes, when a player chose to accept the reward, we fired an API call to the publisher to credit that specific player.
MY ROLE: Product Design, UI/UX Design
Design Decisions That Mattered
Three choices shaped how the product felt, and all three came out of that "get me back to my game" state of mind players had.
I put the player in control of their own payout. Earnings visibly sat on their dashboard, and the player decided when to send them back into the game. This was a small action that made the whole exchange feel like it was theirs to control, not ours.
I designed the failure, not just the success. In survey research the worst moment is investing time taking a survey and getting screened out with nothing. For a player who left their game for that experience, that's a rage-quit. So a disqualified survey still paid, usually about 10% of the full reward. Nobody left empty-handed.
I built retention into the reward curve. Every survey a player completed bumped their earning rate up a notch on a metered scale. The more they came back, the better each survey paid, which gave them a reason to treat this as a habit instead of a one-off. Players could see this increase, too, adding to the feedback loop.
The whole experience was wrapped in one honest promise, because it was the only one that fit the audience. We'll get you back to your game as fast as we can, and the more success you have, the better this gets.
MY ROLE: Product Testing, Data Analysis
An Insight That Changed the Story
Engagement was never the problem. Getting players in and taking surveys worked. What we discovered was subtler and required paying attention to the data.
I set up a data filter to isolate just the survey jobs routed through Survey Surfing, and watched them on weekly reporting. Over the first month, confirmed again in the second and third, the drop rate on these jobs ran far above our norm. A typical survey had a user drop rate of around 10 to 12%, but with this market anything with a length-of-interview (LOI) over five minutes had a drop rate that jumped to around 30% or more. Lined up against each survey's length, the pattern was unmistakable: players were bailing right around the five-minute mark to get back to the game.
I have to be honest about how solid that number is and why it mattered. We didn't control the survey experience. In market research you're usually fielding someone else's survey, so the player goes off to the client's link in a new window and we hear nothing until they're terminated or get a complete. That left a gap where we registered neither outcome and so assumed the respondent had dropped out of the survey. Client data often included time-in-survey, but not always; it was very client-dependent. To pressure-test the theory, though, I rebuilt an existing client survey in a third-party survey tool and ran it through Survey Surfing myself. The metrics came back clearly, which is what convinced us the five-minute cliff was real and not an artifact of missing data.
The response was a design decision as much as an operational one. We capped the length-of-interview on anything routed to Survey Surfing, and I added dashboard messaging telling players the longest we'd keep them in a survey was about five minutes. That expectation held true, and the honest expectation did more for completions than squeezing in a longer survey ever would have. It wasn't a full correction of the drop rate, but we were able to work it down to acceptable levels over the next several months.
MY ROLE: Product Evaluation
Where It Was Headed
The cliff put a real ceiling on how lucrative this product could be, because the longer, higher-value surveys were exactly the ones this audience wouldn't finish. The ideal version of Survey Surfing solved that by keeping the entire experience in-app, with a survey built specifically for this interface instead of a borrowed browser window.
I went deep on what that would take. The concept I developed initially was to take an existing client survey, break it into its component questions, recreate it on the fly for this audience inside our own frame, and backfill the client's results behind the scenes.
The idea of disassembling a client survey and recreating it was laughable, and completely impractical. I explored the technical requirements and concluded it simply wasn't feasible. To work, we needed a survey building tool, which was still in the works, and several other features whose ROI simply wasn't justifiable. Keeping the survey in our own frame wasn't just a nicety, in my mind it was the thing standing between a good product and a great one.
Survey Surfing, though, was not meant to continue forward in this way. As InnovateMR went through a private equity purchase and major senior staff changes, this version of the product was de-prioritized, though the main site still exists at this link.
MY ROLE: Product Post Mortem
What It All Added Up To
Survey Surfing went from almost nothing to roughly 10,000 completed surveys a month within three months, reached an audience we'd never been able to reach, and fed new, high value members into PointClub. It didn't become the revenue line we'd hoped for, the five-minute cliff saw to that, but it opened long-term relationships with game publishers that outlasted the product itself. And it taught me the thing I've carried into every product since: with an audience like this, the unhappy path and the honest expectation aren't the finishing touches, they're the product.
Skills & Expertise
Product & UX Design
-
0-to-1 product design, concept to launch
User flows, wireframes & interactive prototyping -
Cross-platform design: responsive web plus native iOS & Android
-
Engagement & retention design
-
Designing the unhappy path
-
Registration, onboarding & profiling flows
Data-Informed Design
-
Drop-off analysis from live performance reporting
-
Hypothesis testing & validation
-
Setting experience constraints (LOI caps) from real usage data
Integration & Front-End
-
API-driven integration design with partner platforms
-
Mobile SDK design (iOS, Android)
-
Hand-coded HTML & CSS
Visual & Product Branding
-
Product rebrand from a half-built concept
-
UI visual design, icons & on-screen assets
-
Consistent patterns across web and native apps