私は、特にモバイルデバイス向けの情報アーキテクチャ手法について、Web上で例を見つけようとしています。モバイル/デスクトップツールのIAを取得する手順は、カードの並べ替え、ペルソナ、ユーザープロファイル、アフィニティダイアグラム、サイトマップなどであることを理解していますが、私が本当に興味を持っているのは、マルチを作成する際に設計者が留意すべき違いです。プラットフォームアプリケーション。言い換えると、私のアプリケーションがデスクトップ、モバイル、タブレットで動作する場合、IAが留意すべき点は何ですか?
モバイル用のIAを探索および作成するコアメソッドは、デスクトッププロジェクトと同じです。 AI自体(コンテンツとその配置)は異なりますが、これは主に(非常に)画面サイズが小さいためです。
シンプルで小さいコンテンツ- Research ユーザーはモバイルで読むことと理解することを少なくしていることを示しています。つまり、デスクトップサイトの長く複雑なコンテンツを書き換えて、短くてわかりやすくする必要があります。これは、セカンダリコンテンツ(つまり、ユーザーの現在の画面にとって絶対に重要ではないもの) 異なる必要があります より低いレベルの画面に移動することも意味します。
シンプルなナビゲーションメニュー-メニューにあまり多くのオプションを含めることはできません。タブ付きメニューには通常、最大5つのタブが含まれます(例: foursquareのネイティブアプリ )。 MSNBCのモバイルサイト 「more」を使用してサイトを上にスクロールし、21のセクションと検索フィールドがあるナビゲーション領域を表示します。
ここで私が書いたすべての良い例は、ギャップのWebサイト デスクトップ上 および モバイル上 です。
他のUXプロジェクトと同様に、ユーザー調査とユーザビリティテストは非常に効果的です。
私が知っているモバイル固有のテクニックはありません。ただし、モバイルアプリケーションのUIの選択には、多くの制約があります。
ネットワークの使用が制限されています。常時ネットワークアクセスを使用しないでください。ネットワークの使用量は、明示的(ユーザーアクションが要求される)または非常に小さい(新しいメールヘッダーをチェックする)必要があります。常時ネットワークアクセスに依存することはできません。また、ネットワーク接続がない場合、アプリケーションは静かに静かに失敗するはずです。
画面スペースが制限されています。ユースケースをユーザーにとって最も一般的で便利なものに絞り込みます。これらの使用例を実現するために必要な最小限のUIを定義します。次に、リストをさらに切り詰めます。おそらく、まだ十分に単純化していないためです。大きなフォントは、多くの画面の非常に小さなポイントサイズを補います。また、柔軟なレイアウトにより、複数のデバイスであらゆる方向に最適なレイアウトを提供できます。
あなたの記憶は制限されています。データセットをRAM=にロードすることはオプションではない場合があります。モバイルデバイスではこれらの選択が本当に重要であるため、データ効率の高いアルゴリズムとプロセッサ効率の良いアルゴリズムの間で行う選択に注意してください。
ランタイムが制約されています。アプリはいつでも停止される場合があります。バッテリーはいつでも死ぬ可能性があります。タスクの途中であっても、データを矛盾した状態にしないでください。通話やユーザーの気まぐれにより、いつでもバックグラウンドに投げ込むことができます。
ストレージが制限されています。ストレージは、モバイルデバイスではギガバイトではなくメガバイトで測定されます。アプリケーションのフットプリントを可能な限り削減します。フラットアイコンフェチの1つの利点は、グラフィックの圧縮性が大幅に向上することです。
入力が制限されています。タッチインターフェイスは不正確で、タイピングは面倒です。どうしても必要な場合を除いて、ユーザーにエッセイを書かせないでください。クリックターゲットに正確に到達するとは期待しないでください。もちろん、これは、画面のデザインとレイアウトの方法に関する上記の表示制約と関連しています。
そしてもちろん、CPUには制約があります。上記のように、アルゴリズムの効率に注意してください。必要に応じて、重い処理タスクをクラウドにオフロードします(「ネットワークが使用できないときに正常に失敗する」という警告)。ビジネスでは、時間=お金。モバイルでは、cpu =バッテリー。目に見えて直接的にユーザーに利益をもたらさない不要なCPUの使用を避けます。プラットフォームを理解し、利用可能なAPIを使用して、ホイールの再発明を回避するように努力してください。組み込み関数は、ほとんどの場合、独自の関数を実行するよりもパフォーマンスが高く、効率的です。
モバイル空間向けの設計とは、制約を認識し、それらの制約を念頭に置いてアプリケーションを設計することです。デフォルトにgoodを設定すると、ユーザーは大量の設定をいじる必要がなくなります。ユーザーインターフェイスを作成します予想ユーザーのニーズを満たし、最も一般的なユースケースで必要なアクションは最小限です。画面に10個を超えるボタンがある場合は、おそらく何かがおかしいでしょう。複雑さを制限します。
お役に立てば幸いです。
私が考慮できるIAの主な影響は2つあります(純粋に技術的なもの以外)。
「マクロ情報アーキテクチャ」(つまり、有益なドメインの構造)と「micro情報アーキテクチャ」、つまり、ページ上で情報を表現する方法(または、モバイルについて、ビューで説明する方法)。
モバイル用のマイクロ情報アーキテクチャがデスクトップ用のものとはどういうわけか異なるはずであることは間違いありません。レスポンシブデザインのアプローチは、レイアウトをクライアント側に適合させる試みであり、これは多くの場合許容できるソリューションです。ただし、アドホックビューの設計が望ましい状況もあります(モバイルおよびネイティブアプローチ)。
一方、マクロ情報アーキテクチャに関しては、デスクトップからモバイルに変更する必要があることはそれほど明白ではありません。一部のプレーヤーが問題にどのように対処したかを確認するために短いベンチマークを作成したところ、一部のプレーヤー(たとえば、BBC、ニューヨークタイムズ)が単純化する傾向があることを発見しました情報階層の構造を平坦化しますが、他の(Amazon、Ebay)はその深さをpreserveにする傾向があります。
個人的には、マクロアーキテクチャはユーザーのメンタルモデルに基づくべきであると想定しているため、後者の解決策に同意する傾向があります。ほとんどデバイスに依存しない:モバイルアプリのカードの並べ替えの結果がデスクトップサイトのそれと異なる場合、私は非常に驚きます。
ただし、マクロIAの構造が非常に複雑な場合、設計者はユーザーにそれを表すように細心の注意を払って、トラフ階層をナビゲートできるようにする必要があります。 、フィルター、並べ替え、ファセット、横方向のナビゲーションなど。そして、ナビゲーションパターンはデバイスに適合させる必要があります。
これはOPが最初に要求したものだと思います。
http://www.uxbooth.com/articles/designing-for-mobile-part-1-information-architecture/
グラフィックなしの抜粋:
モバイル情報アーキテクチャ
モバイルデバイスにも、独自の情報アーキテクチャパターンのセットがあります。レスポンシブサイトの構造は、より「標準的な」パターンに従う場合がありますが、たとえば、ネイティブアプリは、多くの場合、タブベースのナビゲーション構造を採用しています。繰り返しますが、モバイルサイトやアプリケーションを設計するための「正しい」方法はありません。代わりに、最も一般的なパターンのいくつかを見てみましょう:階層、ハブ&スポーク、ネストされた人形、タブ付きビュー、ベントボックス、フィルター付きビュー:
階層
階層パターンは、インデックスページと一連のサブページを持つ標準のサイト構造です。レスポンシブサイトを設計している場合、これに制限される可能性がありますが、追加のパターンを導入すると、モバイル向けのエクスペリエンスを調整できるようになります。
Luke Wroblewskiのモバイルファーストアプローチは、重要な要素、つまり優れたユーザーエクスペリエンスの作成に役立つ機能とユーザージャーニーに最初に集中するのに役立ちます。
良い
デスクトップサイトの構造に従う必要がある複雑なサイト構造を整理する。
気をつける
ナビゲーション。多面的なナビゲーション構造は、小さな画面を使用する人々に問題を提示する可能性があります。
ハブ&スポーク
ハブアンドスポークパターンは、ユーザーがそこからナビゲートする中心的なインデックスを提供します。これはAppleのiPhoneのデフォルトのパターンです。ユーザーはスポーク間を移動できませんが、代わりにハブに戻る必要があります。これは、ワークフローが制限されているデスクトップで一般的に使用されていました(通常、フォームや購入プロセスなどの技術的な制限が原因です)。これは、ユーザーが1つのタスクとフォームに集中しているため、モバイル環境でより一般的になっていますデバイスの要素により、グローバルナビゲーションが使いにくくなります。
良い
それぞれが異なる内部ナビゲーションと目的を持つ多機能ツール。
気をつける
マルチタスクをしたいユーザー。
入れ子人形
ネストされた人形のパターンは、直線的な方法でユーザーをより詳細なコンテンツに導きます。ユーザーが困難な状況にある場合、これは素早く簡単なナビゲーション方法です。また、ユーザーはコンテンツの構造のどこにいるのかを、前に進んでから後ろに戻るという感覚でユーザーに強く感じさせます。
良い
単一または密接に関連するトピックを含むアプリまたはサイト。これは、標準の階層パターンやハブアンドスポークなど、他の親パターン内のサブセクションパターンとしても使用できます。
気をつける
ユーザーはセクション間をすばやく切り替えることができないため、コンテンツの探索の障壁ではなく、これが適切かどうかを検討してください。
タブ付きビュー
これは、通常のアプリユーザーがよく知っているパターンです。これは、ツールバーメニューで結合されたセクションのコレクションです。これにより、ユーザーはアプリを最初に開いたときに、アプリの全機能をすばやくスキャンして理解できます。
良い
同様のテーマのツールベースのアプリ。マルチタスク。
気をつける
複雑。このパターンは、非常に単純なコンテンツ構造に最適です。
弁当箱/ダッシュボード
お弁当やダッシュボードのパターンは、コンポーネントを使用して関連するツールやコンテンツの一部を表示することにより、より詳細なコンテンツを直接インデックス画面に表示します。このパターンは複雑であるため、モバイルよりもタブレットに適しています。ユーザーが一目で主要な情報を理解できるため、非常に強力ですが、明確に提示された情報を備えた適切に設計されたインターフェースに大きく依存しています。
良い
同様のテーマを持つ多機能ツールとコンテンツベースのタブレットアプリ。
気をつける
タブレット画面は、このパターンをうまく利用するためのより多くのスペースを提供しますが、ユーザーが各コンテンツとどのようにやり取りするかを理解して、アプリを簡単、効率的、そして楽しく使用できるようにすることが特に重要になります。
フィルタービュー
最後に、フィルターされたビューパターンでは、フィルターオプションを選択して別のビューを作成することにより、一連のデータ内を移動できます。フィルタリングとファセット検索メソッドの使用は、ユーザーが自分に合った方法でコンテンツを探索できるようにする優れた方法です。
良い
記事、画像、動画など、大量のコンテンツを含むアプリやサイト。マガジンスタイルのアプリやサイト、または別のナビゲーションパターン内のサブパターンとして使用できます。
気をつける
モバイル。フィルターとファセット検索は、複雑であるため、小さな画面に表示するのが難しい場合があります。
私はおそらくこれを非常に不十分に説明します。
すでにここにある提案は別として。モバイルはよりパーソナルなデバイスです。ユーザーはほぼ独占的にデバイスにアクセスし、ビューを変更するので、より個人的に重要になります。
つまり、あなたのウェブサイトは、ユーザーにとって個人的な領域を持つ大きなウェブサイトを持っているように見えるかもしれません。モバイルは、そのビューを提供するWebサイトで個人的なビューを持っていると考えられます。この良い例はebayだと思います。サイトを見てください。それはあなたが何でも買うことができる大きな「ショッピングモール」で、これの小さなエリアがあなたのためです。アプリを見ると、それはすべてあなたの周りに設計されており、あなたが最後にやったことと、最後に中断したところから始めたいという例外があります。その小さなエリアに焦点を当て、「ショッピングモール」へのアクセスを提供します。
補足として、これは潜在的にレスポンシブデザインがメディアの変更をうまく処理しない場所です。 UIは向上しますが、必ずしもユーザーエクスペリエンスは向上しません。
まず、IAを定義する必要があります。情報アーキテクチャ、またはユーザーエクスペリエンス全般について具体的に質問しますか?
IAは少しあいまいな用語です。サイトマップとコンテンツマトリックスを参照するために使用する人もいます。他のユーザーは、ユーザーエクスペリエンスの同義語としてそれを使用します。
コンテンツ構造の観点から見ると、モバイル上にいることとデスクトップ上にいることとの間に大きな違いはありません。もう少し細かく分類することもできますが、ユーザーの目標はかなり重複することがよくあります。
UX全体を話していたら、Myrddinの答えは適切です。
レイアウトに関する他の回答に加えて、モバイルユーザーが採用している検索/ブラウズ戦略を検討することをお勧めします。他のユーザーが特定のアイテムを探しているのに対して、一部のユーザーは偶然にアイテムを偶然見つけました。 IAは、ユーザーが両方のモードを柔軟に切り替えられるようにすることで、ユーザーの行動範囲の両端を考慮する必要があります。たとえば、ブラウズ画面では、「ピン」機能を使用して、ユーザーが後で最も頻繁に購入したリストからすばやく見つけることができるアイテムを保存できます。