Amplifidor,
an influencer
platform.

Solo-designed on top of a product three agencies had already touched. Extended it with new features, rebuilt the parts that were quietly broken, and gave it a real responsive system instead of a shrunken web layout. Four months, design delivered.

Client
Amplifidor
Region
Saudi ArabiaSaudi Arabia
Industry
Social Media / Marketing
Scope
Web · iOS · Android · Design System
Fig. 01 — Influencer Profile

Snapshot

Role
Senior Product Designer, solo
Team
PM, CTO, and the engineering teams I worked alongside daily
Timeline
4 months
Platform
Web, iOS, Android
What was mine
Every design decision across the surfaces I touched. The vision, scope, and the existing foundation from three prior agencies were set before I arrived. I owned how it worked, how it held together, and how it looked from there.
Overview

Amplifidor is an influencer platform for Saudi Arabia and the wider region, built to give influencers, brands, and agencies one place to run their work. By the time I came in through BitBang, the product had passed through three agencies. It had features, but it didn't read as one product. My job was to keep extending it while fixing the parts that were already wrong. The hardest problem wasn't adding screens. It was making a product built by four different hands feel like it was built by one.

Fig. 02 — Dashboard
Context

The platform brings influencer profiles, cross-platform analytics, an affiliate engine, a two-way wallet, and community groups into a single account. Brands use it to find and connect with the right talent in under an hour instead of scouting cold. Influencers use it to hold their whole presence in one place. The premise is consolidation, so the product itself had to feel consolidated. That was exactly what three rounds of separate agency work had eroded.

My Role
  • Mine: New onboarding, sign-in / sign-up, and account verification. Profile switcher. Search. Personal account and rate settings. Agency owner and admin functionality. A new dashboard, profile page, and analytics page. The responsive system and its components. Design system corrections. The mobile app.
  • Shared: Feasibility and sequencing with the engineering teams, since I was building on top of code that already existed and couldn't rewrite freely.
  • Set by others: Product vision, scope, and the inherited foundation from the agencies before me.
The Problem

Influencers and brands were being handed a product that looked finished and behaved like three products stitched together.

  • What people struggled with: patterns that shifted depending on which agency had built that corner. Flows that didn't match each other. And on mobile, an experience that was just the web layout squeezed onto a small screen, so nothing felt made for the device in your hand.
  • How I framed it: the obvious ask was "add these features." The real question was whether I could add anything at all without making the incoherence worse. So I framed the work as two jobs running together: extend the product, and quietly repair the base I was extending, or every new feature would inherit the same debt.
Fig. 03 — Rate cards
Approach & Success

Discovery was light by necessity. This was a contracted build on a product with two years of prior work behind it, not a greenfield start, so my first weeks went to reading what existed and finding where it broke rather than running a research phase I'd be inventing. Working next to the PM, CTO, and the dev teams gave me the real constraint map: what was cheap to change, what was load-bearing, what I'd have to design around.

Good meant coherence, not a metric. Could a new person move between the dashboard, a profile, analytics, and the agency tools without feeling the seams? Could the same flow work on a phone because it was designed for one, not resized into one? I didn't own analytics on this project and it didn't reach the point where launch numbers existed, so success was judged on the design holding together across every surface I touched, and on engineering being able to build from it without guessing.

Process & Exploration

The responsive system was faking it. What shipped as "responsive" was the web layout scaled down. It technically fit a phone and worked for nothing. I treated small screens as their own design problem, not a resize target, and built a new component set and layout logic for them. This was the clearest inherited failure on the project: something that had been called done, observed to fail in the hand, diagnosed, and rebuilt properly.

One account, many identities. A single login could hold several identities, personal and agency, each with a different set of things you could do and see. That meant a profile switcher that changed not just the name at the top but the whole capability underneath it, personal settings and rates in one context, admin and agency controls in another. The architectural call was keeping all of this inside one account with a clean switch, rather than splitting it into separate logins that would have fractured the person's presence, which is the one thing the product exists to unify.

Fixing components without breaking the build. Some of the design system had genuinely wrong UX baked in, and engineering had already built against it. I couldn't just redraw it. Each correction was a judgment about whether the fix was worth the rework it forced downstream, and I made those calls in conversation with the devs rather than over the wall.

Onboarding and the front door. New sign-up, sign-in, and verification flows, plus onboarding that actually set someone up rather than dropping them into a blank account. The first screens were among the most inconsistent inherited pieces, so they were worth rebuilding outright.

Fig. 04 — Analytics · audience and engagement
The Solution
  • New onboarding and authentication. Sign-up, sign-in, and verification, rebuilt from the inherited versions.
  • Profile switcher. Move between multiple identities inside one account, each with its own capabilities.
  • Search. New functionality for finding people and talent across the platform.
  • Personal account and rates. Influencers set and adjust their own details and pricing.
  • Agency owner and admin. A separate set of controls for running an agency on the platform.
  • Responsive system. A new component and layout system designed for small screens, not inherited from the web.
  • Dashboard, profile, and analytics. New dashboard, new profile page, a reworked analytics view pulling performance across the major social platforms.
  • Mobile app. Design work carried through to iOS and Android, plus multiple more features across the product that lived beyond these headline pieces.

The corrected design system is the connective tissue. It's what lets the parts three agencies never coordinated read, finally, as one product.

Fig. 05 — Program · participant criteria
Key Decisions & Tradeoffs
01
Repair the foundation while extending it, not after.
I chose to fix inherited UX and structure as I built new features on top, rather than shipping features fast and cleaning up later.
Tradeoff: slower visible progress early, and harder conversations with a team used to additive work. It was right because every feature added onto broken patterns would have carried the break forward.
02
Design mobile as its own thing.
I rebuilt the responsive system from scratch instead of patching the scaled-down web layout.
Tradeoff: more work than adjusting what existed, and new components to maintain. But a resized web page was never going to feel like it belonged on a phone, and this product's whole pitch is that it feels made for you.
03
One account, one switcher.
I kept multiple identities inside a single login with a switcher that changes capability, not just label.
Tradeoff: more complex permission and state handling than separate accounts. Splitting logins would have been simpler to build and would have broken the single-presence promise the product is built on.
04
Fix components even where engineering had built them.
When a system component had wrong UX, I corrected it rather than leaving it because it was already coded.
Tradeoff: rework for the dev teams, and I had to pick my battles on which corrections earned their cost. Leaving known-bad patterns in a design system means every future screen inherits them.
Fig. 06 — Settings example
Impact & Results
  • In four months, solo, I extended a product three agencies had left incoherent and pulled it back toward reading as one.
  • The responsive experience went from a resized web page to a system actually designed for mobile.
  • The design system was corrected enough that engineering could build from it without inheriting the old UX mistakes.
  • Multi-identity, onboarding, search, rates, and agency admin all shipped as design, coherent with each other rather than each in its own dialect.

Directionally: the foundation was solid, the seams were closing, and the product finally had one voice across its surfaces.