
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
CASE STUDIES ARE AVAILABLE ON DESKTOP
