最初にデスクトップでのみ使用されるアプリのモバイルを設計する必要がありますか？
コールセンター業務用のCRMタイプのシステムを設計するプロジェクトに参加しています。
これを使用するのは会社のデスクトップでのみであり、モバイルやタブレットの機能はありません。
最初にモバイルを設計/スケッチしてからデスクトップビューを構築することの価値はまだありますか？それとも、存在しないユースケースの構築に時間の無駄ですか？
「モバイルファースト」の主な利点は、アプリを最も重要な機能に絞り込む必要があることです。 IAと相互作用を簡素化します。
次に、デスクトップバージョンを設計するときに、追加機能ごとに機能を追加する必要があります。デスクトップ機能を本当に含める必要があるかどうかを慎重に精査する必要があります。
したがって、実際のモバイルアプリが存在するかどうかに関係なく、「モバイルファースト」のプロセスは、より優れたデスクトップアプリになると思います。
CRMアプリケーションは通常、1つの画面にユーザーに関する多くの情報（場合によってはすべての情報/アクション）を備えた多数のダッシュボードです。 fullHD画面でブラウザを必要とするCRMアプリを使用しました
UIの場合、最初にモバイルが間違っていると思います。
しかし、すべてのバックエンドAPIは、ダッシュボードの小さな部分を（クエリ、リクエスト、変更）できるように十分に小さくモジュール化されたものに設計する必要があります。ある日、優先順位が変更された場合、同じバックエンドAPIを使用して、モバイル用の二次（小型、タッチ、マウス、キーボードなし）UIを作成できるようになります。
はい、デスクトップのみのアプリには、お気に入りのモバイルファーストデザインプロセスを使用します
「モバイル」という言葉にこだわらないでください。アプリが携帯電話やタブレットで使用されない場合でも、モバイルファーストプロセスにはまだ価値があります。
画面サイズに関する限り、これはおそらく簡単に対応できますが、ユーザーの画面でデザインが機能することを単に前提としないでください。 （ユーザーのディスプレイに関するすべてをかなり簡単に見つけることができるという利点があるため、スキップする理由はありません。）
プログレッシブエンハンスメント
モバイルファーストの方法論には、 プログレッシブ拡張 テクニックの使用が含まれます。これらは、電話ユーザーと同様に、デスクトップユーザーにも少し関連しています。 ベースシステムを特定します-つまり、サポートする必要のある最も能力の低いブラウザです。
あなたは快くまたは不愉快に驚かれるかもしれません。ユーザーが最新のブラウザーを使用している場合（またはブラウザーに要求することができる場合）、フロントエンドの開発者は強力な新しいWebテクノロジーを使用できる可能性があります。あなたの会社がまだIE 8で立ち往生している場合は、今それを見つけて、それに応じて計画する必要があります。
設計プロセスの選択
携帯電話やタブレットをサポートしないWebプロジェクトを見ると、モバイルファーストの設計プロセスを使用する場合にどうするかについて、3つの選択肢があります。
（1）プロセスをスキップします。 アドホックです
（2）デスクトップ用の新しい（合理化された）設計プロセスを発見します。
（3）他の方法で使用するのと同じモバイル優先プロセスを適用し、無関係な部分はスキップします。
イラスト
UXPinの Guide to Mobile-First Responsive Design を使用して、これがどのように行われるかを見てみましょう。
レスポンシブブレークポイント
レスポンシブなブレークポイントの分析は、デスクトップのみのサイト/アプリには関係ありませんか？ （設計ad hocの場合、これを無視する場合があります。また、デスクトップのみの設計プロセスから削除できる「モバイル」ステップのリストの一番上にある場合があります。 ）
とにかく、ユーザーが使用している解像度を分析するとどうなるでしょうか。 2016 では、一般的な解決策は次のとおりです。
それはかなり広がります-あなたが使うかもしれない追加のスクリーン全体と半分のディスプレイ。
アプリを見て、ユーザーはリスト画面と詳細画面の間で pogo-stick する必要がありますか？ 3840ピクセルは、リストビューが詳細ビューの横に表示されるのに十分な幅があるため、余分なクリックや頻繁なコンテンツの切り替えからユーザーを節約できますか？
モバイルファーストが一般的な慣行です
モバイルファーストプラクティスは非常に普及しているため、ユーザーは慣れ親しんでおり、それに慣れていないWebサイトは古く、奇妙で混乱しているように見えます。
1つの例を概説するために、UXPinのモバイルファーストデザインのステップ5を検討してください。
- ホバーを当てにしない
私の意見では、重要なものにホバーを当てにすることは、それほど素晴らしいアイデアではありませんでした。しかし、それでも、「モバイルは関係ない」サイトにいくつか追加することについて最近尋ねられました。
問題は、多くのサイトがモバイルフレンドリーにするためにサイトを削除しているため、ユーザーは以前よりもホバー行動に慣れなくなっていることです。ホバーツールチップが見つからない場合があり、ホバードロップダウンは奇妙で迷惑なようです。
車輪を再発明しないでください
お気に入りのモバイルファースト設計プロセスでは、チェックポイントは次の3つのカテゴリに分類されます。
- モバイルと同じようにデスクトップシステムに適用されるもの（コンテンツが最初など）
- モバイルファーストのデザインが一般的であるという事実によって通知されること（ホバー動作など）
- デスクトップに関係のないもの（例：タッチ動作）
3番目のカテゴリのアイテムは、「リストをチェックする」ためだけに多くの時間を浪費することはありません。お気に入りのモバイルファーストパターンを使用して、デスクトップのみのソリューションを改善してください。
Htmlとcssで記述されたほとんどのアプリでは、デスクトップに機能を追加する方が、削除するより簡単です。
アプリが最終的にモバイルアプリで機能しなければならない可能性が少しでもあれば（それに直面しよう-おそらくそうなるでしょう）、最初にモバイル向けに設計する必要があります。
ここに実用的な例があります：
今日の多くのアプリは、Bootstrap 3.のように、最初にモバイルであるインターフェースフレームワークを使用して構築されています。その特定のフレームワークには、さまざまなサイズのビューポートでアプリがどのように表示されるかを指示する特定のcssクラスがあります。
可能な最小サイズ（電話の場合はxs）から始めると、その後に続くすべての大きいサイズ（タブレットの縦向き、タブレットの横向き、さまざまなデスクトップ）よりも、何も追加することなく最小のスタイルが継承されます。
しかし、デスクトップから始めて下に向かって作業する場合は、小さいサイズに向かって作業するときに、デザインと競合するデスクトップ固有のクラスを削除する必要があります。これはすぐに悪夢に発展し、維持することになります。
したがって、デザインと技術の両方の観点から、モバイル開発はデスクトップ開発の実用的な選択肢です。
このように見たいと思うかもしれません-ほとんどのユーザーが大画面（デスクトップ）を使用してそれにアクセスすることを考えると、モバイルファーストサイドからすぐにアプローチするのはあまり意味がありません。むしろ、アプリケーションの性質を考えると、小さい画面（デバイスではない）は、ユーザーがデスクトップ上で実行できるより大きなアクションセットを補完するものと考えてください。たとえば、
1）モバイルバージョン（もちろん後で計画することもできます）では、ユーザーはアプリケーションで発生する重要なアクティビティに関するアラートや通知などを受け取ることができます。 CRMの場合、それはいくつかの主要な分析レポートなどであり、デスクトップバージョンで定義できると想定します。
2）言ったように、機能セット全体にアクセスするために使用するのではなく、小さいアプリケーションをマザーアプリケーションの補助として考えることは理にかなっています。これは、a）デスクトップ上の機能セットの設計に限定されないこと、およびb）ユーザーが要求したときにモバイルバージョンを後で計画できることの2つに役立ちます。
3）ただし、アプリケーションのレスポンシブデザインを健全に保つことができ、無視することはできません。
私はケン・モンカーンに完全に同意します。そして、その方法をサポートするBen GremillonによるUXPinの記事 モバイルファーストレスポンシブデザインの実践ガイド 。ただし、優れたUXデザイナとの違いはそれほど大きくありません。それほど大きくはありませんが、ツールの実装が適切かどうかを判断する機能です（この場合、「モバイル向けに最初に設計する」）。
あなたは言及しました：
最初にモバイルを設計/スケッチしてからデスクトップビューを構築することの価値はまだありますか？それとも、存在しないユースケースの構築に時間の無駄ですか？
時間の無駄ではありません！しかし、あなたが働いている会社が急いでいて、このステップに取り組むことは、プロジェクトの期限のために貴重な時間を費やすことがわかる場合。まあ、それはそれほど素晴らしいアイデアではないかもしれません。それが最終製品に役立つとしても。
私たちはUXデザイナーとして、可能な限り最高の製品を最終ユーザーに提供したいと考えています。そして、時々私たちは誰のために働いているのかを忘れます。設計ツール/プロセスの実装は、常に次の2つに依存します。1.利用可能な時間。そして2.プロジェクトで利用可能なリソース。
要件であり、有効なユースケースである場合は、最初にモバイルを設計することを強くお勧めします。 CRMを改良することは、かなりの状況ではなく、設計も簡単です。
以前に同様のタイプのプロジェクトに取り組んだことがあり、「desktop first」というレスポンシブデザインという用語を使用して、全体的なデザインコンセプト/方向性を構成しました。
これは、デザインがさまざまなビューポートやデバイスに対応できることを意味しますが、最初にモバイルデバイスで適切に機能することを確認する代わりに、デザインが美しく、デスクトップモニターや構成に適していることを優先します。これにより、インターフェイス全体を再設計することなく、範囲をモバイルWebサイトやデザインにまで拡張できる可能性もあります。
デスクトップマシンで実際のタスクを実行する特定のアプリケーションでも、通知、更新、またはモバイルデバイスでのダッシュボード/レポートの表示を検討することをお勧めします。これは、多くのデスクトップ向けアプリケーションの拡張になりつつあるためです。そのような可能性に応えるために害を及ぼすことはありません。少なくとも、後でそれに対応しない設計パスを下るリスクを最小限に抑えるためです。
会社のバックオフィスCRMであり、オフィスでのみ使用される場合、最初にモバイルで設計する必要はありませんがあります。それはあなたに追加の不必要なリソースを費やすだけです。
ただし、私の意見では、レスポンシブデザインを使用して、デスクトップの解像度に焦点を当てる必要があります。このようにして、システムはデスクトップ用に最適化されると同時に、モバイルデバイスでCRMを使用する場合に備えてmobile readyになります。
幸運を。
私はここでほとんど同意しません。
いいえ、モバイルファーストで設計しないでください。
いいえ、モバイルビューを実際に設計することは役に立ちません。また、ピクセル密度が高いため、特大のフォンタなどを考慮する必要もありません。
はい、優先順位の高いコンテンツを決定することは良いことです。はい、下位互換性は良好です。はい、パフォーマンスに注意してください。
しかし、これらはすべてツールと戦略です。また、テーブルと同じツールを使用してキャビネットを作成します。ただし、最初にテーブルを作成してから、それをキャビネットに変換する必要はありません。
キュレーションと最適化はどちらも常識的なアプローチです。これらはモバイルファーストのデザインに限定されるものではありません。彼らはどんな種類のまともなデザインにも不可欠です。