// Protected work

Enter the password

This case study is gated. Drop the password Reem sent you and the page will unlock for the rest of this session.

← Back to home

// META Preview — case study upon request

Native Commerce Services

Company
Meta
Role
Design lead
Year
2024–2026
Overview

Meta Native Commerce Services offers a suite of independent, performant services, each solving a specific problem and each easy to integrate on its own: product recommendations, metadata signals and ranking, a UX component library, prefetching, and product maintenance and data management.

Goal

Help Commerce teams build high quality native commerce experiences faster and ship them to production with strong performance, by making it trivially easy to plug in proven services for ranking, recommendations, UX components and site performance optimization.

An Instagram ad tapping through to a native Decor collections page, annotated to show two platform services at work: personalised and contextual ranking driven by customised metadata, and the reusable common UX components the product tiles are built from.
My Role

Design lead. I created the design model and its principles, built the intake process and the compliance framework, reframed the platform strategy and set org-level priorities, drove the design position on architecture, and led two designers through the build.

  1. Problem

    1. 01

      Engineering The visible cost. Every new surface meant rebuilding primitives that already existed somewhere else.

    2. 02

      Drift With no shared source, surfaces diverged slowly. Spacing, states, empty cases, and loading behaviour all differed depending on who built them and when.

    3. 03

      Design review Every team ran its own design review cycle for components that already existed. A designer building a new surface would take a product tile through their own critique, then a design systems review, then a leadership review, to arrive at a component another team had already shipped and validated. The process was correctly protecting quality and incorrectly treating solved problems as new ones.

  2. What the Platform Saves

    Every service is built to the same four characteristics.

    Easy to integrate

    Import a component or call a ranking API. Clear interfaces and documented integration paths, with no platform expertise and no full-stack adoption required.

    Modular and independent

    No cross-dependencies. Adopt one service, several or all of them, and the component library still works with a team's own native UI.

    Plug and play

    Value from day one. No multi-week onboarding, no architecture kit to take on first, no migration project.

    Performant

    Every service ships with performance optimizations already proven in production at Shops scale.

    Design cost efficiency

    Design teams building on the services skip the review cycles below. Each ran about four to six weeks.

    Without the platform
    1. A new surface needs a product tile
    2. Own design critique
    3. Design system review
    4. Leadership review
    5. A component that already existed

    Three review cycles to arrive at something already built and validated.

    With it
    1. A new surface needs a product tile
    2. Pick the pre-approved component
    3. Ship

    The value isn't that engineers rebuild less. It's that designers stop re-litigating solved problems.

  3. What I Did

    1. 01

      Created the scaling model The design model and its principles: reusable component patterns, the hierarchy between them, how they compose, and the distinction between a component piece and a component assembly. Design and engineering both build against it.

    2. 02

      Built the operating infrastructure A component intake process so teams could request what they needed instead of building their own, and a two-part compliance framework following the piece and assembly split, with explicit targets against both apps' design systems. I defined and directed the design system's information architecture, its structure, naming and rebrand, and consolidated the documentation into one source of truth discoverable from inside both systems.

    3. 03

      Reframed what the platform was for The original case was engineering velocity. I rewrote it around unblocking design workflow: pre-approved Facebook and Instagram components remove the per-team review cycle for every team that adopts them. I set org-level priorities, gaps and sequencing, carried the stakeholder alignment, and defined the platform's role in making AI-generated design output shippable.

    4. 04

      Set the design position on architecture, then led the build I drove the design position on rendering strategy and shaped the H2 architectural decisions, including the consistency versus velocity tradeoff between server-driven and native rendering. I directed two designers through execution, prioritized the build task list, ran quality testing sessions, and documented status and outcomes.

  4. Design system

    Design System Structure

    Every component is documented the same way in the design system: what it is and which surface it belongs to, how to use it, best practices, the platform specifics for each app, its anatomy, layout and spacing, and its loading states. I set that structure and the bar each entry had to meet. The designers I led produced the specs themselves.

    1. Tagged media, one of the 26.

  5. Adoption

    One Component, Six Surfaces

    The same product grid, running in six different post-click surfaces: full-screen destinations, sheets over feed, reels-driven shopping, and the full shops surface. Each is owned by a different team, and none of them rebuilt it.

    1. Watch and Navigate: the lululemon product grid, two columns of product tiles with names and prices.
      FB Watch and Navigate
    2. Instant Experiences: a full-bleed editorial image above a two-column product grid.
      FB Instant Experiences
    3. Dynamic landing page: a recommended-for-you product grid filling the screen.
      FB Dynamic landing page
    4. Instagram commerce page: a new-arrivals product grid in a sheet over feed.
      IG commerce page
    5. Collection lite: an Outdoor Voices collection with sort and filter above the grid.
      FB Collection lite
    6. Native shops collection: a brand hero above filters and a two-column product grid in the full shops surface.
      IG Native shops collection

  6. Outcome

    All 26 priority components built and validated, past the stretch target. Adopted across 12 product use cases, by teams I don't manage.

    Across the platform, the team cut development time by 60% and saved tens of thousands of engineering hours for the teams building on it, on a single stack rather than fifteen separate ones. That is the number that matters for platform work: it only counts if other people ship faster because of it.

    The part that outlasted the components is the operating model. It began as a request queue with the platform team as the bottleneck, and has moved to teams adopting on their own. The organization now funds the platform as somewhere to build ahead of demand rather than a library to draw from.

  7. Want the full story?

    This page is a preview. The full case study covers the design model and its principles, the piece versus assembly split that made the standard enforceable, the compliance framework, the intake and documentation systems, and the migration in detail. Reach out and I'll walk you through it.