レスポンシブデザインの出現によるデザインの進化

こんにちは、こんにちは！



当社が最初の適応型ウェブサイトを立ち上げてから約2年が経過しました。これは一般にロシアでこの問題とほぼ同量です。 その瞬間から、デザイナーとして、私はすでに多くの熊手を歩くことができたので、最初の投稿で、アダプティブの出現とともにサイト設計プロセスの変更点について私の考えを共有したいと思います。



設計プロセス全体を詳細に説明することはしません。この問題に関するHabréの記事は十分ありますが、いくつかの点にのみ焦点を当てます。



したがって、一般的な形式の平均的な設計プロセスは次のようになります。

1. 簡単な学習とビジネスタスク
2. 仮説の定義、定式化/目標の設定
3. KPIを定義する
4. 指標を達成する/達成しない条件を決定します
5. 研究用のセグメントを定義する
6. 結果を見て分析し、設計課題を作成します
7. パラグラフ6の結果に従って、キャラクターとインタラクションのシナリオを決定します
8. サイト構造を作成し、関係を決定します
9. コンテンツをデザインします
10. コンテンツを作成する（必要な場合）
11. プロトタイピング
12. テスト（必要な場合）
13. 文書要件

以下に、適応設計がもたらすプロセスにいくつかの基本的な進化的追加を示しました。

適応性の境界の選択

2年前、新しいものはすべてそうであるように、クライアントは、費用と利点の誤解のために、自宅での適応性の実装に非常に警戒していたと言わなければなりません。 現在、当社の新しいプロジェクトの80％の適応性は、今後の必須要件の1つです。 同時に、クライアントはまだ適応性の限界についてあまり心配していないか、クライアントによって境界が誤って決定されている場合があります。



例1：クライアントは（統計に基づいて）自分のサイトにモバイルユーザーがいることを知っていますが、その動作に関する情報は持っていません。

例2：モバイルユーザーは、ポータルのニュースよりも記事を好むようです。 この研究の結果は、クライアントには本当に見えたが、実際にはすべてが正反対だったことを示しました。



どのような結論が導き出されますか？ 適応性の境界の選択、すなわち：

• サイトが適応する許可。
• サイト上の正確に何を必ずしも適合させる必要があり、何を適合させないか。
• どのデバイスに注意する必要がありますか。低予算のデバイス、タッチインターフェイスのない携帯電話、網膜スクリーンのあるデバイスを検討する必要があるかどうか。

したがって、最初からfireを壊さないようにするには、クライアントに耳を傾け、よく知られているツール（Google Analytics、Yandex.Metrica）を使用して、測定されたパラメーターに関するすべての仮説を確認する必要があります。



クライアントにサイトがまったくなかった場合はどうなりますか？ プロトタイプテストを使用して従来の設計のフルサイクルを実行し、アクセス可能な方法で環境、競合他社、対象ユーザーを分析し、プロジェクトのリリース後にすべてが正しいことを確認する必要があります。 良いインターフェースは、ご存じのとおり、プロセスです。 すぐに完璧に。



アナリティクスを使用すると、実際のユーザーグループ、主要なタスク、および合成の発明なしの相互作用シナリオに関する情報も得られます。 しかし、これは一般的にすべてのサイトに適用されます。

コンテンツ変換

最も困難で全体的な作業段階の1つ。 実際には、このすべての適応が必要な段階です。 激しい議論の対象は、異なるデバイス向けに設計されたサイトのバージョン間を移行するときにコンテンツをどう処理するかです。



コンテンツを操作するための主な機能：

構造的に変換する

ブラウザウィンドウの作業領域が減少するにつれて、フォント、テーブルの調整、文字列に公開する画像の数の変更などを行います。 これは、コンテンツを操作するための基本的なルールです。

コンテンツを非表示/非表示

分析および/またはコンパイルされたユーザーシナリオに基づいた二次的なコンテンツ、アクション（クリック、スクロール）などの背後に隠れているコンテンツ。

優先度を変更

モバイルユーザーが最初に何かを発言したり表示したりすることがより重要な場合は、コンテンツの優先度を変更できます。 たとえば、オンラインストアの場合、他の品揃えよりもモバイルユーザーに関心のある製品のグループを区別することは、しばしば非常に明確に可能です。

削除する

通常のモバイルサイトでは、完全なバージョンに切り替える機能を維持しながら、ユーザーにコンテンツの切り捨てられたバージョンを表示するという事実に慣れています。 サイトのバージョンは1つであるため、レスポンシブデザインはそのような機会を奪います。 今すぐコンテンツを削除できますか？



このための前提条件から始めます-モバイルデバイスを使用するシナリオは、デスクトップデバイスを使用するシナリオとは異なるという意見があります。 モバイルオーディエンスには独自の特定のタスクがあり、結果指向です。 ユーザーはモバイルプラットフォームを断続的かつランダムにサーフィンします。 そうですか？ そして、今日のモバイル機器とは何ですか？



移植性の現在のレベルとモバイル視聴者の境界を曖昧にすることを考えると、これら2つの質問に対する答えは次のとおりです：主なユーザータスクを形成するために、プラットフォームだけでなく、状況、条件、現在のニーズ、すなわち 使用のコンテキスト。 ユーザーデバイスの小さな画面は、限られたニーズを意味するのではなく、まったく意味を持ちません。

したがって、多くの場合、対象者を区別することは困難ですが、タスクと動作の違いが明白で重要な場合もあります。



したがって、ユーザーにすべてのコンテンツを表示したり、ディスカッションでよく見られるように、実際のユーザータスクに基づいて「本のいくつかの章」だけが必要です。 そしてそれらを発明し、同様の主題の他のサイトの経験を再考することは非常に危険です。 したがって、単純なルールがあります。不明な場合は削除しないでください。 信頼できるデータがある場合、または必要なオーディエンスセグメントからコンテンツが不要であることを確認できる場合にのみ、コンテンツを削除できます。 検証ツールとして、すべて同じWeb分析サービス。

感覚で変身

ここから楽しみが始まります。 モバイルオーディエンスのタスクが「デスクトップ」のタスクと一致する場合でも、セマンティック最適化などのコンテンツを準備する必要がないという意味ではありません。 モバイルからサイトにアクセスする場合、それは別のサイトになり、すべてのユーザーが答えを求めてマーケティングテキストのページの「ヒープ」間を移動するのが楽しいとは限りません。

何してるの？ 同じ形式のデスクトップバージョンのすべてのコンテンツをモバイルセクターに移動することはできません。 この最適化の目的は、公開されたボリュームを減らし、コンテンツの消費速度を上げることだけです。



これは必ずしも必要なわけではなく、次の用途には絶対に適していません。

• 情報が頻繁に追加および更新される動的コンテンツ（ニュース、定期刊行物）。既成のテキストを扱う機会はありません。 この場合、形式に従って変換を実行します。
• Statics。変更なしですべてのバージョンに移行する必要があります（連絡先など）。

視覚的な表現のために、コンテンツテーブルのコンテキストで変換を作成します。

そして、適応の前は何でしたか？

すべてが少しシンプルに見え、コンテンツの構造と関係、コンテンツタイプ、コンテンツフォーマット、属性構成要件、および主要なコンテンツ特性を備えたより詳細なコンテンツテーブルなど、高レベルの要件を修正することで構成されていました。

設計方法の選択

アダプティブサイトを開発する際、さまざまなデバイス（異なるビューポート、パフォーマンス、インターフェイス）に関連する多くの不確実性に直面しています。 当然、デバイスからの十分な抽象化がなければ、サイトを設計することはまったく不可能になります。

そして、ここでは、適応が私たちの助けになる前であっても、開発方法が広く普及しています。

• 優雅な劣化;
• 純粋にWebベースのProgressive Enhancement。
• そして、すでに適応性に直接関係する、Mobile Firstの哲学。

これらはすべて、インターフェイスがデバイスに依存せず、指定されたレベルのフォールトトレランスを提供するのに役立ちます。



基本的に、これらは開発で直接使用されるため、これらの方法が設計の組織にどのように影響するかという問題について簡単に説明したいと思います。

Graceful Degradationでは、サイトの最も機能的なバージョンで設計を開始し、逆に、Progressive Enhancementでは、最も非機能的でシンプルな設計を開始します。 原則として、これは、グレースフルデグラデーションではデスクトップバージョンから開始し、プログレッシブエンハンスメントではモバイルバージョンから開始することを意味しますが、必ずしもそうではありません。 また、Mobile Firstでは、モバイルデバイスのみで開始することをお勧めしますが、一般的にはProgressive Enhancementに適しています。



どのアプローチを選択しますか？

私自身は、次の選択基準を決定しました。

プログレッシブエンハンスメント/モバイルファーストは、設計の開始時にすべての機能要件がすでに整っている場合に適しています。 原則として、このカテゴリに分類されます：内部（すべてが既に100,500回議論され、概要が示され、事前に記録されています）およびプロモーションプロジェクト（深刻で複雑な機能はありません）。 したがって、モバイルバージョン（Mobile First）のプロトタイピングから始めて、機能を徐々に増やしていくことを妨げるものはありません。



ほとんどのクライアントプロジェクトで一般的であるように、プロトタイプが要件を抽出および承認する要素である場合、グレースフルデグラデーションから開始する必要があります。

つまり、プロトタイプを作成するときに要件を処理する場合、最も機能的なインターフェイス状態を例として使用して要件を処理する必要があります。 レスポンシブデザインのコンテキストでは、これは最大画面サイズのバージョンではない場合がありますが、このインターフェイスの他の状態が機能を超えてはならないバージョンである必要があります。 これにより、機能要件（次の図のように要件の1つが明らかでない可能性があることが示されている）を失うことがなく、プロジェクト全体とクライアントの両方について明確に理解できます。



その後、適応ラダーを下に、場合によっては上下に移動できます。

試作方法

現在、市場には多数のデバイスがあります。 許可は少なからずあります（同僚がここで適切なリストを収集しました ）。 レスポンシブサイトは、アクセス許可の対象範囲全体にわたって継続的に表示される必要があります。 これらの目的のために、インターフェイスのブレークポイントまたは境界状態の概念があります。 もちろん、その数は、目的の範囲で可能なすべての解像度よりもはるかに少ないです。



これらのポイントを選択するには、3つのアプローチがあります。

• 解像度の境界に基づく選択（通常は、従来の320、480、768、1024、1280px ...）。 これは、Web分析の結果に基づいて調整できます。
• 選択は、古典的な許可が隣接するブレークポイント間の間隔内にあるという事実に基づいています。 したがって、インターフェイスの最もストレスの多い状態は、一般的なデバイスのアクセス許可に該当しません。
• 3番目の方法-デザインがUXを破壊または劣化させ始める場所での任意のブレークポイントの選択。

3番目の方法は、一般にデバイスから抽象化され、設計者が好むため、柔軟で正しいものですが、人件費の観点からはまったく予測できません。 固定値プロジェクトでは、使用するのは困難です。



最初の2つは、透明性があり、追加の不確実性を生じさせず、プロジェクトの人件費の初期評価で考慮できるため、設計者や管理者にとって便利です。



プロトタイピングのプロセスに加えて、適応法の設計を追加しています。 インターフェイスの適応は、論理的に、自然に、できるだけ均一に行われる必要があります。 異なるセクションの同じタイプの要素とブロック（テーブル、リストなど）には、最小限の十分な可変性が必要です。 同じパターンを使用するよう努力することをお勧めします。 これは、コンテンツおよび機能ブロックにも適用されます。 彼らの例はここにあります 。



また、アダプティブインターフェイスを設計するときに忘れてはならないことについて、いくつかの言葉を紹介します。

• 機能を簡素化して最適化することを恐れる必要はありません。
• 認識以上にサイトを変更する必要はありません。 これは適応法の問題です。
• サイトがユーザーデータで機能する場合、サイトのどの状態でも部分的または完全にアクセスできない場合がありますが、この状態に応じて、プレゼンテーション/入力の形式を変更することはできません（フォームを簡略化できますが、異なるバージョンで誕生日を要求することはできません）別の形式で）。
• 機能要素を配置するために、折り線（ブラウザーに表示されるサイトの下側の境界線）を使用しないでください。 曲げ点が異なるデバイスに対して規則的ではないことは明らかですが、一般的に、スライダーや他の同様の要素を配置すべきではない危険な間隔を決定できます。
• 画面の広い領域をスクロールするページと方向が一致する内部ナビゲーションを備えたGoogleマップやその他の要素を配置しないでください。これにより、ページのスクロールが困難になる可能性があります。 モバイルユーザーは、ネイティブマップアプリケーションにリダイレクトできます。
• 多くの場合、モバイルバージョンのメインページは、できるだけ早くユーザーをランディングページにリダイレクトするために広げる必要があります。
• 可能な限り適切なネイティブインターフェイス要素を使用します。
• タッチをサポートしていないデバイスから、サポートされているデバイスへの移行の瞬間を監視する必要があります。 これは、たとえば、マウスオンの代替を迅速に提供するために必要です。 同時に、市場にはタッチスクリーンを備えたラップトップが十分にあるため、画面サイズが決定的になるべきではないことを理解する必要があります。
• スクロールは定期的な情報（ニュース、記事）にのみ使用してください。 作業の速度を最適化するには、そのようなコンテンツの再読み込みに頼る必要があります。 そして、このブロックの下に、重要な要素を配置しないでください。当然、ユーザーはそれらにアクセスできません。

作業結果

適応性はページとコンテンツの構造の動的な変化に関連しているため、次の問題が発生します。最終的な結果はどのような形で提示されるべきですか？ 次の2つのオプションがあります。

• 静的レイアウト。 明らかなマイナスのうち、レイアウトの数が4倍以上増加しました（30ありましたが、120以上になりました）。 暗黙的-適応パターンは必ずしも明白ではないため、デザイナーが後でニュースの行き先を尋ねないように、明確化のためにメタデータを使用するのを怠る必要はありません。 利点-作成の速度と変更の容易さ。 多くの人が変更の単純さに関して疑問を持っているかもしれませんが、一般的に、マスターパネルのおかげで、これは迅速に行うことができます。
  
  
  
  
  
  
  
  
• インタラクティブなプロトタイプ（ 例 ）。 ここでは、ソフトウェア自体の機能を設計に使用するか（Axureを使用しますが、これはすべてではありません）、利用可能なフレームワークを使用します。 明らかなプラスは、適応メカニズムと部分的な機能を完全に示す機能です。 マイナスの-複雑さと変更の複雑さ。 もう1つ不足していることを以下に説明します。

インタラクティブなプロトタイプを使用する傾向があるにもかかわらず、積極的にテストする必要がない場合は、結果なしで静的を使用できます。

クライアントと交渉する方法

段階的に調整し、1つのバージョンのみを表示する必要があります（GDを使用する場合は、最も機能的です）。 承認されたら、次の開発に進みます。 これにより、クライアント側でプロトタイプが変更された場合、1つではなく4つ以上のレイアウトを変更する必要があります。

実際には、最も理解しやすいwin-winオプションは、静的レイアウトを調整することです。 それらは理解しやすく、修正が容易ですが、適応の仕組みとそれに関連するインタラクティブなプロセスは、多くの場合、クライアントにとって無関心です。 部分的にレイアウトを提供することは、クライアントにとってそれほど疲れませんが、すべての承認に対して彼の注意が十分ではない傾向がまだあります。



より複雑なオプションは、インタラクティブなプロトタイプです。 ただし、知らないうちにすべてを調整するわけではありません。 その理由は単純です。移動/インタラクティブ要素の出現、明確な固定位置の欠如により、見えないものを見逃す可能性がはるかに高くなります。

結論として

アダプティブはデザイナーに十分な追加作業を投げかけ、私の計算によると約2.5倍に増やし、追加のリソースを要求し、フロントエンドとテスターに​​非常にフレンドリーにしました。 ちなみに、彼らは最も多く得ましたが、これは別の記事のトピックです。

いくつかの側面の詳細に興味がある場合、またはレスポンシブサイトの設計にご自身の経験がある場合は、ぜひコメントでお話しください。