機能を個別のアプリに分割するのが適切なのはいつですか？
私はデザイナーですが、会社には2つの異なるタイプのユーザーにサービスを提供する単一のアプリがあります。
1つのグループは一般ユーザーで、アプリを使用して大きなイベントをナビゲートします（例：年次ユーザーグループ会議セッション、出展者、他の参加者とのつながり）。
2番目のグループはスタッフです。主に一般ユーザーが作成したプロファイルにアクセスします。たとえば、詳細を追加できます。彼らとの会話についてのメモ。
私たちはより多くの「スタッフ」機能を提供するように求められました。アプリはかなり大きくなっています。アプリは「深すぎる」べきではないと聞いたことを覚えています（おそらく2年前にNNGコースで考えています）...ドリルダウンの悪夢は回避できると思いますが、フットプリントがどれほど大きくなるか心配です。
個別のアプリを作成する場合と、多くの機能を1つにまとめる場合の経験則はありますか？および/または誰かが私をリソースに向けることができますか？
2つの異なるアプリがある場合、（どちらかのアプリ）のユーザーが他のアプリに切り替える必要がある頻度はどれですか？
答えがneverの場合、2つの異なるアプリが有利です。それぞれのアプリは、対象ユーザーに合わせて調整できるためです。答えがめったにない場合は、ユーザーがアプリを切り替えるコストを考慮する必要があります。答えが頻繁にである場合は、おそらく単一のアプリを持っていることが最善です。
私たちの会社は今逆のことをしようとしています...複数のアプリがあり、同じユーザーのセットがほとんどの機能にアクセスする可能性が高いため、すべてを1つに統合した方がよいことに気付きました。いくつかのアプリを管理する意味はありません。
私の提案は、2つのユーザータイプに基づいて使用状況を評価することです。スタッフがアプリの一般公開側にアクセスする必要がある頻度はどれくらいですか？どのようなコンテキストでアクセスする必要がありますか？
単一のタスクフローの場合、スタッフは両方の領域にアクセスする必要があります...または、頻繁に両方にアクセスする場合は、一緒に保持することでアプリの切り替えの摩擦を軽減できます。
スタッフが必要とするものが非常に明確で分離されていて、一般の人々が使用するものである場合は、必ずそれらを分割してください。
私が作業している現在の考えは、個別のアプリがより簡単に維持され、（ユーザーベースと利用可能な機能の点で）より適切に拡張できるということです。私たちが提供するすべてのサービスが1つのアプリで提供される場合、小さな更新でさえ大きなリスクを伴います。このアプリ数の多いアプローチにより、1つのサービスを更新したり、別のプラットフォームに移動したりしながら、他のサービスには触れないようにすることができます。
もちろん、いくつかの要件があります。アプリAの一部の機能をアプリBに提供する必要がある場合があります。その場合は、機能を複製せずにアプリ間で共有して、単一のコードベースを再利用できるように、何らかのフレームワークが必要になります。それらがWebアプリである場合、1つのアプリから別のアプリへのシームレスな切り替えを可能にする何かを用意する必要があります。例えば。中央のユーザープロファイル/認証サービス（ここではStackExchangeで使用しているような）を使用できます。
いつ分割するかは難しい質問ですが、レシピを知っているかどうかはわかりません。状況のように、特定のユースケースに必要な機能が、適切な分割を簡単に定義できるようになる点まで逸脱する場合があります。いくつかの例：メールクライアントやWebブラウザーにRSSリーダーは必要ありません（以前はMSがそうであったと考えていました）、テキストエディターにマークアップは必要ありません、私の中に複数ページのレイアウトは必要ありませんPhotoshop。
アプリを無駄のない状態に保ちますが、提供するワークフローが1つのアプリケーションで完了できること、または論理的な分割を行い、いくつかの統合機能（たとえば、IndesignドキュメントにPhotoshopファイルを「配置」）でそれをサポートすることを確認してください。
アプリの最初でユーザーを2つのグループにまとめることができる場合、ユーザーは起動時に「スタッフ」/「非スタッフ」オプションを選択し、基本的に、単一の深い階層ではなく2つのパスを作成します。
一般ユーザーとスタッフユーザーの両方に同様の量の機能を追加できますが、それらは並列であるため、階層の深さは半分になります。スタッフのユーザーにとっては、彼にとって有用ではない一般的な機能は見られず、その逆も同様です。