Building a Mobile Component Library: Practices and Lessons from iQIYI

Component libraries have become popular in the internet industry over the past two years. Their main value is clear: rapid front‑end page construction, reduced design‑development communication cost, and unified experience standards.

Building a component library is costly, so two undesirable outcomes must be avoided: (1) creating an overly comprehensive library that is never used, and (2) building a library that does not meet business needs. The article explores how to achieve a higher return on investment when constructing a business‑specific component library.

1. Preparation

Before building a component library, thorough preparation is required on two parallel tracks.

One track is to understand the current business development status and pain points, communicate core requirements between design and development, and explore construction solutions with the development team. The other track is for the design side to conduct a comprehensive UI audit, organize and summarize interface content, and then formulate design specifications.

1.1 Understand Business Status

iQIYI’s mobile business faces: (1) continuous addition of features and content leading to many legacy styles and pages, (2) highly specialized developer responsibilities causing inconsistent implementations, and (3) numerous independent sub‑businesses each maintaining their own code.

These conditions result in duplicated content, inconsistent implementations, and time‑consuming design‑to‑code hand‑offs, which hinder rapid iteration.

1.2 UI Audit & Design Specification

After auditing more than 400 pages, the team organized, refined, and optimized the UI content, then established a design specification for iQIYI’s mobile side. (The detailed specification is omitted for brevity.)

During this process, the team identified high‑reuse content and determined which components should be built.

1.3 Core Requirements

Control UI consistency through component‑based specifications, reducing unnecessary variations.

Components must accommodate business content and brand differences while supporting unified updates.

Provide cloud‑based dynamic adjustments and capabilities for component querying and management across dimensions.

2. Component Construction

The audit revealed two major component categories: basic components (e.g., modal, menu, toast) that implement fundamental functions, and business components (referred to as “cards”) that showcase business‑specific content.

2.1 Choose Appropriate Granularity

The team considered atomic design (atom‑molecule‑organism‑template‑page) but opted for a “block‑card” granularity to balance reusability and maintainability. Instead of referencing every element inside a card, a card is composed of predefined blocks, allowing business teams to assemble pages by invoking card components.

2.2 Fast Invocation, Extensibility, and Compatibility

Each card component has a clear name and defined content scope. To avoid over‑customization, the team defined a framework structure and allowed a limited set of interchangeable modules within each block.

Examples of various Card frameworks

Cards supporting multiple built‑in blocks

Two business scenarios were addressed: (1) direct reuse of components with global updates, and (2) brand‑specific adjustments that should not be overwritten by future component revisions. The team introduced a “component derivation” (parent‑child) relationship to allow localized changes while preserving global updates.

Card component usage example

2.3 Backend Management Platform

The overall workflow is: design defines component content → front‑end implements styles → backend platform manages publishing, distribution, and version control. The platform enables unified component usage, facilitates querying of component usage, and supports independent management for vertical business lines.

2.4 Sketch Plugin Integration

To bridge design tools and code, the team built a custom Sketch plugin offering automatic annotation, font‑size calculation, component naming lookup, dark‑mode color key conversion, and design‑to‑code export, improving efficiency even for non‑componentized tasks.

3. Enhancing Component Coverage and Reuse

To maximize efficiency, the team strives to replace existing page elements with components wherever possible. This involves extensive UI audits, similarity scanning of style code for secondary pages, and manual validation of high‑similarity candidates for componentization.

4. Outcomes

After a quarter of building and replacing components, card coverage reached 43% of iQIYI’s mobile pages. The overall “design‑development‑testing” workflow efficiency improved by approximately 40%, and UI consistency increased by about 25%.

The success was driven by continuous UI audits, weekly cross‑functional discussions, and a product‑manager‑like roadmap for component rollout. The article concludes that while componentization boosts efficiency and consistency, it should not suppress design innovation; a balanced approach that respects product value and holistic design thinking yields the best results.