RIZZ.MARKET — A PLATFORM FOR AD INTEGRATIONS BETWEEN BRANDS AND BLOGGERS, BUILT ON TELEGRAM MINI APP

COMPANY

Rizz.market

ROLE

Product designer

YEAR

2025 — 2026

THE PROTOTYPE WILL BE CLICKABLE SOON

The platform brings together two audiences with different goals and workflows: advertisers and bloggers. It works as a marketplace for collaboration offers, where advertisers publish products and bloggers apply to receive them and create social media content. All communication, payment, paperwork, and deal management happen inside the platform.

THE ADVERTISER CREATES AN AD CAMPAIGN WITH A MARKETPLACE PRODUCT

BLOGGERS APPLY TO THE CAMPAIGN AND GO THROUGH ADVERTISER SELECTION

THE AD INTEGRATION BEGINS: THE BLOGGER COMPLETES SEVERAL STEPS TO KEEP THE DEAL SAFE, RECEIVES THE PRODUCT, CREATES CONTENT, AND UPLOADS THE FINAL MATERIALS

AFTER THE ADVERTISER APPROVES THE CONTENT, THE BLOGGER PUBLISHES IT ON SOCIAL MEDIA IN LINE WITH ALL LEGAL REQUIREMENTS

THE BLOGGER GETS PAID THROUGH THE PLATFORM, WHICH AUTOMATICALLY HANDLES TAXES AND GENERATES A SERVICE AGREEMENT

OVER THE YEAR,

I REDESIGNED NAVIGATION, REBUILT KEY PRODUCT FUNNELS, AND IMPROVED

THE TEAM’S DESIGN PROCESS

When I joined the project:

I needed to define the design development strategy myself and set goals for 3, 6, and 12 months. There was only one criterion: every change had to create tangible value for the product and the team.

The interface had grown chaotically

Navigation did not scale well and did not work with Telegram Mini App

There was no design system or shared decision rules, so developers hardcoded design elements

There was no design process; new features were shipped quickly, often without designer involvement to save resources

The project was funded by investors and had not yet reached self-sufficiency

NAVIGATION REDESIGN

AND USER FLOW REASSEMBLY

Analytics showed that users regularly got lost on the way to key actions. The reason was the absence of a unified navigation system, so the first stage was to rebuild the app structure around user scenarios and Telegram Mini App constraints.

01 UNIFIED NAVIGATION ARCHITECTURE, MOBILE-FIRST, AND TELEGRAM MINI APP

Instead of a unique structure for every page, I designed a unified navigation framework adapted for Telegram Mini App. I accounted for platform constraints and Telegram’s built-in navigation; unified the Navigation Bar for all internal screens; introduced a shared screen structure and grid; made navigation behavior predictable across scenarios; and built a system that could scale to new screens without changing the core logic.

02 REWORKED THE TAB BAR

Before the redesign, identical navigation elements could open different types of screens, breaking user expectations. I unified the transition logic, designed consistent element states (Default/Active), and made navigation easier to remember.

03 BOTTOM SHEET FOR COMPLEX PATTERNS

Used for full-screen secondary scenarios such as filters and information screens. It has a fixed height and a consistent behavior pattern, so it does not depend on content volume and remains predictable for the user.

Component

Usage examples

04 DRAWER FOR SUPPORTING SCENARIOS

Used for quick contextual scenarios: menus, notifications, tooltips, and confirmations. It adapts to content height and lets the user complete an action without interrupting the main flow.

Component

Usage examples

NOT STOLEN — JUST INSPIRED A LITTLE TOO MUCH

Users were already dealing with unfamiliar product scenarios: launching ad campaigns, passing legal deal stages, and managing integrations. That’s why I deliberately borrowed the visual language of the main screens from interfaces users already knew. For example, the Market section was based on familiar patterns from Ozon, Wildberries, and Yandex Market.

«If you're not embarrassed by the first version

of your product, you've launched too late.»

REID HOFFMAN

DESIGN DEBT KEPT GROWING UNTIL I STARTED SPEAKING THE SAME LANGUAGE AS DEVELOPERS

After introducing design review into the process, it became clear that the team was spending too much time fixing visual mismatches during development. A release could be delayed by another 2–3 days because of review iterations. Initially, the team used a free library, but it did not cover all needs or reflect the project’s visual vibe. For new scenarios, I started drawing basic elements manually, which created duplicates and made the interface harder to maintain. Alongside the redesign, I moved the interface toward a component-based approach. Before I joined, part of the interface was hardcoded, and tokens existed only on the development side. Together with developers, we aligned token naming in Figma and Tailwind.

COMPONENTS

ATOMS

PRIMITIVES & TOKENS

color/text/primary-black

Ag

type/header-3

base/green/500

12

A PLACE FOR EVERYTHING,

AND EVERYTHING IN ITS PLACE

When I joined the team, there was effectively no design process. The company had gone six months without a designer, so some features were developed without design support. Mockups drifted away from production, components were missing, and developers did not always know which design was current and ready to build. Alongside the product redesign, I rebuilt the workflow between design and development.

Organized Figma

I separated working files by product area; moved the design system into a dedicated library and connected it to all mockups; introduced Ready to Dev and Design Review pages; documented every task, user flow, and implementation detail directly in Figma; and organized the workspace structure and team access.

Introduced mandatory design review

Every implemented task was checked before release. I compared the test build with the mockups, documented mismatches on a separate Figma page, and supported every note with screenshots and explanations.

Synchronized design and development

After components and tokens were introduced, the number of mismatches dropped noticeably. If a screen moved to Ready to Dev, it meant the design was approved and ready for implementation without extra clarification.

BEFORE: ONE SHARED FIGMA FILE

FOR EVERYTHING

AFTER: EVERY TASK IS

STRUCTURED AND DOCUMENTED

CASE 1. OFFER MARKET AND BLOGGER APPLICATION FLOW

Problem and analysis

The Market was the first entry point into an ad integration. This was where a blogger decided whether a campaign was worth applying for. Analytics, blogger interviews, and support requests revealed several systemic problems:

Bloggers did not understand the terms they were applying under or what they would need to do after approval. It was difficult to understand the three payment formats — CPM, fixed fee, and barter — and how compensation was calculated. Users did not understand who paid the tax or that the product had to be purchased first with their own money. The new auto-approval mechanic did not fit the existing interface and only increased confusion. Campaign cards contained a lot of information, but it was poorly structured, so users could not quickly make an informed decision. Users formed their own expectations of the deal that did not match the real collaboration terms. As a result, two key funnels dropped at once: Market → Apply and Apply → Start Work. Users either did not apply at all or applied without understanding the terms, then later refused to complete the campaign.

Solution

Added onboarding in a stories format so users did not have to search for answers in support.

Banners highlighted extra earning opportunities.

The catalog structure became closer to familiar marketplaces, making relevant campaigns easier to find through categories.

Moved key parameters into filters so users could quickly exclude unsuitable campaigns.

Instead of a generic “Apply” button, the CTA started showing what mattered most — the integration price. I removed quick applications in favor of a more deliberate choice, which increased the number of bloggers who started working on campaigns after approval.

Social media logos made it immediately clear which platform the integration was for.

Badges for labeling and tax surfaced important legal terms directly on the card.

CPM (per views)

Fixed fee

Barter

Results

Market → Apply

+2 pp

conversion growth, accounting for traffic growth

Apply → Start Work

+52%

increase in bloggers starting work after applying

Support requests

fewer questions about payment formats and collaboration terms

CASE 2. INTEGRATION PROCESS

Problem and analysis

Research with bloggers, managers, and the head of support showed that most mistakes happened not because the integration itself was complex, but because the process was unclear. Bloggers regularly attached the wrong materials: receipts without a QR code, reviews still in moderation, incorrect ERIDs, or screenshots of the wrong product. Advertisers’ technical requirements had to be explained manually through chat, PDF instructions, or support. Communication between the blogger and advertiser slowed down the integration and worsened the experience for both sides. Most corrections repeated from integration to integration, but the interface did nothing to prevent these errors. As a result, the number of revisions grew, integration time increased, and support kept answering the same questions.

THE IN-DEPTH INTERVIEWS INCLUDED 3 BLOGGER RELATIONS MANAGERS

AND THE HEAD OF TECHNICAL SUPPORT

Hypothesis: “If the necessary instructions, checks, and communication are embedded directly into the integration process, users will make fewer mistakes without manager or support involvement.”

Solution

01 Split the integration into sequential steps

Each step became a separate screen with its own statuses, deadlines, and tasks.

02 MOVED INSTRUCTIONS INTO THE PROCESS

The user received tips exactly when they were needed: how to attach a receipt; what a review should look like; which ERID to insert; and which publication requirements applied.

Step 1
Product order

Step 2
Marketplace review

Step 3
Content (with labeling)

STEP 3
Content (native)

Step 4
Social media publication

03 REPLACED FREE-FORM CHAT WITH SCENARIO-BASED COMMUNICATION

Instead of open-ended messaging, users sent predefined requests: deadline extensions, revision requests, and other scenarios. This reduced unnecessary communication, sped up approvals, and stopped advertisers from having to educate bloggers.

04 ADDED A REQUIRED SELF-CHECK BEFORE SUBMITTING EACH STEP

Before submitting each step, the user confirmed the most common requirements for that stage, helping reduce revisions and check their own work.

Results

Support requests

fewer support requests about the integration process

Start → Complete integration

+8 pp

conversion from starting an integration

to completing it increased

Average revisions per integration

3 → 1

average revisions per integration

decreased x3

Average integration time

integrations are completed faster thanks

to fewer revision iterations

THANKS FOR READING,

COME BACK WITH AN OFFER

Telegram

LinkedIn

ostrostrow@gmail.com

©

2026 SOFIA RUDAKOVA — ALL PIXELS RESERVED

CASE STUDIES ARE AVAILABLE ON DESKTOP