Skip to main content

Hello There!

Do you like discovering new things?

Premium features: Success (frame: Premium features - success)
Premium features: main list with Honey balance (frame: Premium features - main)
Premium features: Oops, not enough Honey (frame: Premium features - Oops)

After this study you will know that

I can turn a revenue target into a system people understand, and I can do it as the only designer in the room.

Overview

I designed a separate in-app store where Hornet members spend Honey, the app’s existing currency, on individual Premium features, from a sketch on paper to production. Honey purchases went up by 37%+, and the feature has been live for about three years.

Client
Hornet, a gay dating app
Type
In-house product design
Platforms
iPhone, Android, and a web app opened from inside both
Role
Sole product designer
I led
Logic, research, wireframes, prototypes, hi-fi, in-app ads and notifications
Others led
Development, QA, analytics, revenue targets
Team
Product manager, growth and revenue lead, analytics team, 10+ QA testers, lead developer, web team
Tools
Figma for wireframes, prototypes and hi-fi. Usage data by feature and country came from the analytics team.
Live since
2023

Hornet: Premium Unbundling & Revenue Optimization

The Challenge

Unbundling premium features and introducing a secondary storefront into a 15-year-old legacy social application without causing decision fatigue or alienating the existing user base.

My Role

Sole product designer. I spearheaded the behavioral architecture for the new premium flow, focusing on choice architecture, cognitive load reduction, and iterative prototyping to ensure a frictionless journey.

The Business Impact

Successfully integrated the new storefront, optimizing the conversion funnel and mitigating cognitive load. The unbundled architecture unlocked a new scalable revenue stream, and Honey purchases went up by 37%+ after launch.

37%+

increase in Honey purchases after the feature shop launched.

Hornet in numbers

100M+
registered users
2.3M+
monthly active users
100+ min
average time in the app per week
21M
messages sent per day
2011
year Hornet was founded

Company-wide figures as Hornet states them for advertisers: hornetapp.com/about/advertise (checked 21 October 2026). Founding year from the Hornet Media Kit (December 2022). They describe the company, not the result of this project, and are marketing claims, not audited figures.

01 Hook and context

Finance wanted money, and fast.

Hornet is a gay dating app, and many of its features were free to use. The analytics team could tell exactly which ones people used the most. Finance and marketing wanted a part of the product that earns well, and earns fast.

The idea came from the growth and revenue lead. I joined it on paper, at the company meetup in Cape Town, with developers and the finance team around one table.

Hand-drawn first sketch: Premium split into single features paid with Honey
The first sketch, redrawn
A laptop on a table showing a video call with a shared slide; faces of other participants are blurred
Status review of the Premium unbundling work, on a team call.
02 Problem

One big Premium. Many small needs.

Honey is Hornet’s in-app currency, and it already existed. You could buy it in the web store (next to caps and T-shirts), or earn it when somebody sent it for your creative content. Members spent it on stickers and on gifts to creators.

Premium, meanwhile, was one big bundle. The job was to unbundle it, so Honey could also buy single features, such as seeing who viewed your profile.

Business goal

Make money from the product quickly, without rebuilding it.

Assumed member benefit

Get the one feature I want without paying for a whole subscription.

03 My role and its limits

One designer, many people.

I was the only product designer on this. I defined the flow and interaction logic, ran the research, drew the wireframes, prototypes and hi-fi screens, and designed the in-app ads and notifications for the features, and later for new ones.

I led by influence, not by authority. Nobody reported to me, and I did not manage people on this project.

I did
  • Logic and behavior of the whole flow
  • Research and competitor review
  • Wireframes, prototypes, hi-fi
  • Conversations with analytics, per feature and country
  • Ads and notifications
Others did
  • Product manager: made time for it next to regular work
  • Growth and revenue lead: the idea and revenue goals
  • Analytics: usage data
  • 10+ QA testers: testing
  • Lead developer and web team: building, and telling me what was possible
04 Principles

Three rules I held to.

These came from how I work, and I used them on every screen.

  1. Draw every state before building any of them. Every window variation, every case that can happen, so everyone knows what to expect.
  2. Test first, and let reactions set the logic. How fast people get there, what triggers them, what they like and what they don’t.
  3. Let data inform the price, country by country. What is popular in one country is not popular in another. The numbers came from analytics.
From wireframe to hi-fi

Same screen, two stages

Wireframe of the Premium features list, shown in a full phone frame
Hi-fi Premium features list with Honey balance, shown in a full phone frame
05 Insights

What the numbers said.

Because people could use the features freely, the analytics team could show which ones they already used the most. That is where pricing started.

Popularity differed by country, so a feature that earns well in one place would not in another. That moved me from one global price to rules per market.

In tests, I watched what people did, how fast, and what made them stop. In that data I found six types of users on Hornet, by how they behave and communicate.

Hand-drawn sketch: usage data and country lead to the rule
Schematic, no real figures
06 Options

Five or six meetings, one flow.

Over five or six meetings with the developers I tried different flows: how a member gets from a locked feature to the shop, what a tap does, and when it asks for payment. Then I tested the wireframes as a prototype to see how fast people got there.

Hand-drawn sketch of the flows compared in meetings
Flows compared in the meetings, redrawn
Wireframe: Flow 1 from the grid (frame: 635:4937)
From the grid
Wireframe: Flow 2 Premium features (frame: 512:4332)
From Premium features
Wireframe: Flow 3 Feature list (frame: 512:4415)
From the Feature list
07 Decisions

Three free uses, then Honey.

D1

The first uses are free

Problem
Many features were free, so there was little reason to pay for them.
Decision
A feature is free for the first three uses; after that it costs Honey, and some features cost more than others.
Why
Usage data showed which features people already reach for, and it differs by country.
Premium features: list with price per feature (frame: Premium features - main)
D2

Add to bundle, or unlock now

Problem
A member may want one feature, or several.
Decision
Each feature card has two actions, Add to bundle and Unlock, a choice of duration, and a cart that shows one price per bundle.
Shopping cart: price per bundle (frame: Feature list - success)
D3

A web app inside two mobile apps

Problem
The iPhone and Android apps and the web app do not behave the same way, yet the shop is a web app opened from inside both.
Decision
I designed one web interface that is entered from both mobile apps and still feels like part of them.
Why
iPhone, Android and the web app behave differently, so the handoff between the apps and the shop had to be designed.
Entry from the app into the web shop (frame: Premium features - main)
D4

When Honey runs out

Problem
The person wants a feature and does not have enough Honey for it yet.
Decision
An “Oops” screen with one clear button, Buy more, for every entry point.
Oops: not enough Honey (frame: Premium features - Oops)
D5

Active features: what is left, and what next

Problem
Members lose track of what they have paid for.
Decision
An Active features screen with days left on each feature and an Extend action.
Active features (frame: Active features - success)
Wireframe and hi-fi

Hi-fi, key states

Hornet Premium features screens, pair 1
Hornet Premium features screens, pair 2
Hornet Premium features screens, pair 3
Hornet Premium features screens, pair 4
Hornet Premium features screens, pair 5
08 Where is the line?

The ethical bit.

Some of the paid features are filters on sensitive attributes, such as sexual role and relationship status. A mechanism that asks for Honey after the third use is exactly where I should say how I thought about the line.

Mechanism
First uses free, then Honey.
09 What did not work

The idea I dropped.

10 Collaboration

The web app did not want to behave.

The hardest conversation was about platforms. iPhone, Android and the web app do not work the same way, and the shop had to be a web interface entered from inside both mobile apps.

I went through every screen with the lead developer and the web team, who told me what was possible and what was not. The product manager protected our time next to regular work, so it could ship.

11 Result

Did it work?

37%+

increase in Honey purchases.

GoalEarn well and earn fast
OutcomeHoney purchases up 37%+
Wireframes and final Figma designs

From first flows to final screens

12 Validation and launch

From alpha to the store.

Hornet ships through separate builds. The feature went to alpha and beta testers with QA first, and only then out to the store as an update. First the 10+ QA testers, then members who sign up to test early versions. QA checked that it worked, prototype tests checked whether people understood the flow, and alpha and beta checked it in the real app.

It has been live for about three years, and my screens are still in use.

13 Reflection

Would I change it?

What still holds up: my screens are still in use, and the team still ships in the pattern I designed. I had a great team. Some people researched, some tested, some read the analytics and told me who spent how long on which screen, and I added my own analytics work on top.

What I have not evaluated is how it performs today. What I would check now, country by country: how different types of members behave and how much time they spend talking. A small app section can teach you a lot about people.

14 What this study does not cover

Honest limits.

This study shows depth and ownership, not people management. I led through influence, with analytics, QA, developers and the growth and revenue lead, and did not manage a team here.

15 Craft details

One icon, everywhere in the app.

Orange crown icon
Premium feature
White crown icon
Neutral
Yellow crown icon
Active Premium
16 Questions I often get

The short answers.

ScopeDid you start the project or get a task?

The idea came from the growth and revenue lead. I shaped it from paper to production.

Proof in the study: Hook, Role

ScopeHow many people, and for whose work were you responsible?

I was responsible for the design of the whole feature. Nobody reported to me.

Proof in the study: Role

StrategyWhy this problem?

Finance wanted fast revenue, and the data showed which free features people used most.

Proof in the study: Hook, Insights

ResearchWhere did the insight come from?

Competitor and previous-store review, analytics by feature and country, QA and user tests.

Proof in the study: Insights, Options

DecisionsHow did you convince others?

Five or six flow meetings and a tested prototype of the wireframes.

Proof in the study: Options, Collaboration

ResultsDid it meet its goal, and how do you know design was the cause?

Honey purchases rose 37%+. Growth after launch does not by itself prove that design caused it.

Proof in the study: Result

MistakesWhat did not work, and what would you change?

I would change little.

Proof in the study: What did not work, Reflection

LeadershipDid you lead a team?

I led by influence, not authority, on this project.

Proof in the study: Role, Limits

DIGITAL DESIGN EXPERIENCE MILIJANA KOMAD