DE{CODE}: サイト モニタリング: 製品、UX デザイン、リサーチの交差点

あなたのサイトやクライアントのサイトがダウンしていることを知ったとき、あなたはそれを嫌いではありませんか? クライアントから. 二度と盲目的にならないでください！ WP Engine のシニア プロダクト マネージャーである Bryan Smith、UX アソシエイト リサーチャーの Kate Meyer、およびシニア プロダクト デザイナーの Kameron Fehrmann が、この問題を過去の遺物にする WP Engine のサイト監視ソリューションについて説明します。 このセッションでは、サイト監視がどのように機能するか、また、UX デザイン、UX リサーチ、および開発がどのように組み合わされて製品と市場の適合性が確保されるかについて詳しく説明します。

セッションスライド

全文トランスクリプト

BRYAN SMITH : みなさん、こんにちは。 私の名前はブライアン・スミスです。 私はWP Engineのプロダクトマネージャーです。 本日はご参加いただき、誠にありがとうございました。 サイトの監視、製品、UX デザイン、調査の交差点についてお話しします。 今日は、UX 研究者の 1 人である Kate Meyer と、製品デザイナーの 1 人である Kameron Fehrmann が参加します。 次のスライドでは、サイト監視とは何かについてお話します。 そこで、この新製品をリリースしました。 それは「サイト監視」と呼ばれます。 WP Engine のお客様向けのアドオンとして利用できます。 これにより、アカウントに関連付けられているすべてのサイト環境を監視できます。 また、サイトまたはプラットフォームで何らかの障害が発生した場合はお知らせします。

次に、アジェンダについて簡単に説明します。 そのため、製品について説明し、概要と技術的な詳細について説明します。 しかしその前に、Kate Meyer にこの資料を渡して、この製品にたどり着いた経緯について少し話してもらいます。 彼女は、私たちが使用したいくつかのユーザー調査手法について説明します。 その後、彼女はそれをカメロンに引き渡し、カメロンは私たちの製品設計と反復を行います. 最後に、製品の概要と技術的な詳細について説明します。 あなたに、ケイト。

ケイト・メイヤー：わかりました。 ありがとう、ブライアン、私はケイトです。 私はここ WP Engine の UX 研究者であり、現在はサイト構築サービスの改善に取り組んでいます。 そこでブライアンは、私たちが今持っている素晴らしい新製品を見せてくれました。 しかし、どうやってここにたどり着いたのでしょうか？ タイムラインの最初に戻って、デザイン思考を使用して、ユーザーに関する基本情報を把握してからわずか数か月で製品をリリースする方法を示したいと思います。 私たちのプロセスの調査面に焦点を当て、あなたの役割が何であれ、チームに UX 調査員がいない場合でも、これらのプラクティスをどのように実装できるかを共有します。

前述したように、このプロジェクトではデザイン思考のこれら 3 つのフェーズを使用しました。 デザイン思考は業界標準のフレームワークです。 これは本質的に、問題を解決するためのユーザー中心のアプローチです。 ここでは、作業をこれら 3 つのフェーズに分けて説明します。 この夏、WP Engine のユーザー ポータルの問題点を修正する方法だけでなく、それを次のレベルに引き上げる方法を学びたいと考えました。

そこで、これに対処するために、ジェネレーティブ リサーチを使用しました。 これは、さまざまなユーザーへのインタビューという形で行われました。 仕事、目標、課題などについて理解を深めるために、事前に作成された一連の質問をすべてのユーザーにすべて同じ質問で尋ねました。 面接プロセスに圧倒されるように感じる場合は、同じ目的で調査ツールを利用することもできます。 実際に、フィードバックを得るもう 1 つの方法として、SurveyMonkey とインタビューを併用しました。

調査のこの段階で、ユーザーの役割の違いにもかかわらず、実際には多くの共通の目標と問題点を共有していることが非常に興味深いことがわかりました。 そして、これは本当に素晴らしいパターンです。 私たちは実際に、さまざまなタイプのユーザー間でこれらの類似性を確認したいと考えています。 これらのインタビューと調査を実施しているうちに、ホスティング Web サイトのコンテキスト内でいくつかの共通のテーマに気付き始めました.

私たちがよく耳にする 2 つの目標は、Web サイトを監視および維持し、クライアントやサイト訪問者が問題に気付く前に問題を検出するための 1 つのツールが欲しいというものでした。 ただし、共通の問題点は、ユーザー ポータルが現在、ユーザーがこれらの目標を達成できるようになっていないことです。 実際、このエージェンシーのオーナーは次のようにまとめています。 私は、「ああ、ねえ、何だと思う？」というクライアントの電話を受けたくありません。 私は自分のウェブサイトに行きました。 そこにはありません。 今日は何をしますか？'"

ユーザーからの意見を聞いているときに、これらの共通のテーマが何度も出てくるのを目にしたら、アイデアを練る時期であることがわかります。 ユーザーが積極的にサイトを管理できるように、ユーザー ポータルを改善する必要があることはわかっていました。 また、当社のエンジニアリング チームがパートナー テクノロジを活用して、ユーザーの問題点の 1 つの側面に対処できることも知っていました。それは稼働時間の監視によるものでした。

したがって、この時点で、すぐに飛び込んですぐに何かを構築し始めるのは非常に簡単でした. しかし、最初から適切なものを構築したい場合は、この段階でユーザーからのフィードバックと意見を得ることが重要です。 この段階では、チーム全体が関与することも非常に重要です。

素晴らしいアイデアを思いつきたいと思うのは確かですが、アイデアが実現可能であり、ユーザーが本当に必要としているものと一致していることも確認する必要があります。 そのため、このフェーズでは、デザイナーがエンジニアリング チームと協力してアイデアを考え出し、サイト モニタリングの実現可能性を確認しました。 そして、プロダクト マネージャーとデザイナーと一緒に、アイデアをユーザーに提示できるように、いくつかのコンセプト テストを計画します。

コンセプト テストは、アイデアがユーザーの期待やニーズと一致するかどうかを知るのに役立つ調査の一種です。 そこで私たちは彼らに私たちのアイデアを示し、それについて質問します。 この特定のケースでは、設計者がエンジニアリング チームの助けを借りて作成した、左の図のようなミッドフィル LE モックアップを使用しました。 しかし、この種の調査の素晴らしい点は、紙にペンを書くだけの簡単なものを示すことができることです。 見栄えがする必要さえありません。

この手法は、ユーザーが視覚的なプレゼンテーションではなくアイデアに集中できるため、非常に優れています。 繰り返しますが、この段階では、あなたのアイデアが正しい方向に向かっているかどうかを知りたいと思っています。 これのもう 1 つの側面は、何十人、何百人もの人々に見せる必要がないことです。 この種の調査には 5 人程度の参加者を使用できます。その時点までに、あなたのアイデアに対する参加者の反応にいくつかの共通のテーマが見られるようになるはずです。

そのため、コンセプト テスト中に、ユーザーの期待がこの製品に対する私たちの計画と一致していることがわかりました。 そのため、私たちはそれを構築し始めるのに適した立場に置かれました. それでもフィードバックを収集したかったので、クローズド ベータに移行することにしました。 これは、何人かのユーザーにオプトインしてもらい、自分のアカウントに機能を追加してもらい、新しい機能を使用するプロセス全体でフィードバックを求めているように見えます. したがって、この少数のユーザー グループに製品へのアクセス権を与えることは、製品の使いやすさをテストし、バグを解決し、製品がすべての人にリリースされる前に、どうすれば彼らの期待にうまく応えることができるかを理解するための非常に優れた方法です。ユーザーの。

ということで、ここからカメロンが話を進めます。 しかし、調査の記事を後にする前に、私の話から何を理解してもらいたいかをまとめたいと思います. 繰り返しになりますが、このフレームワークは、ユーザーのニーズを理解し、新しい製品を構築するのに役立ちます。 また、チームの誰もが、プロジェクトのあらゆる段階で、さまざまな方法でユーザーから学ぶことができます。 ユーザーを構築の中心に置くことで、ユーザーが製品をできる限り簡単に使用できるようにし、競争力を高めることができます。 ありがとう。 カメロン。

KAMERON FEHRMANN : どうもありがとう、ケイト。 ねえ、みんな。 私はカメロンです。 私はWP Engineのシニアプロダクトデザイナーです。 また、ビルダー ツールや当社の e コマース製品も扱っており、今日はサイト モニタリングについてお話しできることを非常に楽しみにしています。 つまり、これが私たちのタイムラインのどこにいるのかということです。 ジェネレーティブ リサーチを実施し、いくつかのコンセプト テストを実施して、ベータ版をリリースしました。 私たちは人々の意見に耳を傾けているという調査を行っていますが、これが実際に私がこのプロジェクトに参加したポイントです。

以前の研究にすぐに追いつきました。 ケイトとブライアンはこれに非常に役立ちました。 正直なところ、設計と研究、製品とエンジニアリングの間のコラボレーション ケイデンスのいくつかをまだセットアップしていなかったら、物事はこれほどスムーズには進まなかったでしょう。 ですから、彼らは私が途中で追いつくのに最適なパートナーでした. エージェンシーで働くことの意味を理解している人もいると思います。 この基盤はベータ版としては素晴らしいものでしたが、それ以上のことをしたいということはわかっていました。

そのため、ベータ版をリリースした後、デザインをもう少し改善するためにファストフォローを行いました。 何よりもまず、WP Engine のステータスから始めました。 ユーザーから、彼らが経験している停止が内部で行った何かの結果によるものなのか、それとも率直に言って制御不能なWPエンジンの問題なのか、よくわからないと聞いた. そのため、WP Engine で何かが起こっていることを実際に確認できるように、このステータスを追加しました。 それはあなたではなく、私たちです。

また、監視用の追加、削除、または一時停止機能も追加しました。 これは基本的に、ユーザーがモニターを追加または削除し、必要に応じてモニターを一時停止する方法であり、エクスペリエンスをもう少しカスタマイズする方法にすぎませんでした。 そして最後に、ここでわかるように、非常に深刻な機能停止が表面化しました。 私たちは、人々が自分のサイトで何が起こっているかを明確に確認し、人々と確実にコミュニケーションできるようにしたいと考えていました. また、これは私たちが聞いたことでもあり、彼らは停止を確認し、できるだけ早く問題に対処できるようにしたいと考えていました。

そして、これは、ベータ版から始めて、リリースする前に終わった場所の前後のようなものです. ご覧のとおり、いくつかのかなり大きな違いがあります。 私たちは特に列に焦点を当てました。 コラムとは何か、コラムが何のためにあるのか、コラムに含まれる内容が何を意味するのかをよく理解していないという声が寄せられました。

そのため、何かが停止中であるかどうか、およびそれが何を意味するかについて、停止ステータスをより明確にしました。 さらに、いくつかの実用的なリンクも追加しました。 機能停止とは何かの定義を追加し、サイト監視に関するサポート記事へのリンクを追加して、ユーザーが必要に応じて詳細情報を見つけられるようにしました。

私たちが行ったもう 1 つのことは、これを社内の設計システムにより密接に結びつけることでした。 デザイナーとして、また開発者として、ある種のコンポーネントのライブラリから引き出すことができてとても良かったので、あらゆる種類のワークフローを高速化することができました. 使用しているデザイン システムをまだ持っていない場合は、1 つを強くお勧めします。 ワークフローが非常に簡単になり、すべてが大幅に高速化されます。 このデザイン システムのおかげで、左から右にすぐに移動できました。

これがそのワークフローであり、ベータ版で作業していたときのイテレーションのようなものです。 それで始めました。 リリースしました。 私たちの調査でユーザーから、また製品に取り組んでいる開発者からもフィードバックを得ていました。 一部デザインの変更を行いました。 トライアドと話します。 私たちの間だけでフィードバックがあれば、それを開発者に渡します。 フィードバックがあるかもしれません。 話し合いをしてからベータ版をリリースすると、サイクルが最初からやり直されます。

ここでチェックインするために、ベータ版をリリースしました。 ベータ調査で人々の声に耳を傾けました。 これで、アラートを開始して、そのようなエクスペリエンスを開始する準備が整いました。 アラートについては、人々がアラートを必要としていることがわかっていました。 これは非常に重要であり、モニタリングをさらに価値のあるものにするだろうとユーザーから聞いたことです。

また、ユーザーは、クライアントに問題が発生する前に問題の通知を受け取りたいと考えていることもわかっていました。 彼らは、クライアントから、サイトに問題や停止があり、実際にはそれについて知らなかったという電話を受けたくありません。 それは良いことではありません。

これについてのもう 1 つのことは、リリース タイムラインに間に合うようにしたかったので、実際にはこの作業に 2 つの開発チームを追加したことです。 より多くのチームがあったため、あなたが見たそのサイクルは非常に重要になりました。 人手が増えると作業は軽くなりますが、作業が複雑になる可能性もあります。 しかし幸いなことに、私たちは彼らのケイデンスのためにそれを処理することができました. アラートで把握しなければならなかったのは、使用したいチャネルでした。

ユーザーから主に聞いたのは、Slack や SMS よりもメールの方が好まれているということでした。そのため、最初はメールを使い続けることにしました。 そして、そこから出発して、さまざまな電子メールのシナリオをすべて考えなければなりませんでした。 私たちは、私たちのメッセージが非常に明確で実用的であること、アラートを受け取ったときにできるだけ早く理解して行動を起こすことができることを確認したかったのです.

私たちが考えなければならなかったもう 1 つのことは、誰かがアラートにサインアップしたときに、彼らが購読していることを確認したいということでした。 これは、ユーザー エクスペリエンスに関するベスト プラクティスの一種です。 そして反対側では、登録解除機能が実際に人々にとって非常にシームレスであり、すべてを考慮して非常に簡単で優れたエクスペリエンスであることを確認します. それで、ええ、私たちはこれについてさらにユーザーテストと調査を行いました。 そして、私が言ったように、メッセージが理解しやすく、実行可能であることを確認したかったのです。

繰り返しになりますが、これはテスト前とテスト後の比較です。 ここではクレイジーな違いはあまりありません。 主に、特定のエラーが何であるかを知りたがっていて、より多くの情報が必要であるとユーザーから聞いたので、それを提供しようとしました. 私たちは、エラー コードと可能な限りの情報を提供し、その内容を少しだけ明確にしようとしました。 あとは、正直リリースに向けて作業するだけでした。 正直なところ、私が話したこれらの重要なポイントのいくつかと、このプロジェクト全体で私たちが持っているこれらの重要なコラボレーションポイントを強調したいと思います.

何よりもまず、トライアド オペレーティング モデルは私たちにとって非常に重要でした。 繰り返しになりますが、この製品を発売するために、デザインと研究、製品、およびエンジニアリングのすべてがチームとして協力しました。 デザイン、研究、エンジニアリングについては、頻繁に同期と接触ベースを持っていました。 そして、私たちは質問をし、協力します。

独自の Slack チャンネルも設定しました。 誰もができるわけではないことは認識していますが、デザインと製品の間に協力的な関係を築くことは非常に重要です。 そして、それらは、製品を作成する際に、その企業または代理店レベルでその調整と説明責任を確実に持つための鍵となります.

もう一つ申し上げておきたいのは、デザインとリサーチが非常に密接なパートナーシップを結んでいることです。 誰もがデザイナーや研究者と一緒に仕事をしているわけではありませんが、ユーザー エクスペリエンスの提唱者になることはできます。 優れたリソースとベスト プラクティスを提供する UX グループはたくさんあります。そのため、それがあなたの主要な役割ではない場合や頻繁に行うことではない場合でも、ユーザビリティの提唱者になることができます。

私が言及するもう1つのことは、実際には開発とのパートナーシップです。 このプロジェクトでは、すべての開発チームと密接に協力しました。 私はしばしば彼らのところに来て、私がデザインなどを作成することに夢中になっているのではないかと尋ねました。

よかった。 私たちは本当に素晴らしい協力的な関係を築きました。 ですから、デザイナーと一緒に仕事をしているなら、手を汚して協力することを躊躇しないでください。 私たちは、そこに座って解決しようとしている問題を理解し、その共通の目標に向かって一緒に取り組むことをいとわない開発者と一緒に仕事をするのが大好きです.

その上でもう 1 つ、私は実際に、これらのチームが持つ多くのアジャイルのセレモニーとケイデンスに参加しました。 そのため、座って、改良のバックログやスプリント計画を立てて質問をすることができ、開発作業のコンテキストで彼らに質問してもらうことができたことは非常に価値がありました。 最後になりましたが、非同期コラボレーションです。 これは本当に重要でした。 私たちはグローバル企業です。 私たちには世界中にチームがあり、皆とても忙しいです。

そのため、私たち全員がコラボレーションできるように、チーム全体に専用の Slack チャネルを作成できることが非常に重要でした。 ケイトと私は研究とデザインについて投稿できました。 レビューや会議を待つことなく、フィードバックを取得したり、質問したりすることができました。 そして、私は、私たちが協力するために、状況が完璧である必要はないということを強調したいだけだと思います-すみません、完璧です。 非同期で実行できます。 会議を待つ必要はありません。 物事を成し遂げるために、すべてが正確である必要はありません。 それが私の時間です。 どうもありがとうございました。 ブライアン、私たちの製品概要についてお話させてください。

ブライアン・スミス: どうもありがとう、カメロン。 わかった。 約束どおり、製品の概要に飛び込み、最後に技術的な詳細について説明します。 だからサイト監視とポータル。 アドオンを追加すると、新しいポータル ページにアクセスできるようになります。 それは「サイト監視」と呼ばれます。 このページから、モニターの追加、一時停止、および削除を行うことができます。 カメロンはこれについて少しほのめかしましたが、これはあなたがそれを行うページです.

また、このページから、選択した日付範囲の停止、アップタイム、平均応答時間を表示できます。 また、停止が検出されたときにサイト固有のエラー ログにリンクすることもできるため、このページからすべてを実行できます。 Alert Preferences ページへのリンクもあります。このページについては、すぐに説明します。

OK。 すぐにビデオを見てからスライドに戻りたいと思いますが、これはポータルでそのページがどのように見えるかの実際のデモ ウォークスルーになります。 1つだけ指摘しておきたいのは、それはあなたがカメロンから見たいくつかの画像の前に記録されたということです. そのため、これを更新しています。 これを正確にどのように見えるかを理解しないでください。ただし、これはポータルで表示される内容の適切な概算です。

メニュー。 サイト監視リンクが表示されます。 ここでこのページを表示すると、監視しているすべてのサイト環境のリストが表示されます。 それらの応答時間と、現在監視されているすべての応答時間のリストを確認できます。 上部にある WP エンジン ステータス リンクをクリックすると、この WP エンジン ステータス ページに移動しました。 先ほどもカメロンさんがおっしゃっていましたが、そちらで入手可能です。

[モニターの追加] ボタンをクリックすると、ワンクリックで簡単に追加できます。 これは、この製品と統合の大きな部分であり、モニターの一時停止、削除、またはプロビジョニングを簡単に行えることです。 ここで、モニターを一時停止しています。 そこに小さな [再開] ボタンが表示されます。 うん。 Resume を押すと、一時停止が解除されます。

一時停止が実際に行うことは、ping モニターが実際にサイトに ping を送信するのを停止することです。 そのため、一時停止すると、実際にはその ping が送信されません。 ここでは、モニターを削除します。 確認画面が表示されます。 これらのモニターの 1 つを削除すると、実際には、それに関連付けられているすべての停止履歴が削除されるためです。 ですから、それを覚えておいてください。

それがポータルのページです。 わかった。 ここでスライドに戻り、電子メール アラートについて少し説明します。いくつかの異なるテンプレートがあります。 カメロンはこれについて少し前にほのめかしましたが、ここでもう少し深く掘り下げます. そのため、電子メール アラートをオプトインすると、次のような電子メール テンプレートが届きます。これは、サイトの監視アラートを購読していることを示しています。 サポート センターの記事へのリンクが表示されます。この記事では、この製品がどのように機能するかについての詳細を説明しています。 一番下には、先ほどお見せした Site Monitoring ページへのリンクがあります。

OK。 そのため、サイトで停止が検出されると、次のようなメールが届きます。 停止が検出されたときのサイト名が表示されます。 また、その WP エンジンのステータスも表示されます。 このステータスは、プラットフォーム、ホスティング プラットフォームの現在のステータスを示すため、重要です。 これで問題ないように見えても、まだこのメールが届く場合は、実際にはサイト固有の問題があることを示しています。

ホスティング インフラストラクチャに固有のものではありませんが、実際にはサイトまたはドメインに何かがあります。 ここにある電子メールの内容には、表示されている応答コードが表示されます。 そして一番下に、そのサイト監視ページへのリンクがあります。 アクセス ログへのリンクもあります。これは、何が起こっているのか、この停止メールが表示される理由を診断するための次の最善のステップになるからです。

わかった。 それが解決すると、サイトが復旧したことを示す別の電子メールが表示されます。 停止は発生しなくなりました。 検出されなくなりました。 これにより、バックアップされているサイトもわかります。 そのサイトがダウンしていた期間が表示され、下部にリンクが表示されます。 一番下にも同じリンクがあります。

これは、Site Monitoring ページとポータルからアクセスできるページだと言いました。 これは、実際にアラート設定を設定する場所です。 ここから、アラート チャネルを有効または無効にできます。 メール連絡先を入力できます。 電子メールの連絡先はポータル ユーザー リストから取得されるため、左側の下部に表示されます。 ただのチェックボックスです。

私たちはすでに名前とメールアドレスを持っています。 それを入力する必要はありません。 繰り返しますが、ポータルの連絡先から取得しています。 ただし、これは Slack 統合を有効にできるページになることをここで述べてください。 まだそれはありませんが、ロードマップにはあります。 これは、私たちが取り組みを開始しようとしているものです。 そのため、現在はメール アラートのみですが、Slack はロードマップ上にあります。

わかった。 ここでは、これらすべてが舞台裏でどのように機能するかについてのアイデアを提供するために、いくつかの技術的な詳細について説明します. これは、私たちが「サイト監視エージェント」と呼んでいるものを通じて可能です。これは、ユーザーポータルとそこでユーザーが行っていることと、監視およびアラート API を使用しているパートナーの New Relic との間の中間層です。 そのため、Site Monitoring Agent は基本的に New Relic リソースを一元化します。

これは、モニターとアラートを作成、更新、および削除するレイヤーです。 また、あらゆる種類のエラーを調整してキャッチできる場所でもあり、誤って削除されないようにします。 これがインタースティシャル レイヤーです。ユーザー フローで起こっていることのいくつかを少し見ていきましょう。 それでは、典型的なユーザー フローを見ていきましょう。 したがって、ユーザーはサインアップします。 ポータルに対して資格チェックが行われ、サイト監視にアクセスできるかどうかが確認されます。

その場合、WP Engine 資格サービスをチェックして、OK を取得します。 このチェックに合格すると、ユーザーは以前にポータルで示したサイト監視ページからモニターを作成できます。 そのため、[モニターの追加] ボタンをクリックして、そのモニターを手動でプロビジョニングします。 そして舞台裏では、実際にそのモニターをプロビジョニングするために New Relic Synthetics API にリクエストを送信しています。

これで、ポータルのそのページにもいる間に、データを表示できます。 履歴データを表示できます。 設定したサイトに ping を送信した結果から、平均応答時間、アクセス ログへのリンクも確認できます。 ここで、顧客はそのページでそのデータを表示できます。 舞台裏で起こっていることは、実際には別の New Relic API をヒットしているということです。 それは彼らの NerdGraph API です。 したがって、Site Monitoring Agent は、そのデータを取得して表示する要求を送信します。 そして、これもすべて、New Relic を介した NerdGraph API を通じて行われています。

一般的な他のいくつかの使用例は、Edit Monitor シナリオです。 したがって、これは既存のモニターを一時停止する可能性があり、その場合、エージェントは New Relic Synthetics API にパッチ リクエストを送信します。 モニターのプロビジョニングを解除することもできます。 これは、先ほどお見せしたポータル ページからモニターを削除することになります。 これは、Synthetics API に削除リクエストを送信しています。 お客様は構成を変更することもできます。 ping チェックの送信先ドメインの URL を変更したい場合があります。

この場合、エージェントはパッチ要求を送信してそのモニターを更新します。 また、ユーザーは、サイト監視を行っているサイトをキャンセルできます。 この場合、削除リクエストをそのSynthetics APIに自動的に送信して、そのモニターのプロビジョニングを解除するだけです。 または、顧客が多数の異なるサイト モニターを含むアカウント全体をキャンセルする可能性がある場合、それが検出されると、それらすべてのモニターをプロビジョニング解除する要求が自動的に送信されます。 したがって、これらはすべてユーザー フローにとって重要であり、Site Monitoring Agent はそれを可能にするものです。

わかった。 先ほども言いましたが、先を見据えて、Slack を追加のアラート チャネルとして統合することを確実に計画しています。 また、SMS についても検討しているため、今後の追加機能にご期待ください。 これが私たちの V1 です。 ここ DE{CODE} でローンチできることを本当にうれしく思います。 しかし、これは本当に V1 です。 たくさんのプランをご用意しております。 これらはほんの一部です。 しかし、モニタリングによる構成オプションの追加、ユーザー ポータルの改善にも引き続き注目してください。私たちは、この時点に至るまでの調査と設計の反復プロセスを継続していきます。

それでは、他のプレゼンターの Kate と Kameron に感謝します。 そして、本日ご参加いただきました皆様、誠にありがとうございました。 素晴らしい一日をお過ごしください。サイトの監視をチェックしてください。ありがとうございます。