PROJECT OVERVIEW
I reimagined Moktiv’s meeting-led campaign service as a governed B2B SaaS product for music-label teams. Finance funded the account. Account Managers ran campaigns. Business Managers monitored performance. Account Owners controlled teams and permissions. The product connected those roles across funding, campaigns, strategies, creator work, reports, and approvals.
CLIENT
Moktiv
MY ROLE
Product Design Lead, via Plexable
SCOPE
Product strategy, research planning, information architecture, user flows, wireframes, financial architecture, design system, interface design, usability testing, and development collaboration
VALIDATION
Tested with 10 participants across two client companies
TIMELINE
June 16–October 28, 2025
TEAM
Delivered through Plexable with Moktiv stakeholders and the development team
The context
Moktiv helped music labels run TikTok creator campaigns, but the labels did not have a product they could operate. A new campaign meant a meeting. A change meant another meeting. Reports were prepared and sent manually. If a client wanted to check a budget, adjust a campaign, or understand how an influencer performed, the request went back through Moktiv.
I joined through Plexable to turn the existing admin panel into a client-operated B2B SaaS. Redesigning the screens was only part of the job. We first had to decide who could control money, who could launch work, and where Moktiv still needed to step in.
My responsibility
My mission was to reintroduce the admin panel as a B2B SaaS product that music companies could operate themselves. I reimagined and redesigned the system end to end: business rules, roles and permissions, funding, campaign and strategy architecture, creator review, reporting, wireframes, final UI, testing, and collaboration with the development team.
The turning point came when feature discussions reached questions the founding team could not answer: Who can fund the account? Who allocates credits? Who runs campaigns? Who monitors the business? I prepared a structured question set, Moktiv gathered answers from client teams, and I reorganized the product around four roles: Finance, Account Managers, Business Managers, and Account Owners.
CONSTRAINTS & TRADE-OFFS
The hardest decisions were about money, authority, and accountability. Finance needed to add funds without operating campaigns. Account Managers needed control over campaigns, strategies, influencers, and reports. Business Managers needed visibility into reporting and overall progress. Account Owners needed organization-wide access, team creation, invitations, and permissions. Moktiv still controlled onboarding and confirmed incoming payments.
● RESEARCH & CONTEXT
The research changed the shape of the product
Early conversations jumped quickly into features, but several basic questions still had no reliable answer. Who funded the account? Who allocated approved credits? Who ran campaigns? Who monitored the business? I prepared structured questions, and Moktiv took them to its clients.
The answers produced four distinct client roles. Finance funded the account and tracked transfers. Account Managers ran campaigns, strategies, influencers, and reports. Business Managers monitored reports and overall progress. The Account Owner created teams, invited people, set permissions, and retained access to every product area.
The same research exposed a creator problem: influencers were submitting videos without checking the campaign rules. That finding became a hard submission rule, not another dashboard shortcut.
● PRODUCT DECISIONS
Three decisions that made the operating model work
● PRODUCT ARCHITECTURE
The architecture follows the operating model
Moktiv kept onboarding controlled. A label could not self-register from the public website. Moktiv invited the first Account Owner, who created the organization and invited the rest of the team with role-specific permissions.
From there, the architecture followed the work: Wallet → Campaigns → Strategies → Influencers and submissions → Reports. Campaigns held the commercial initiative and total budget. Strategies separated Micro and Macro Influencer work, with their own rules, creator rosters, deadlines, open or invite-only participation, and performance state.
Shared governance connected the product: payment status, access, deadlines, content rules, approvals, and reporting remained visible across the workflow.
● PROCESS & EVIDENCE
I started with user stories and information architecture, then moved through flows, wireframes, the financial model, reusable components, final web UI, and usability testing while development was already moving. The early boards were working evidence; they changed as the client answers changed. They are not presented as the final architecture.
We tested with 10 people from two client companies. One participant did not understand what “strategy” meant inside Moktiv, so I designed a three-step walkthrough and put the task back into testing. The same issue did not appear in the remaining sessions.
OUTCOMES
Validation evidence, without inflated business claims
10
Participants
Finance, Account Manager, and Account Owner roles tested the workflows.
2
Client companies
Participants came from two music-label organizations using Moktiv’s service.
1
Comprehension issue found
The first strategy task exposed a terminology gap; a three-step walkthrough resolved it for the remaining sessions.
WHAT I’D IMPROVE
What the operating model changed
Music-label teams can see budgets, influencers, adjustments, reports, and creator contribution without requesting a meeting for every action.
Moktiv can move routine campaign setup, reporting, and influencer decisions to the client team and spend more time on strategy and platform evolution.
WHAT I LEARNED
What I would carry forward
When a team cannot explain who controls money, authority, and exceptions, the interface is not the first problem. The operating model is.
I approached Moktiv as a change in how the business worked. The interface followed that model.
More work
WHAT'S NEXT STARTS WITH A CONVERSATION.