コンポーネントライブラリの構築にはコストがかかるため、2つの結果を避ける必要があります。1つは、包括的または強力であるにもかかわらず使い物にならない、もう1つは、特定のビジネスニーズを満たせず、努力が無駄になるというものです。では、より高い投資収益率でビジネスに適したコンポーネントライブラリを構築するにはどうすればよいでしょうか？

コンポーネントベースプロジェクトの全体フローチャート

コンポーネント ライブラリを構築する前に、徹底した準備が不可欠であり、この準備には 2 つの並行した手順が必要です。

一つのアプローチは、ビジネス開発の現状を把握し、問題点を特定し、コンポーネントライブラリに関する設計チームと開発チームのコア要件を伝え、開発チームと共に実装ソリューションを検討するというものです。もう一つのアプローチは、設計チームがページを包括的にレビューし、インターフェースコンテンツを整理・要約した上で、デザインガイドラインを策定するというものです。

この状況により、オンライン上には一貫性のない類似コンテンツが蔓延し、同じコンテンツが複数の場所で繰り返し実装され、単一の要素を変更するために複数の個別の変更が必要になるという問題が発生しています。全体的な設計・開発プロセスには時間がかかり、ユーザーエクスペリエンスの迅速な反復と最適化を妨げています。

コンポーネントを構築するには、まずコンポーネントの設計スキームを決定する必要があり、コンポーネントの基礎は完全な設計仕様になります。

400ページを超える内容を徹底的に検討した結果、インターフェースの内容を要約、整理、追加、削除、修正、そして洗練させ、最終的にiQiyiモバイルアプリのデザインガイドラインを策定しました。このデザインガイドラインの定義は長くなるため、ここでは詳しく説明しません。

3. 中核的要求

プラットフォームの観点から見ると、統一されたユーザー エクスペリエンスと効率性の向上という中核的なニーズと、社内のさまざまなビジネス ユニットの通常のニーズを組み合わせると、iQiyi のモバイル コンポーネント ライブラリが達成する必要のある主な目標は次のとおりです。

• 標準化された制御用コンポーネントを使用することで、恣意的な組み合わせや不要な小さな違いを減らすことができます。

• コンポーネントは、ビジネスのコンテンツとブランドの違いを満たす必要があり、仕様が更新された場合にも統一された調整をサポートする必要があります。

• クラウド内で動的かつ均一に調整する機能や、さまざまなディメンションからコンポーネントをクエリおよび管理する機能を備えています。

包括的なページレビューと要件に関する議論を通じて、色やコントロールアイコンといった基本要素に加えて、再利用性の高いコンポーネントを主に2つのカテゴリに分類しました。「基本コンポーネント」（ポップアップ、メニュー、トーストなど）は基本的な機能を実装し、ビジネスコンテンツを表示する「ビジネスコンポーネント」（社内ではカードと呼んでいます）は、ビジネスコンテンツを表示するコンポーネントです。基本コンポーネントの要件は比較的単純で、業界定義もほぼ一貫していますが、カードコンポーネントはiQiyiのビジネス特性をよりよく反映しているため、以下の議論では主にカードコンポーネントに焦点を当てます。

1. 適切な粒度を選択し、構成関係とフレーム タイプを定義します。

コンポーネントライブラリの構築というと、多くの人は「原子-分子-組織-テンプレート-ページ」構造を用いるアトミックデザイン理論を思い浮かべるでしょう。このアプローチは、より厳密で包括的な標準を可能にするため、設計仕様の策定に適しています。しかし、特定の業務アプリケーションで使用されるコンポーネントライブラリとなると、実際の状況に基づいて粒度を考慮する必要があります。

コンポーネントの粒度が細かくなるほど、詳細な仕様をより適切に実装できるようになります。しかし、結果として得られる組み合わせは非常に多様になり、全体として見ると多くの非標準化の可能性が生じます。さらに、共通要素で構成されるコンポーネントが互いに結合されているため、1つの要素の変更が広範囲に及ぶ影響を及ぼし、制御不能な状態につながる可能性があります。

そのため、カードコンポーネントを構築する際には、カード内のすべての要素に参照関係を作成しませんでした。代わりに、再利用性を高めるために「ブロックカード」という粒度を主に採用しました。つまり、異なるブロックモジュールとカード構造を定義しました。カードは複数のブロックで構成され、ビジネスロジックはカードコンポーネントを使用してページデザインを完成させます。

2. コンポーネントはすぐに呼び出すことができ、拡張性と互換性も備えています。

検索と迅速なアクセスを容易にするために、カードの構成要素には名前と、対応するコンテンツが明確に定義されている必要があります。カードにあまりにも多くのバリエーションを組み込めると、特定の通話中に内容が分かりにくくなります。一方、カードの変数が少なすぎると、ニーズを満たすために過剰な数のカードを作成する必要があり、カード間の類似性が非常に高くなります。

コンポーネントを使用する場合、2 種類のビジネス要件があります。1 つは、コンポーネントを直接再利用し、バージョンが変更されたときに同時に有効になることを期待することです。もう 1 つは、コンポーネントを使用するが、ビジネス ブランドのニーズに応じてローカル調整を行い、調整された部分はコンポーネントのバージョン変更の影響を受けないことです。

カードコンポーネントの使用例

3. 統合管理のためのコンポーネント バックエンドを構築します。

呼び出し関係を標準化・明確化することで、コンポーネント管理プラットフォーム上で各コンポーネントの使用状況を照会できるようになります。また、その後の設計イテレーションにおいて、コンポーネントの変更による影響範囲を明確に把握できるため、設計上の決定と変更の効果を保証できます。

デザインツールと開発コードを統合することでのみ、効率を向上させ、より良い結果を得ることができます。そのため、開発チームには独自のSketchプラグインの開発も依頼しました。このプラグインは、自動注釈、ワンクリックでのテキストの高さ変換、コンポーネント名の直接表示、ダークモードのカラーキーと値の変換、デザイン案のコードへの変換といった機能を提供します。これらの機能は、コンポーネントベースではない要件の効率も向上させます。

III. コンポーネントの範囲と再利用性を高めることで効率を向上します。

IV. コンポーネント化の結果