Anastasiia Iakovleva    •   Contact

GWI · Meta Ads Integration


TL;DR

  • Redesigned GWI’s integrations with ad platforms;
  • Replaced a broken "Push" button with a complete, structured workflow;
  • Reduced errors, clarified UX, and supported the launch.

Role: Senior Product Designer

Context

GWI is a leading audience research platform. Marketers and other interested parties come to the platform to learn more about their target audiences, their demographics, interests and more.

My domain was Integrations – enabling users to push custom audiences directly into advertising platforms like Meta Ads, Google Ads, and TikTok Ads for campaign targeting.

The Problem

When I joined the feature looked like this:

“Sign in to start a campaign”


Audience mapped to Facebook database attributes, estimation and a “Sign in” button.


In practice, users were hitting constant backend errors due to missing steps in the flow:
  • No ad account selection (required)
  • No campaign objective (required)
  • No campaign naming (optional)
  • No handling of auth conflicts (e.g. users with multiple ad accounts)

The integration was not aligned with how Meta/Google actually work, and this mismatch led to high error rates and poor user experience, meaning in practice, the feature wasn’t working at all.



My Approach


I zoomed out to map out the flows: current, ideal and possible ones.

1. Workflow Mapping

  • There was no documentation, so I mapped the real-life ad platform flow (part without GWI);
  • Mapped the current GWI integration blueprint;
  • Paired with backend engineers to connect specific errors to missing steps in our flow;
  • Continued the workflows in Meta Ads Manager, because it doesn’t stop upon Sign in.
        






2. User Research


The goal was to validate the assumptions on several technical topics, such as, the amount of campaigns and accounts, how important is the naming etc.

  • Created a lightweight Intercom survey

    → 56 responses in 1 week

    → 3% response rate

  • Validated assumptions: many users had multiple accounts, chose different campaign goals, audience reuse etc.





3. Ideal Flow Design


The survey data + knowledge of the existing flow and our and Meta’s limitations allowed me to build a new workflow blueprint that included:

✅ Selecting ad account;

✅ Defining campaign objective;

✅ Naming the campaign;

✅ Real error handling logic.





The Solution


The audience push flow was redesigned end-to-end using existing design system components to ensure consistency and speed of implementation.
The solution was shaped through team design critiques and continuous iteration with Product Owners, allowing us to align UX decisions with technical and business constraints.
Special attention was given to error handling and system feedback — particularly backend errors, which had previously gone unaddressed — turning silent failures into clear, actionable communication for users.










In the final design, a user is able to select the account to sign in into, the campaign objective and name the campaign so that the sign in smoothly transition into the Facebook side and can be continued from there.



Launch


The release wasn’t treated as a single moment, but as a process.
I worked side by side with frontend engineers to refine interactions and edge cases, pressure-tested layouts across devices, and partnered with Product Marketing to align the product story with what we were actually shipping.
We introduced the feature gradually — first through a soft beta, then a broader hard launch — allowing us to observe and correct issues before they scaled.


What changed


As the system stabilized, backend error rates dropped noticeably — especially around authentication and objectives (–38%).
We introduced granular analytics (Mixpanel) to finally see where users were falling off, and why.
With fewer fires to put out, both support and engineering could shift attention back to real user problems instead of infrastructure noise.


What this revealed


Frequent changes in Meta’s API exposed a deeper issue: the product wasn’t built for real-time adaptability.
Rather than patching symptoms, we planned a full UX research cycle to re-examine the core user problem — a turning point that led to what became The Pivot.