よい設計の原則の理解

メモ

メモ

Einstein Analytics は、Tableau CRM という新しい名称になります。機能の変更はありません。Tableau CRM は、Salesforce CRM 製品内部のネイティブ分析に最適なエクスペリエンスを提供します。これまでどおり人工知能 (AI) とビジネスインテリジェンス (BI) を組み合わせ、Einstein Discovery で引き続きプラットフォームと緊密に連携します。この更新を進めている間は、ところどころで旧名称を目にすることがあると思います。

学習の目的

この単元を完了すると、次のことができるようになります。
  • Analytics アプリケーションの設計の基本原則を理解する。
  • Analytics ダッシュボードの要素にこれらの原則がどのように反映されるか理解する。
  • アプリケーション設計プロセスの概要を理解する。

先の予測できない設計ジャーニー

今日、あなたは、DTC Electronics の Salesforce システム管理者としての業務を開始します。

新しい業務についてはほとんどわかっていませんが、設計改革のプロセスに携わることになります。シングルダッシュボードアプリケーションの初期バージョンから、設計の基本原則を利用してアプリケーションのよい点と悪い点を分けます。次に、もっと便利できちんと設計されたものを作成します。これをやり遂げるまでに、独自のアプリケーションやダッシュボード設計に応用できるプロセスの役立つ知識を得られます。また、Salesforce デザイナで改革されたダッシュボードを確認できます。

DTC 本社に着いたあなたが知っているのは、実際の業務の第 1 日目ということだけです。その前の 2 週間、オリエンテーションで準備し、前任者と会いました。そして、DTC の華々しい Salesforce 組織の担当者としての最初の月曜日です。

華々しいと言えば、前任者が開発したアプリケーションを空き時間に見せてくれました。前任者は Einstein Analytics を使用して、営業マネージャに営業担当者の活動すべての最新情報を提供するアプリケーションを作成しました。チームが軌道に沿って活動できるようにするアプリケーションということで、The Motivator という名前が付いています。前任者はまだチームにこの話をしていませんが、あなたには早めに話そうと思ったようです。

作業開始を楽しみにしながら、Analytics Studio を起動し、The Motivator を [Sales Team Activities (営業チーム活動)] ダッシュボードで開きます。今週中に営業統括責任者に見せて、幸先のよいスタートを切れるはずです。

The Motivator ダッシュボード

美しさは表面的なものではない

アプリケーションは実際のところ、多くのデータを含む 1 つのダッシュボードです。シンプルである方がより優れています。

チームの活動はタイプ別に確認できます。電話、メール、イベント、ToDo です。所有者名によって絞り込んで誰が何を完了したか確認したり、取引先別に活動を表示したりできます。また、完了および期限切れの活動の最下部で、優先度や積み上げ集計に沿って数値を確認できます。これにより、マネージャは営業担当者の活動内容を追跡し、トップパフォーマーを確認したり十分な結果を残せていないメンバーをコーチングしたりして、チームのモチベーションを維持できます。

ただし、営業チームの追跡やモチベーション維持についてどのようなことがわかっているでしょうか? 前任者は多くの Analytics Studio 機能を楽しんで活用したようです。ただし、見た目はよいものの、便利そうには思えません。活動の期間を確認できないことにすぐに気づきます。また、各営業担当者の [所有者 氏名] で活動を表示するメニューも見つけにくい状態です。各地域マネージャは担当地域の活動のみを表示できるようにしたいはずです。

営業チームメンバーを数人集めて、大至急確認します。そうしないと、業務に役立たないツールで時間を無駄にしてしまいます。

明確性、効率性、一貫性、美しさ

すでに皆さんは、設計ジャーニーの第一歩を踏み出しています。前任者が、対象にまったく合わない可能性の高いものを作成したことを確認しました。それをどのように便利にできるかという問いについて考え始めました。次は、その答えを見つけるステップに進みます。

Salesforce Analytics では、あなたとその船に乗る人々のための戦略を明文化しました。自身を設計者として考えていなくても、Analytics アプリケーションまたはダッシュボードの作成を開始すれば、設計者のように思考する必要があります。そうしなければ、チームの助けとならないものが生まれる恐れがあります。設計者視点で思考すれば、大きな枠で考えて、あなたやユーザに影響を与えながら問題を解決できます。

戦略は、以下の設計原則から始まります。

  1. 明確性。アプリケーションからあいまいさを排除します。明確性があれば、ユーザが自信を持って確認、理解、行動できます。雲の上に伸びる建物を示す明確性の原則の図。
  2. 効率性。アプリケーションの機能を通じたユーザの動作を予測し、ワークフローを合理化および最適化します。これにより、ユーザはすばやく、スマートに、よりよく作業できます。空に伸びる先の尖った塔を示す効率性の原則の図。
  3. 一貫性。同じものには共通の名前を使用し、データの共通部分や同じアプリケーションアクションは似た図の要素で示し、重要性が同じ要素は近いサイズで示します。同じソリューションを同じ問題に適用して、ユーザの知識を育み、共感を強めます。空に伸びる先の尖った塔を示す効率性の原則の図。
  4. 美しさ。よく練られて、洗練されたクラフトマンシップを忙しいユーザに提供します。ユーザの時間や関心を奪うものはほかにもたくさん存在します。夜のゴールデンゲート橋を示す美しさの原則の図。

これらの原則をまとめて適用すれば、ユーザとアプリケーション間のすべての相互作用が機能し、連携します。ユーザはストレスのない柔軟な環境を楽しみ、アプリケーションを何度も活用するようになります。

アプリケーション設計とは

設計の話を進める前に、アプリケーション設計という基本用語を定義しましょう。Analytics アプリケーションは、連携して 1 つの業務目標に従事する一連のアセットです。たとえば、Salesforce Sales Analytics アプリケーションの目的は、営業チームの各員に、Sales Cloud データのインサイトをすばやく直感的に取得する手段を提供することです。

Analytics アプリケーションアセットには、データフローと、レンズ、ダッシュボード、およびデータセットのコレクションが含まれます。詳細は、この単元の終わりの「リソース」セクションの Salesforce ヘルプと Trailhead へのリンクを参照してください。

アプリケーションの開発は、以下の基本プロセスに従います。

  1. データをデータセットに読み込み、Analytics で処理できるようにフォーマットおよび変換します。
  2. データから探索 (分析およびアクション用データ総計値を視覚化するレンズ) を作成します。
  3. データへの明確なパスを提示するダッシュボードに、一連の探索を保存します。
  4. アセットをまとめて包括的なストーリーを提示するアプリケーションに、アセットを保存します。

「リソース」セクションのリンクから、さらにアプリケーション開発の詳細を学べます。

設計とは何を指すのでしょうか? 開発プロセスの各フェーズでは、含めるデータの内容、調整方法、探索で使用するディメンションと基準などの設計の意思決定を適用する必要があります。このモジュールで説明するアプリケーション設計は、対象ユーザ、ユーザのニーズ、アプリケーションコンテンツの提供方法を判断して定める意思決定を指します。当然ながら、ほとんどがアプリケーション設計開始に先立つ意思決定プロセスであるため、熟考が必要です。設計の意思決定を適用する例もいくつか説明します。

また、アプリケーションは、1 つの目的に従事する一連のアセットとして定義されます。複数のダッシュボードである場合や 1 つのダッシュボードのみの場合もあります。作業するアプリケーションは 1 つのダッシュボードでのみ構成されています。The Motivator に追加のダッシュボードが必要であることは、後で判断できます。ただし、このモジュールでは 1 つのみを扱います。

原則を実際の業務に落とし込む

明確で効率的で一貫性があって美しいという設計原則は、最適に思えます。ただし、The Motivator がチームの役に立つようにするには、それをどのように活用すれば良いのでしょうか?

私たちは多くの場合、設計を単なる見た目として考えます。ただし、Steve Jobs 氏の言葉を借りれば、「設計とは、単なる見た目や感じのことではない。設計とは、どのように機能するか」なのです。アプリケーションが適切に機能するには、どのようにアプリケーションが使用されるかをしっかり考える必要があります。ただし、多くの場合は、色やフォント、ブランド設定、全体的なデザインなど、ソフトウェアの外観の考慮事項から作業が開始されます。また Analytics グラフやウィジェットなど優れたデザイン表示のツールがある場合、利用できるからという理由だけで使用します。

うわべではなく、その下にあるコンテンツをしっかり考えなければ、魅力的な色やおしゃれなフォント、目を引くグラフィック、クールなグラフはユーザにとってたいした意味をなさないのです。The Motivator のことを考えましょう。外観としては、関心を引きます。ただし、その要素のいくつかは便利な位置に存在せず、所定の場にまったくない、および見つからない要素もあります。それらはすべて改善する必要がありました。

つまり、優れた設計の原則を実際に機能するアプリケーションに適用することは、熟考を意味します。以下のように、外観以外から始めます。

  1. アプリケーションの利用者目的を判断する。アプリケーションはユーザをジャーニーにいざないます。あらゆる開発作業に先立って、そのジャーニーの各ステップと、最終的にユーザを待つものに関する明確な案が必要です。それには、利用者がどのような人かと、利用者が何を必要とするかをきちんと理解する必要があります。またアプリケーションの目的を知る必要があります。目的とは、アプリケーションを使用して利用者が実現したいと願う目標です。
  2. アプリケーションの構造を思い描く。アプリケーションの機能とコンテンツがアプリケーションの目的を果たせるように、どのように境界を配置しますか? また、論理フローでそれをどのように調整しますか? アプリケーションの構造が優れていれば、ユーザのジャーニーは興味深い発見のプロセスになります。アプリケーションのコンテンツを発見するには、論理的な計画に従う必要があります。それは簡単で楽しいものです。
  3. 正しい外観の要素を選択する。機能全体でユーザのジャーニーを可能な限り流動的にして、適切なパスを選択できるように、どのような印を設定しますか? アプリケーションに対するユーザの感情的な結びつきを高めるには、どのようなデザインの選択を決定する必要がありますか? どのような視覚要素が、ユーザの目標達成の報酬となりますか?
設計プロセス: 目的から始める、構造に移る、外観で仕上げる

設計とは、どのように機能するか

ジャーニーを進めるうちに、「熟考」する方法を学習することになります。これまでに説明したプロセス全体を通じて、独自のアプリケーション設計と開発に利用できるように実践的な演習を紹介します。そのプロセスを The Motivator に適用し、熟考によって、見た目がよいものがどのように実際によいものに変わるのかを説明します。最終的には、Einstein Analytics や他の種類のアプリケーションプラットフォームの実用的に優れた独自のアプリケーションを設計するために必要なツールを得られます。

では始めましょう。

リソース