アプリケーションをバンドルまたは分離するUXを決定する方法
私はオープンソースプロジェクトに貢献しています。機能と範囲の問題があります。
現在、私は日常のワークフローで、かんばんボードとヒップチャットを使用していることに気付きました。したがって、カンバンボードの機能としてチャットを追加するのが目的です。
Facebookは、メッセンジャー機能と通常のFacebook機能を分離することで、サービスの分離を試みました。
マイクロソフトは最近、カレンダー、メール、クラウドサービスを1つのアプリにバンドルすることを試みました。
この質問は、アプリのスコープにアプローチし、バンドルするかどうかを決定することについてです。何を考慮する必要がありますか。ブラウザーで2つのタブを開くよりも、同じインターフェイスに2つの機能を備える方がよい状況はどれですか。
バンドリングの議論：多くのインターネットユーザーは、ブラウザーのタブ機能の使い方を知らない
すばらしい質問です。私は、販売とマーケティングの観点からは分割されているが、エクスペリエンスの観点からはより緊密に統合されている（キット全体を購入する人向けの）アプリケーションスイートに取り組んでいます。
活動の問題です
明らかに、ビューに追加された機能はすべて情報アーキテクチャを複雑にします。ただし、ユーザーがアクティビティの過程で定期的に複数の機能にアクセスする場合、それらを単一のビューに表示すると、ワークフローが単純化される場合があります。
私の最終的な基準：
それが仕事を難しくするかどうかにかかわらず、ユーザーの仕事はより簡単になるはずです。
逆に、これらの要因は、物事を分割するための良い指標です。
- ユーザーの仕事は、簡単ではありません。
- 関数は論理的に関連していません。
- バンドルすると、ワークフローやシステムパフォーマンスが低下します。
戦略的側面に対処する方法
これは、事業戦略、システムアーキテクチャのラインを横断するため、少なからず複雑なテーマです。ユーザーエクスペリエンスは非常に深い方法です。私はUXがこの質問の評価を始めるのに最適な場所だと思います（私がUXDだからというだけではありません;-)。経験が単一のビューを要求する場合でも、ビジネスは依然としてコンポーネントを明確に販売できます。また、最近ではシステムアーキテクチャが制限になることはほとんどありません。選択は、機能のユーザーエクスペリエンスに依存する必要があります。
実際、アプリケーションを作成するかどうかを決定するのと同じ原則を適用して、アプリケーションを結合するか分離するかを決定できます。
- 最初のステップは、ビジネス、テクノロジー、およびユーザーの観点から要件をリストすることです。
- 2番目のステップは、各要件に重みを割り当てることです。
- 最後のステップは、優先順位が何であるかに基づいて決定を行うことです。
したがって、たとえば、1つのアプリケーションを維持したり、各アプリケーションに特化した製品チームを作成したりするコストとメリット、およびビジネスの運営に与える影響など、多くのビジネス要件があるかもしれません。製品を競合他社とどの程度差別化したいかに影響を与える競合他社の分析があるかもしれません。
次に、アプリケーションを個別に開発するのがいかに簡単か、各アプリケーションのさまざまな機能をサポートする技術スタック、設計、開発、保守に利用できる社内または外部委託の専門知識などの技術要件があります。
もちろん、各アプリケーションのユーザー人口/人口統計に基づくものなどのユーザー要件もあり、個別の製品を作成するのに十分な違いがあるのか、それともユーザーがそれを1つのアプリケーションと見なすのかなどもあります。
80/20ルールは、意思決定プロセスに適用したり、各要件に重みを付けたりするのに適していると思います。また、3つの領域のそれぞれについて、これらの要件が時間の経過とともにどの程度変化するかを予測する必要があるため、決定を下すのは容易ではありませんが、考慮できる要素が多いほど、最適化する可能性が高くなります。決定。
最適なUX基準は、UXの観点からの製品バックログまたは機能ロードマップの分析に依存する必要があります。基本的には情報アーキテクチャの演習です。 SiebelやAutodeskなどの企業向けに、長年にわたって数多くの大規模な製品スイートに取り組んできました。最新のウェブアプリケーションでは、ユーザーの役割（役割ベースのアクセス制御）に基づいて機能を有効にする方法と、ユーザーのログイン認証情報に関連付けられているタスクまたはワークフローについて検討することが重要です。
通常、同じRBACモデルは、コードを再利用してUIの一貫性を実現し、開発コストを削減する方法で機能セットを有効にすることができます。 UXに影響を与える他の技術的な考慮事項があります。たとえば、Webアプリで個別のコードベースを作成すると、通知やダッシュボードなどの統合が難しくなる場合があります。ブラウザーのセキュリティモデルは、あるページが別のページと相互作用しないように設計されているため、2つのブラウザータブにコンテンツを配置すると問題が発生することがよくあります（ https://en.wikipedia.org/wiki/Cross-site_scripting を参照）。
実際に言うと、すべてのユーザーストーリーまたは機能をスプレッドシートの最初の列に配置し、それらが表すワークフローの分析に基づいて、それらをエピックまたはテーマにグループ化します。 （Mike Cohnは彼のサイトで叙事詩やテーマについてよく説明しています。）
エピックを別々のアプリに分割したくないのは、通常、エピックのストーリーが互いに依存しているためです。また、エピックやグループが同じ方法で同じグループに属しているか（同じアプリ）、他のグループから比較的独立しているかを考慮する必要もあります。
最後に、設計するペルソナ/ロールごとに列を作成し、ペルソナがアクセスできるストーリーをこれらの列で確認します。 http://boxesandarrows.com/integrating-ux-into-the-product-backlog/ にこれに関するブログ投稿を書きました
理想的には、チームで作業するスプリント計画セッションと同じように、壁に付箋を貼ってこの作業を開始します。後で参照するために、スプレッドシートを使用して出力をキャプチャする傾向があります。ほとんどのアジャイル計画ツールは、これをうまく実行しません。スプリントの計画、機能の開発、テストの取り組みが改善されるため、正しく行われれば、チーム全体が最終的な分析から多くのメリットを得ることができます。
アプリケーション/関数/インタラクションをバンドルまたは分離するいくつかのUXの理由を次に示します。
補完的なものをバンドルする
牛乳、ジュース、ソーダなどの液体アイテムのみを販売する食料品店と、シリアルやクラッカーなどの箱入りアイテムのみを販売する別の店に行くことを想像してみてください。これは、穀物と牛乳の朝食を購入することを非常に難しくします。多くの人がシリアルと牛乳を一緒に食べるため、シリアルと牛乳を1つの店舗にまとめることは当然のことです。
アプリケーションの1つのコンポーネントが別のコンポーネントの品質を強調または強化するのに役立つ場合は、必ずそれらをまとめてください。ユーザーは両方によく接続します。
コンテキストを提供するものをバンドルする
誰かに番号2の赤いバッジを表示すると、2人がプライベートメッセージを送信したことを知らせることができます。それらを読むために別のアプリに切り替えることは、一見平手打ちです。
ユーザーは、必要なコンテンツにアクセスするために邪魔になる必要はありません。
少数の人が使用するものを分離する
ほとんどの人が使用するものだけを表示することにより、ユーザーエクスペリエンスを向上させます。
アプリケーションに何かを追加するたびに、ユーザーの 認知的負荷 が増加します。認知摩擦の量はいくつかの要因に依存しますが、他に何もない場合、ユーザーはそれを見て、なぜそこにあるのか疑問に思う必要があります。
確かに、コンポーネントを使用する少数の人々は、コンポーネントを移動することを気に入らないかもしれませんが、個々の部分のUXを改善し、メインアプリケーションから古いバージョンを完全に削除する前にどこに行くべきかを知らせることにより、これを軽減できます。
対象ユーザーが異なるものを分離する
これの良い例は、Googleドライブアプリでユーザーがあらゆる種類のドキュメントを表示できる方法ですが、ドキュメントを編集するには別のアプリが必要です。これは良いUXです。デバイスによっては、実際に編集する必要がないため、消費されるリソースが少ないためです。すべてのドキュメントを任意のデバイスで読み取る主な機能は、まだ完全に機能しており、応答性が高くなっています。ドキュメント、スプレッドシート、またはその両方を編集するために追加のリソースを使用するデバイスを決定するのは、私の選択です。
この質問に対する本当の答えは、それはユーザーにのみ依存するため、最終的な決定を下す前に、自信を持って言ってください...
この変更により、ユーザーのほとんどの生活が楽になります。
私は最近、ユーザーの生活をできるだけ簡単にすることは悪いことだという結論に達しました。製品のばかげた証拠を作成することを唯一の目的として、プロジェクトに極端な設計、インターフェース、および開発の制限を課し、製品の目的を完全に失うことがよくあります。
それを考えると、バンドルのケースは次のようになります。バンドルする製品を簡素化しますか？それほどではありませんが、目立った（またはおそらく微妙な）影響を与えるために必要な手順の数を減らしていますか？または、意味のある方法でサービスを組み合わせて、潜在的にプロセスをより複雑にしますが、ユーザーの生活/一般的な経験を概念的に簡素化しますか？
私が取り組んだ1つの製品は、モバイル用のデジタルデイプランナーでした。それがどれほど難しいか想像できます。スケジュール、カレンダー、タスク管理、連絡先管理、メモ...すべて1つのモバイルアプリで！それは3年前のことでしたが、今日では、これらの機能を備えたほとんどのアプリは1つのことしか実行しません。ただし、それらを一緒にバンドルする強力なケースがあります。一連のタスクとメモを取り巻く多数の連絡先を含むカレンダーイベントをスケジュールすることができます。 これは毎日発生します。
私たちの課題は明確でした。紙のデイプランナーよりも使いやすく、期待されるすべての機能を備えたモバイルアプリを作成してください（デイプランナーはどこにでも持ち運べます）。スケジューリングは過剰でした。今日では、すべてのWebベースのカレンダーツールがそれを提供しますが、これは同社のセールスポイントの1つでもありました。失敗し、（顧客のフィードバック、分析、および私たち自身の分析に基づく）最大の理由は、それが多すぎるということでした。あるいは、少なくとも、ユーザーがさまざまなアプリを組み合わせて使用するのではなく、ユーザーが製品を使い続けることができるように、十分または有益なものにすることはできませんでした。
マイクロソフトが過去2年間でAcompli、Sunrise、Wunderlistを購入したのはそのためです。 Acompli（現在のOutlook）は、電子メール、連絡先、ファイルを処理し、カレンダーもサポートしています。 Sunriseはカレンダーを非常にうまく処理します。また、Wunderlistはタスク管理を非常にうまく処理します。これらはすべてOfficeスイートで動作し、それぞれが独自のアプリです。マイクロソフトがそうしているので、主要なユースケースへの焦点は明確です。カレンダーもスタンドアロンです（おそらく永遠ではありません）。タスク管理はスタンドアロンです。それらはすべて、Word、Excel、PowerPointなどの主要な生産性ツールを中心に展開しています。
では、バンドリングはバンドリングしないよりも良いのでしょうか？多くの事柄に依存しますが、最も重要なことは、それをどのように構築するか、および機能の深さに依存します。さらに、それはプラットフォームに依存します。スタンドアロンアプリが非常に強力な場合に、Slackを片思いでiPhoneのアプリに統合したくありません。しかし、誰が知っているのか、多分人々が必要/望んでいるそれのための良いケースがあるでしょう。