インターフェイス統合：eコマースプロジェクトの経験

2012年の初めに、eコマースラインはMail.Ruグループで再編成され、すべてのサービスを更新するという課題に直面しました。 アップデートの一環として、すべてのプロジェクトのインターフェースが単一の分母になりました。 この投稿では、実際に統一がもたらすものと、大規模プロジェクトで作業する際のコストを最小限に抑えるのに役立つ方法について説明します。

入力データ

Mail.Ru Groupのeコマースビジネスには、商品、お金、不動産、旅行が含まれます。 それらに加えて、今年中に新製品-基本サービスの衛星に取り組みました。 その結果、航空会社、金融会社、修理会社の新しいプロジェクトが生まれました。



私たちの主なタスクは、短時間で基本的なインターフェイスを作成することでした。これは後で改善およびスケーリングする必要があり、今後必要になります。







設計部門のリソースに関する入力データは次のとおりでした。2人のスタッフとフリーランスの専門家を引き付ける能力です。 実際には、これは作業の一部が外部の請負業者に向けられ、多くのコミュニケーションがあることを意味していました。



リソースとタイムラインに基づいて、さらなる作業の戦略が定義されました-すべてのプロジェクトのインターフェースの統合。 Mail.Ru Groupでのこのような大規模な統合が最初であったため、このようなソリューションの明確な正当化が必要でした。

統一が必要な理由

開発コストのメリット



プロジェクトの統合により、インターフェースの設計、設計の作成、フロントエンドの開発にかかる時間を短縮できます。 しかし最も重要なことは、統合プラットフォームを使用すると、さまざまなサービスを迅速かつ簡単に接続し、プロジェクト間でモジュールを転送し、より少ないコストで衛星サービスを作成できることです。 最後に、インターフェイスを作成するためのユニバーサルコンストラクターを取得します。







節約は、生産コストに相当する金額だけではありません。 最も重要な要因は、完成品を市場に出すことができる時間です。 時間を節約することは、実際の作業を削減するだけでなく、チーム内のフリーランススペシャリストと作業する際の組織プロセスを削減するのにも役立ちます。



サポートされている経済的利益



統一されたインターフェースは、バージョン管理のサポートを簡素化し、製品のその後の進化を促進します。 新しい機能が表示されるか、既存のモジュールが変更されると、すべてのプロジェクトに最小限のコストで変更が実装されます。



同様のプロジェクトの問題も同様です。 ユーザビリティ調査を実施する際、結果の一部を他のプロジェクトに送信できます。 同様に、コンバージョンを促進するソリューションの成功は分野横断的なものになる可能性があります。

統一の種類

統合は、機能と視覚の2つのコンポーネントに分けることができます。



機能的統合とは、グリッド、ナビゲーション、検索のフォームおよびその他のモジュールの構築と操作のロジックの共通分母への削減を意味します。



視覚的な統一には 、フォント、色、距離のリズム、グラフィックスなど、さまざまなブランド要素が使用されます。 結果は、スタイルを使用するためのスタイルガイドです。 さらに、視覚的な統合には、ボタン、ドロップダウンリスト、入力フィールド、その他のコントロール、およびそれらのアニメーションなどの単純なインターフェイス要素が含まれます。 この部分は、いわゆるUIキットで説明されています。







統合の2つのコンポーネントには、異なる目的と実装の異なる領域があります。



そのため、ビジュアルコンポーネントはブランド認知度の向上に影響を与え、大規模なチーム内でプロジェクトの作業を合理化および同期化するのに役立ちます。 ただし、視覚的な統一は実際には時間を節約しません。 単一のガイドラインを作成することは、長く骨の折れる仕事です。 たとえば、アイコンの大きなセットを作成するための単一の視覚的プラットフォームを開発するよりも、10個の接続されていないアイコンを描画する方が簡単な場合があります。 したがって、通信時間のさらなる短縮は、ガイドのコンパイルと保守に費やされる時間によって平準化されます。



しかし、視覚的な統一は氷山の一角にすぎません。 統合作業のほとんどは、機能コンポーネントに当てはまります。







機能的な統合では、インターフェイスのさまざまな部分の作成と操作に関する一般的な原則について説明します。 このタイプの統合は、リソースと時間の節約に最も貢献します。 インターフェイスモジュールには、常に独自のメカニズムとさまざまな状態があります。 開発時間を大幅に短縮するのは、プロジェクトからプロジェクトへの移行です。 たとえば、コメントモジュールまたは登録モジュールは、実質的に変更なしでプロジェクトで繰り返すことができます。



これら2つのタイプの統合は、同時に実行する必要はありません。 これらはそれぞれ、タスクに基づいて個別に使用できます。



良い例は、ホワイトラベルプロジェクトです。 サービスプロバイダーは、機能的に統一された製品を提供します。このインターフェースは、クライアントがブランドに合わせて設計したり、視覚的に統一したりできます。

方法

問題に対する1回限りのアプローチ



最初の方法は、作業の開始時にすべてのプロジェクトに対して分析が実行され、機能要件とビジネス要件の形成がすべての製品の単一ソリューションの提案に基づいていることを前提としています。



プラス方式：

-共通の状況とプロジェクト分析の存在



短所：

-このようなソリューションの作成には、多くの時間と労力が必要になる場合があります

-エラーのコストが高い



この方法は、製品の開発中に分析の結果が古くなる時間がなく、プロジェクトの量に比例してエラーの価格が低下する小規模プロジェクトで最適に機能します。







「進化的」アプローチ



2番目の方法の本質は、作業が1つの製品から始まるということです。 作業シナリオと視覚スタイルが徐々に改善され、最小限のルールと要素のセットが作成され、その後、他のプロジェクトに適用されます。



これはあなたが話すことを学ぶ方法に似ていますが、ルールと要素は文字と比較できます。 プロジェクト間で「文字」を作成し、「単語」を作成すると、「語彙」を拡張し、「テキスト」の品質を向上させることができます。



ソリューションの利点：

-「おしゃべり」を開始するには、複雑なシステムは必要ありません。ここですぐに実行できます

-エラーの低価格、その修正は労働集約的ではありません

-作成されたシステムの最大の柔軟性、選択したコースをいつでも簡単に調整できます



マイナス：

-完全な分析の欠如

しかし、この欠点は、明確に定義されたインターフェース開発戦略によって解消されます。



この方法は、作業が反復的に構築される大規模プロジェクトに適しています。 私たちの場合、合理的な時間内に更新されたプロジェクトを起動し、これらのプロジェクトをさらに改善するための最速かつ最も痛みのない方法であるため、進化的方法が最適でした。

戦略

私たちは、シンプルで直感的なインターフェースの仕組みが主なものである、最小限の軽量設計に依存しています。 ミニマリストのソリューションは、販売される製品、最終的には消費者により焦点を当てています。 eコマースプロジェクトの場合、ユーザーが最終アクションに集中することは重要です。これは、コンバージョン、購入数、またはプロジェクトの収益をもたらす他のトランザクションで表されます。







さらに、このソリューションはより耐久性があります。 2012年初頭に再設計を開始しましたが、Windows 8 UIといわゆるフラットデザインの到来後も含め、選択した方向は依然として重要です。







インターフェースの仕組みについて話すと、単純なソリューションの方がうまく機能し、その後改善が容易になります。



ちなみに、多くの人は、ミニマルなデザインを作成するのにかかる時間が短くなると信じているという間違いを犯します。 実際には、シンプルなインターフェースまたはグラフィックをロードしたインターフェースの作成に費やされる時間に違いはありません。

機能統合

グリッド、ナビゲーション、検索フォーム、インターフェースモジュール



モジュラーグリッド



単一のモジュラーグリッドを一度設計する方法があると想定できます。 これは、同じ種類の情報を持つプロジェクトに適しています。



ただし、eコマースプロジェクトには、検索フォーム、製品リスト、検索結果、支払いフォーム、テキストなど、多くの種類の情報があります。 この場合、すべてのプロジェクトに単一のグリッドを定義することはできません。各タイプの情報には、グリッドの構築と動作の独自のシナリオが必要であるためです。



各プロジェクトについて、このプロジェクトの主要な情報に基づいてグリッドの動作を決定しました。



たとえば、Goodsプロジェクトでは、主な情報は2つの州に存在する製品リリースです。 製品の種類に応じて、写真またはテキストデータのいずれかが支配的です。 製品の2つのカテゴリ、「衣料品」と「コンピューター」を検討してください。 写真の形での外観は、明らかに衣服の場合、コンピューターの場合、テキスト形式の技術仕様にとって重要です。 画像は読みやすさを損なうことなく画面領域のほぼ全体を占めることができますが、テキストには幅の制限があります。 この場合、妥協することをお勧めします。幅を特定のサイズに変更するグリッドを使用して、情報の豊富さと読みやすさのバランスを維持します。







Travelプロジェクトの状況はまったく異なります。 プロジェクトは2つの主要な部分に分けることができます。 1つは、航空券、ホテル、ツアーを検索および予約するためのシステムです。 テキストと表は幅が限られている場合に最も便利に読み取れるため、この部分を拡大縮小する必要はありません。 2番目の部分-記事、レビュー、写真を含むコンテンツ-反対に、適応性が必要です。 この場合、プロジェクトのどの部分を優先するかを決定する必要がありました。 予約を優先部分として選び、サービスは固定グリッドを受け取りました。







ナビゲーションおよび検索モジュール



ナビゲーションおよび検索フォームの状況はより単純です。 検索フォームとナビゲーションの場所のロジックは一度設定されます。 プロジェクトによるこれらの要素の移行は、ユーザーが曖昧に知覚し、方向感覚を失わせます。これは、人がインターフェイスを研究し、特定の共通要素が1つの場所または同じ論理に従って配置されているという事実に慣れているためです。 したがって、プロジェクトで検索とナビゲーションを使用する一般的なシナリオでユーザーを一度トレーニングすると、はるかに効果的です。



エレメントの配置にはF字型ゾーンが使用されました。これは、ユーザビリティテストの結果によると、ユーザーが最も読みやすくなっています。 この配置により、すべてのプロジェクトで検索とナビゲーションが最優先され、横断的です。







すべてのプロジェクトの作業で使用するいくつかの簡単なスクリプトとルールを作成しました。



ルール1

第1レベルと第2レベルのナビゲーションは、ポータルの見出しの下にあります。



Mail.Ruポータルのすべてのプロジェクトには、プロジェクトのロゴと検索を含むall-portalヘッダーの共通要件があります。 青いポータルハットと白い背景とは対照的に、できるだけ暗いサイコロを使用してプロジェクトのナビゲーションを強調しました。 この決定は根付いており、現在では、たとえば、ポスタープロジェクトやスポーツプロジェクトなど、eコマースプロジェクト以外でも見ることができます。







ルール2

大きな検索フォームは左の列にあります。



それらは、短いものと完全なものの両方で表示できます。 垂直配置により、検索パラメーターの数を自由に変更でき、直感的でエンドツーエンドのままです。 これは、たとえばプロジェクトの財と不動産の場合に重要です。







ルール3

小さな検索フォームは水平に配置されます



限られた数のパラメーターを持つ旅行フォーム（たとえば、Travel and Financeプロジェクト）は、ナビゲーションの下の暗い背景にヘッダーの下に表示されます。 この配置もエンドツーエンドであり、画面領域を効果的に使用できます。 さらに、背景が暗いと、検索とコンテンツ部分が分離されます。これは、旅行では重要です。







ルール4

小さな検索フォームがある場合、フィルタリングは右側にあります



この配置では、フィルタリングはユーザーの注意を引き付けず、検索結果の追加の制御要素のままです。



ルールが採用されると、ソリューションを見つけて調整する時間を節約できます。

モジュール

モジュールの継承は、時間とリソースを節約するための闘争におけるショックです。 モジュールは、コメントを追加するための単純なページネーターまたはかなり大量のシステムのいずれかです。



モジュールには常に厳密に定義された作業シナリオがありますが、単一の視覚ベースの外部で使用できます。 よく考え抜かれた作業シナリオのプロトタイプがある場合、モジュールの設計はプロジェクトごとに変わる可能性があります。 たとえば、Mail.Ru ProductsのClothingセクションに基づいて、Lady Mail.Ruの衣料品カタログのショーケースを作成しました。







プロジェクトが多いほど、モジュールの基盤が充実し、人件費の節約が大きくなります。 単純なモジュールを組み合わせて、より複雑なモジュールにすることができます。 最終的に、入力されたページまたはページブロック-テンプレート（たとえば、「記事」ブロックまたは「新しいエンティティの作成」）を取得します。



テンプレートは、有限で厳密に定義されたソリューションではありません。 プロジェクトやタスクに応じて、テンプレートを完成させる必要がありますが、同様のブロックをゼロから開発する場合よりも、費やす労力は少なくなります。



テンプレートの作業量は異なる場合があります。 たとえば、記事のブロックには最小限の修正が必要です。







さまざまなプロジェクトの「新しいエンティティの作成」ブロックには、より多くの機能があります。 これは、「広告の作成」、「新しいプロジェクトの作成」などのページのブロックにすることができます。 この場合、一般的なシナリオは同じですが、スクリプトのステップは異なります。 たとえば、「写真のアップロード-写真の説明-プロジェクトの説明-プロジェクトの公開」。 その結果、インターフェイスが実装オプションと連携するための一般的なシナリオがあります。

視覚的な統一

フォントシステム、グラフィック、シンプルなインターフェイス要素



スタイル要素



フォントシステム、カラースキーム、インデントおよび距離のシステムは、最初のプロジェクトで作業する過程で作成され、プロジェクトごとにさらに補足および改善されます。 他のブランド要素と一緒にガイドラインで説明するのが最善です。 このようなドキュメントは、デザイナーとレイアウトデザイナーのチームのタスクを簡素化します。



私たちの場合、ArialおよびHelveticaファミリーと連携し、ジョージアを大量のテキストに使用しています。 主要な企業の色である青とオレンジは十分に明るく、要素を強調するのに役立ちます。 主に白とグレーの色合いを使用します。 このソリューションにより、青とオレンジの攻撃性を中和して、デザインを新鮮で明るいものにすることができます。



インターフェース要素



ボタン、スイッチ、入力フィールド、プログレスバーはUIキットを形成します-シンプルなインターフェイス要素のセット。 そのようなセットの1つでは、製品を視覚的に統一するには不十分であることを理解する必要があります。







アイコンとイラスト



視覚的な統一のための最も強力なツールは、基本的なグラフィック要素、アイコン、イラストの単一のスタイルです。







アイコン用の単一の視覚的プラットフォームを作成しました。プロジェクトアイコンには、読みやすいように暗い背景に対して、ニュートラルな下地にMail.Ru Groupブランドの主要な色が含まれています。 特に、あらゆるサイズで簡単に認識でき、ウェブでもさまざまなモバイルデバイスでも見栄えの良いシンプルなフォームに焦点を当てました。 一般的なソリューションでは、ラインを拡大縮小できます。 当社の1年前のソリューションは、現在の設計トレンドにうまく統合されています。

統合結果

再設計前のプロジェクトの種類





再設計後のプロジェクトの種類







モバイルプロジェクト



何が行われた



2012年3月以来、つまり18か月間、基本バージョンの3つのWebプロジェクト（商品、旅行、不動産）の完全な再設計を実施しました。 将来的には、ユーザビリティ調査の結果に応じて、これらのプロジェクトの開発を継続し、更新を準備しました。 さらに、航空、修理、および金融という3つの新しいWebサービスが作成されました。 Webプロジェクトに加えて、モバイルの方向性を積極的に開発しました。iOS、Androidの2つのプラットフォーム用に、Money、Goods、Real Estate、Travelの4つのモバイルアプリケーションが作成されました。



面白い算数



Webプロジェクトの平均期間は2.5か月です

設計プロセスの最大参加者数-4人

1つのプロジェクトのレイアウトの平均数は60です

モバイルプロジェクトを作成する平均期間は1か月です

1つのアプリケーションの画面の平均数-22

結論

-統合は、設計プロセスと企業リソースを管理する柔軟な方法です。

-状況とニーズに応じて適用されるいくつかの統一方法があります。

-適切な方法論により、あらゆる製品を統合できます



この膨大な量の手紙を書いて、上記のすべてのプロジェクトに取り組んでくれたPolina Vydrichに感謝します。 そして、面白いペンギンのニキータ・グトロフに感謝します！



小規模または大規模なプロジェクトを統合した経験がある場合は、コメントで共有してください。



キリル・ゴリシェフ、

eコマースデザインチームリーダー