アプリケーションの整合性を考慮して設計するか、OSの慣例に従ってください？
クロスチャネリングの新しい世界で使用するアプリケーションを設計するときは、さまざまな要因を考慮する必要があります。アプリが使用されている環境に対処する必要があるだけではありません。デスクトップアプリケーションはユーザー中心のモードでよく使用されますが、モバイルアプリケーションは動きのある短い時間枠で使用され、一貫性のないモードでタスクを実行する可能性があります。
デスクトップアプリとモバイルアプリの動作とデザインは一貫しているべきだと考えるのは簡単です。アプリケーション中心の設計であればあるほど、ユーザーが自分の道を見つけてアクションを実行するのが簡単になります。
外を見ると、その逆です。 Apple、Windows、Linuxコンピューターでデスクトップアプリを使用する場合は、各OSの規則に従う必要があります。同じことは、AndroidアプリがiOSアプリと異なるなど）のモバイルデバイスにも当てはまります。
私は、後者の方法について、OSの慣習に従うことが常に正しいことを常に説明してきました（ゲームを除く）。昨日のこのコメントのように：
「...私の本では、統一デザインはアプリ中心であり、デバイスでの慣習を破っています。代わりに、ユーザー中心のデザインが進むべき道です。ユーザーはデバイスを知っていますが、アプリは知りません。だからこそ、Snapchatを学ぶのはとても難しいのです。」
それを投稿すると、私は考えました。これが間違っているとどうなりますか？アプリケーションの一貫性はOSの慣習よりも優先されますか？
あなたがそうであるように、私は一般的にOSの一貫性に傾いているでしょう。しかし、ここにトレードオフを明らかにするのに役立ついくつかの質問があります。
ユーザーが複数のプラットフォームからアプリにアクセスすることをどれくらいの頻度で期待しますか？モバイル版とデスクトップ版を使用している異なるオーディエンスがいる場合、それらのバージョン間の一貫性はそれほど重要ではありません。
アプリとのやり取りはどの程度専門的ですか？フォームへの入力やメニューからのアイテムの選択など、OS標準のアクションが主に関係している場合、ユーザーはOSの規則に従うことでより多くのメリットを得られます。ユーザーが実行するアクションがアプリに特化している場合、OSはコンテキストキューを少なくし、アプリとの他のやり取りから知識を利用する可能性が高くなります。
ユーザーはデスクトップ版とモバイル版を同じタスクに使用していますか？もしそうなら、クロスプラットフォームの一貫性のためのケースの多くがあります。最も一般的なアクティビティがプラットフォーム間で異なる場合、ユーザーはそれらが異なる場合に気づいたり気にしたりする可能性が低くなります。
プラットフォームのビジュアルデザイン規則とインタラクションデザイン規則の間には、区別すべき点があると思います。
IOS 7以降を例にとると、従来のアプリはHelvetica Neueでタイプセットされ、主に白であり、ブランド要素は比較的少ない。ボタンは通常、デフォルトでボーダレスであり、要素がクリック可能であることの合図としてアプリのデフォルトの色を使用します。
しかし、私はプラットフォーム上に非常によく設計されたアプリがあり、それらすべての慣習に反するものだと主張します。
ただし、確立されたインタラクションデザインパターンは、おそらく単一のアプリに違反すべきではありません。つまり、iOSのハンバーガーメニューを避けたり、独自のキーボードや日付ピッカーを回転させたり、アニメーションを変更して別のコンテンツ階層を示したりすることは避けてください。
間違いなく、iOSに外国の相互作用メカニズムを正常に実装したアプリがありますが（YouTubeと同様にGoogleマップもその1つです）、重要な種類のコンテンツへの排他的アクセスをオンラインで提供できるという贅沢があります。ユーザーはGoogleから得たものを回避することを余儀なくされています。それに加えて、Googleにはかなり成熟したモバイルプラットフォームとデザイン言語があるため、ほとんどのデザイナーよりも、ターゲットプラットフォームに違反して物事のやり方を強化しようとする動機があります。
私たちのプロジェクトについても同様の議論が最近行われており（これも数年前）、出てきたいくつかの質問の1つは
1）あるプラットフォーム（Windowsなど）でアプリを使用した同じユーザーが、別のプラットフォーム（MacまたはAndroidなど）で同じアプリを開くと、タスクが似たものになるため、イライラしたり混乱したりしませんか？結局のところ、Gmailアプリはすべてのプラットフォーム（iPhoneまたはAndroid）でGmailアプリのように見えるはずです。
また、OSの規則は、そのリリースに伴って変更/進化する可能性があります。アプリに他の値を追加せずに、同じアプリをそのOSのアプリのように見せるために何時間も費やす価値はありますか？
2）OSがアプリを認定するために尊重および実装する必要があるアプリのデザイン（およびルックアンドフィール）に対して禁止を課さない限り（Apple Store）、なぜOSの慣習に従うのですか？アプリは、OSのIDではなく、独自のIDである必要があります。
私たちのチームの1人のシニアメンバーが実際にこの入力をUXチームに与えました[〜＃〜]ない[〜＃〜] iPhoneアプリまたはAndroidアプリのように見えるまたはWindowsアプリ。
デバイスの相互作用に固有であり、ユーザーの視点を考慮します。私のアプローチは「ローマにいるとき（ローマ人のように行動する）」です。
ユーザーが特定のデバイスプラットフォームを使用して快適さを開発し、デバイスプラットフォームの対話規則に従うことで学習の負担が軽減されるため、このアプローチを推奨します。ユーザーは、自分のデバイスでアプリを使用するために別のプラットフォームの相互作用モデルを学ぶ必要はありません。