YourVue

Move an existing panel into our first app

Savanta relied heavily on external panels to find people for surveys, and those costs were climbing. At the same time we ran our own web based panel, the OpinionPanel. Rather than have the two compete, the plan was to close the OpinionPanel and move its users into a new mobile app, our first B2C product, then grow the panel from there.

The direction from our main stakeholder was clear.

Qmee is a reward-based survey app handling up to 100,000 surveys a day. The instinct was to copy it directly and move fast.

Copying the leader gets you to second

Copying Qmee was the quick option, and the safe-looking one. But arriving late with a copy of what someone already does well gives people no reason to switch.

So rather than push back on the plan, I built on it. A short piece of research up front would let us keep what stakeholders liked about Qmee, the parts users genuinely value, and get ahead where it and its rivals let people down. Same speed to a credible product, better odds of users moving across.

They backed it. The brief shifted from copying a competitor to learning from the whole market and beating it in the gaps.

Finding the gaps the market leaders had left open

We reviewed three direct competitors and three market leaders, assessing what each did well and where they lost people. We then ran two rounds of testing with five users from the OpinionPanel, adapting the designs between rounds.

The findings that shaped the product:

• Personalisation was our unfair advantage. Because we own both the panel and the survey engine, we could store a user's demographics once and only ever show them surveys they actually qualify for. Most competitors can't do this, so their users waste time on surveys they get screened out of. For us it became the biggest driver of a better experience.
• Support has to feel immediate. People trade their time for points. If something breaks and support is slow, the app quickly feels untrustworthy and they leave.
• PayPal alone wasn't enough. A technical constraint had us launching with PayPal only. Testing showed a significant group didn't use it and wanted alternatives, Amazon, Costa and others.

Testing also answered the bigger question. We weren't reinventing anything or relying on a gimmick. The core was strong enough to compete with the market leaders on its own terms.

What we built that the others hadn't

The differentiators came directly from the research, each one aimed at a gap the competition had left open.

• Personalisation, powered by our own data. Save your details once and see only the surveys you qualify for. No wasted time, no being screened out halfway through. The backbone of the experience, and the thing competitors structurally couldn't match.
• Gamification. Levels, badges and progress, based on what works elsewhere: Duolingo, Fitbit, the Octalysis framework. A reason to return beyond the cash.
• A referral scheme. Points for inviting people who join and complete surveys, so the panel could grow itself rather than relying on paid acquisition.
• Easier cash out. Lower payout thresholds and more ways to take the money out, directly answering the biggest frustration users had with every rival.

The workflows were the strongest part of the work. Because the research was solid, the flows were quick to design and held up cleanly when tested again with users. Every journey, sign up, personalisation, taking a survey, cashing out, referrals and gamification, was mapped end to end and validated rather than assumed. Where a theme needed deeper exploration we used crazy 8s to generate options quickly before committing to a direction.

A new lite design system, and an argument for fidelity

Savanta's existing design system didn't support mobile apps, so I couldn't lean on it. Rather than treat that as a blocker, I used it as an opportunity to build a lightweight design system from scratch, enough to hold best practice and consistency, but scoped tightly so it wouldn't cost us the release date.

I also made the case to development that fidelity mattered here more than usual. An app isn't a web tool. A first impression of a clunky interface or a bug is enough for someone to delete it and never come back. The design system was how we protected that at speed.

Mentoring a junior through her first design cycle

I brought a junior designer through the entire project, her first time running a full cycle end to end. The pattern throughout: see it done once, then own it, and get sharper each time.

• Model, then hand over. I'd show a skill, but always asked how she'd approach it first. If her idea was sound, we ran with it.
• Observe, then do. I ran the first user interview while she watched, then she ran the next with feedback straight after.
• Coach with questions, not answers. Where does the reward money come from? How does a user track their points? Is this accessible? What happens when the content is far longer than the tidy example?
• Push past the comfort zone. I had her present her own designs to the tech team and defend the why, not just the what.

Presenting was daunting for her early on. By the end she was walking developers through her thinking without me in the room, and took those skills into her next project with far less input from me. I picked up plenty from her, too.

A clean migration and a strong start

We shipped on iOS and Android, built in Flutter. The first job was moving the OpinionPanel users across, and it went well: around 10,000 of the 14,000 invited made the move, a strong transfer rate and a solid base to build on.

Adoption backed up the research. Users took more than 150,000 surveys in the first six months, and the app held a rating above 4 stars across both stores. The personalisation advantage showed, and the core experience held up under real use.

The growth engine never shipped

To hit the deadline for closing the OpinionPanel, stakeholders made the call to launch without the growth features. The reasoning was that we were migrating an existing audience, so we didn't need gamification or referrals to bring people in yet, those would follow in a later release.

I flagged the risk. Those features were the engine: referrals to bring new people in, gamification and enough fresh surveys to bring existing ones back. Without them there was nothing to hold the audience once the novelty faded.

Then funding for the follow-up releases was withdrawn, and they never shipped. With no loop to attract new users and too little to keep the migrated ones engaged, weekly users dropped below 100, and the app was pulled.

What it reinforced

• Competitor research matters even when the pattern is solved. A reward survey app is well-trodden ground, but the research is what let us copy the proven parts and get ahead in the gaps, rather than ship a weaker copy of what already existed.
• You don't need a full design system to hold quality. The right components, scoped to the job, are enough to keep consistency and pace without over-building.
• Flagging a risk isn't the same as landing it. I raised the danger of launching without the growth features and trusted they'd follow. Next time I'd design an interim step, a quicker technical win to bridge the gap, rather than shipping with none of it.