忠実なユーザーを傷つけることなく新機能を展開する方法
公開: 2022-03-10「アジャイルであること。 早期リリース。 頻繁にリリースします。」 私たちはドリルを知っています。 しかし、機能を頻繁に展開し続けることは戦略的に賢明ですか？ 特に、構築している製品が特定のサイズに達したら、新しいマイナーリリースごとにアプリケーションの整合性を危険にさらしたくないでしょう。
あなたの製品に起こりうる最悪の事態は、忠実なユーザー、つまりその小さな機能を何年にもわたって一貫して使用している顧客が、突然同じ便利な方法でそれを使用できなくなることです。 この変更により、ユーザーはより強力になる可能性がありますが、エクスペリエンスはそれほど単純ではなくなります。 欲求不満と不安がソーシャルメディアに急速かつ突然入り、有意義かつ時間内に対応するためのカスタマーサポートへのプレッシャーは毎分増加します。 もちろん、新しい機能を展開して、実際に忠実なユーザーを傷つけていることを認識したくはありません。
SmashingMagの詳細：リンク
- 機能のリリースを2倍の速さで開始した方法
- ウェブサイト立ち上げチェックリスト–公開する前の15の重要なチェック
- モバイルデバイスのWebデザインへのユーザー中心のアプローチ
- 何かを起動する方法
当社の製品の新しいバージョンを展開する際により戦略的になることで、これを防ぐことができます。 この記事では、製品設計者とフロントエンドエンジニアが機能を徹底的にテストして展開してからユーザーベース全体にリリースするための戦略と、UXの問題が今後発生するのを防ぐ方法について説明します。
実際のテスト戦略に飛び込む前に、一歩下がって、新機能がどのように設計、構築、そして最終的に展開されるかについての一般的な誤解を調べてみましょう。
新機能の誤解
既存の製品の新機能が設計されるときはいつでも、主な焦点は通常、それが既存のインターフェースにどれだけ正確に統合されるべきかということにあります。 一貫性を実現するために、私たちの設計者は多くの場合、既存のパターンを調べ、確立された設計言語を適用して、新しい機能をUIに適切に配置します。 ただし、問題が発生するのは、コンポーネントが視覚的に連携しないためではなく、予期しない方法で組み合わせると混乱したりあいまいになったりするためです。
おそらく、インターフェイスのコピーがWebサイトの関連しているが離れた領域であいまいであるか、2つの機能が同時にアクティブに使用された結果は、技術的な観点からは理にかなっていますが、ユーザーの期待と一致しないか、パフォーマンスに大きな影響を及ぼし、UXを傷つけます。
実際、設計では、これらの多数の組み合わせが、完全に予測およびレビューするのが非常に困難です。 すでに設計プロセスにある間に問題に取り組む1つの方法は、外れ値を検討することです。問題が発生する可能性が高い場合のユースケースです。 ユーザーの名前が非常に長い場合、ユーザープロファイルはどのようになりますか？ 多数の受信トレイラベルが使用されている場合でも、未返信の電子メールの概要は明らかですか？ サインアップしたばかりで、受信トレイに数通のメールしか入っていないユーザーにとって、新しいフィルターは意味がありますか？
外れ値の設計：ユーザーインターフェイススタック
外れ値を特定したら、どの程度正確に設計できますか？ 優れた戦略は、ユーザーインターフェイスのさまざまな状態を調査することです。 Scott Hurffによって導入されたアイデアである「ユーザーインターフェイススタック」は、用途が広く複雑です。インターフェイスを設計する場合、通常、Photoshop、Sketch、またはHTMLとCSSでピクセルパーフェクトなモックアップを作成するだけでは不十分です。さまざまなエッジケースと状態：ブランク状態、ロード状態、部分状態、エラー状態、および理想状態。 これらは、私たちが考えるほど単純ではありません。
空白の状態は空である必要はありません。サービスワーカーを使用して、通常の訪問者により良いオフラインエクスペリエンスを提供することができます。 部分的な状態を壊す必要はありません。プログレッシブエンハンスメントによって、壊れた画像や壊れたJavaScriptのエクスペリエンスを向上させることができます。
理想的な状態は、カスタムユーザー設定とユーザーのブラウザーの選択により、「完璧な結果」のモックアップとは大幅に異なる場合があります。 一部のコンテンツやWebフォントは、ブラウザの設定などにより表示されない場合があります。
ですから、いつものように、風景は複雑で、複雑で、予測不可能であり、物事がうまくいかないリスクを無視することはできませんが、これは、リスクを効果的に最小化できないという意味ではありません。 外れ値とユーザーインターフェイススタック全体を早い段階で調査することで、設計の初期段階で一般的なUXの問題を防ぐことができます。 ただし、技術的な面では簡単にはなりません。
展開におけるバタフライ効果
小さな変更でさえ連鎖反応を引き起こす傾向があり、まったく関係がないと思われる領域や状況にバグが発生します。 これの主な理由は、ユーザーエクスペリエンスに影響を与えるが、私たちが制御できない変数の量が非常に多いことです。 私たちはブラウザの使い方を知っていますが、それはユーザーが私たちがこれほど精力的かつ徹底的に作成したWebサイトを見ることを選択するコンテキストについてもっと知っているという意味ではありません。
現在、ボタンのパディングやプログレッシブエンハンスドテキストエリアなどの小さな変更は大したことではないように思われるかもしれませんが、これらの光沢のある小さな変更や機能の影響を大規模に過小評価する傾向があります。 設計または開発の決定を行うたびに、その変更は、構築している複雑なシステムに何らかの影響を及ぼします。これは主に、構築しているコンポーネントが孤立して存在することがないためです。
現実には、ボタンを作成したり、新しいJavaScript関数を作成したりすることはありません。ボタンと関数はコンポーネントまたはライブラリのファミリーに属し、すべて特定の設定内で動作し、他の関数との接続は避けられません。システムの一部は、プロパティ、スコープ、名前、またはチームの記述されていない規則によって示されます。
これらの「サイレント」でほとんど目立たない接続が、機能の展開が難しい理由であり、変更の広範囲にわたる結果を予測することが、鋭い視力の練習であることがよくある理由です。 そのため、CSSでもJavaScriptでも、不要な依存関係をできる限り回避することをお勧めします。特に、完全に理解していないライブラリに依存している場合は、メンテナンスやデバッグに役立ちません。 。
幸い、変更の影響をよりよく理解するために、ブラウザーの開発者ツールなどのリソースを使用できます。 セレクターのリーチまたはJavaScript関数のリーチを測定できます。変更の範囲を可能な限りローカルで最小限に抑えるために、開発中にセレクターに戻ってくることをお勧めします。
これは役に立ちますが、話の一部にすぎません。 私たちは、インターフェースに関する私たち自身の経験と私たち自身の習慣に基づいて、意識的および無意識に仮定を立てます。仮定はユーザーごとに大幅に異なる可能性があることを忘れがちです。 ほとんどのアプリケーションには1つのインターフェイスしかありませんが、このインターフェイスまたはその構成には数十の状態があり、ユーザーの設定や設定に応じてビューが変化します。
カスタマイズ可能なカードを備えたダッシュボード（分析ソフトウェア）、「コンパクト」、「快適」、「詳細」ビューを備えたメールクライアント（Gmail）、ログインした顧客とゲストのために変更される予約インターフェイス、読書体験について考えてみてください。広告ブロッカーまたは積極的なウイルス対策フィルターを使用している人向け。 バタフライ効果は、コードベースだけでなく、それ以上の影響を及ぼします。 これらの外部要因もすべて考慮に入れられ、単体テストや一般的なQAとは異なり、何をテストするかさえわからないことが多いため、それらに対するテストは非常に困難です。
機能の検証とローカルの最大値
診断とメトリックを使用して、どのような変更を行う必要があるかを判断できますが、データだけを追跡することで、「ローカル最大値」と呼ばれる傾向のある、十分に優れた設計のインターフェイスの状態で停滞する可能性があります。それは常に予測可能な論理的な反復に従うため、イノベーションはまったく欠けています。 プロジェクトに取り組んでデータを探索するとき、次の4つのバケットに機能をグループ化する傾向があります。
- 壊れた機能。 。 壊れているか非効率的であるように見える機能—明らかに、それらを修正する必要があります。
- 未使用の機能。 。 意図したとおりに機能するが、ほとんど使用されない機能—多くの場合、それらを削除する必要があるか、または必死に革新が必要であるという兆候。
- 予期しない使用機能。 。 作成者が当初想定していたものとは非常に異なる方法で使用される機能—ゆっくりとした継続的な改良の良い候補。
- 働き者の機能。 。 頻繁に使用され、計画どおりに機能しているように見える機能—この場合、低速の反復プロセスとまったく異なる革新的な概念の両方を並行して調査することで、UXをさらに改善する方法があるかどうかを自問します。
最初の2つのバケットは、インターフェイスの機能と使用可能性を維持するために重要ですが、後の2つは、ユーザーの関心と喜びを維持するために重要です。 理想的には、両方の目標を同時に達成したいのですが、時間、予算、チームの制限が優先されます。
それでも、新しいイテレーションまたは新しいアイデアが選択されると、すぐに新しい機能の設計または構築に取り掛かる誘惑に駆られる可能性があります。 ただし、機能が既存のインターフェイスにどのように適合するかを考える前に、最初にアイデアを検証することをお勧めします—簡単なプロトタイプとユーザー調査を行います。 これを実現する一般的な方法は、GoogleVenturesのデザインスプリントなどの迅速な反復プロセスを使用することです。 数日以内に繰り返すことで、新しい機能をどのように実装する必要があるか、および/または最初に想像していた方法でそれが役立つかどうかを特定できます。
デザインスプリントを使用して、アイデアをユーザビリティ調査に早い段階で公開します。 Google Venturesの方法論では、1日に5人のユーザーでデザインをテストします。 次に、新しい設計のテストを繰り返して実行します。 同じユーザー全員が関与する理由は、その日に各ユーザーで異なる設計をテストすると、どの要素を変更する必要があるかを知るための有効なデータがないためです。 1回の設計反復を検証するには、数人のユーザーが必要です。
スプリントには少し異なるモデルを適用します。 新しい機能の作業を開始するとき、初期の最初のプロトタイプが作成されたら、デザイナー、開発者、およびUXチームを同じ部屋に集め、実際のユーザーをテストに招待し、厳しいスケジュールで繰り返します。 初日、最初のテスター（2〜3人）は午前9時に30分間のインタビュー、2番目のグループは午前11時に、次のグループは午後2時に、最後のグループは午後2時にスケジュールされる可能性があります。 1つは午後4時頃です。 ユーザーインタビューの合間には、「オープンタイムウィンドウ」があります。実際に設計とプロトタイプを繰り返して、ある時点で実行可能なものができるようにします。
この理由は、早い段階で、まったく異なる、時には反対の方向をすばやく探求したいからです。 さまざまなインターフェースに関するフィードバックを収集すると、 「絶対最大」インターフェースのように感じるものに収束できます。 このようにして、非常に多様な設計の反復に関する非常に多様なフィードバックをより速く得ることができます。 フィードバックは主に、ユーザーのクリックを記録するヒートマップ、ユーザーがタスクを完了するために必要な時間、ユーザーのエクスペリエンスがどれほど楽しいかという3つの要素に基づいています。 週の後半には、Googleと同じように、より多くのユーザーと一貫して作業を続け、新しいデザインを永続的に検証します。
これまでのところ優れていますが、一見革新的な新機能が既存の機能と衝突することがあり、両方を同じインターフェイスに配置すると、設計が乱雑になることがあります。 この場合、オプションの1つが他のオプションの拡張と見なされるかどうかを調べます。 可能であれば、その機能とデザインを繰り返すことから始めます。 そのとき、根本的な再設計または段階的な変更を選択する必要があります。 後者はリスクが低く、ユーザーにとってなじみのある対話パターンを維持しますが、重要な変更を他の方法で実現できない場合、または増分変更による利益が浅すぎる場合は、前者が必要です。
いずれの場合も、製品内の単一の機能の価値ではなく、製品のユーザーエクスペリエンス全体に焦点を当て続けることが重要です。 機能を選択し、最初のプロトタイプを設計および構築したら、テストを行います。
8つのレベルのテスト
では、エラーや障害が実際のライブ環境に忍び寄るのを効果的に防ぐにはどうすればよいでしょうか。 機能が展開される前に、いくつのチェック、レビュー、およびテストを実行しますか？ そして、これらのテストをどのような順序で実行しますか？ 言い換えれば、機能を展開するための最終的な戦略はどのようになるでしょうか？
機能を展開するためのより良い戦略の1つは、ロシアの主要な電子メールプロバイダーであるMail.ruの開発責任者であるAndrewSuminによって提案されました。 この戦略はすべてのプロジェクトに適用できるわけではありませんが、中規模から大規模の製品を数千の顧客に提供する企業にとっては合理的で包括的なアプローチです。
戦略を詳細に見て、Mail.ruの製品開発プロセスをカバーする機能ロールアウトの8つのステップをカバーしましょう。
- 開発者とのテスト、
- 制御された環境で実際のユーザーとテストし、
- 全社的なユーザーでテストし、
- ベータテスターでテストし、
- 手動でオプトインしたユーザーでテストし、
- 分割テストと保持の確認、
- ゆっくりと徐々にリリースし、
- 余波を測定します。
Mail.ruの場合、メッセージを構成しているものに関係なく（明らかに）そのまま維持するための最も重要な機能。 これは最もよく使用されるインターフェイスであり、使用できないようにしたり、数秒間でも正しく機能しないようにすることは、まったく問題外です。 では、おそらくいくつかのスマートオートコンプリート関数、カウンター、またはサイドプレビューを追加することによって、テキストエリアの機能を拡張したい場合はどうでしょうか。
1.開発者によるテスト
開発に時間がかかるほど、問題の修正にかかる費用は高くなります。 繰り返しになりますが、製品開発においてすべての決定がどのように関連しているかを考えてください。 製品が洗練されているほど、より多くの決定を元に戻す必要があり、時間とリソースがかかります。 したがって、ビジネスの観点と設計および開発の観点の両方の観点から、問題を早期に特定して解決します。
ただし、アイデアをデバッグすることはできないため、最初のプロトタイプで、本番環境で初期テストを実行する必要があります。 Mail.ruの最初のテスターは、実際にコードを作成する開発者です。 同社は、従業員が製品を社内コミュニケーション（さらにはプライベートコミュニケーション）に使用することを奨励しています。 したがって、開発者は製品のハードコアユーザーと見なすことができます。
最初のステップは非常に明白です。機能を設計および構築してから、ステージングサーバーでローカルでテスト、レビュー、およびロールアウトします。 これがQAテストの出番であり、機能とインターフェイスをクラッシュさせようとする包括的なツールとタスクランナーがあり、Gremlins.jsなどのサルテストツールで自動化される可能性があります。
結果は監視され、機能の次の反復のためにフィードバックループにフィードバックされます。 ある時点で、開発者はビルドに非常に自信を持つようになります。変更は期待どおりに機能しているようで、要件は満たされています。 そのとき、実際のユーザーテストが始まります。
2.制御された環境で実際のユーザーを使用してテストする
最初の実用的なプロトタイプが完成すると、実際のユーザーとのインタビューで機能がテストされます。 顧客はタスクを完了するように招待されます。そのように、UXチームは行き止まりと発生する問題を監視し、その場で対処します。
ただし、テストされているのは新機能だけではありません。 ユーザビリティテストの目標は、新機能がインターフェイスの重要なコンポーネントに影響を与えないことを確認することです。そのため、ユーザーはメッセージの作成、受信トレイでのメールの開封、返信、閲覧などの日常的なタスクを完了します。 新機能と旧機能の両方が十分に理解されていれば、プロセスを進めることができます。
3.全社ユーザーによるテスト
明らかに、ユーザビリティテストからのフィードバックにより、開発者は変更を導入するように促され、変更はユーザビリティテスターにフィードバックされ、結果がより多くのユーザーにとって価値があると思われるまで前後に行き来します。 次のステップは、機能が社内で脚光を浴びることです。全社的な電子メールが送信され、すべての同僚に機能を確認して、トラッカーでレポート、バグ、提案を送信するように促します。
テストでは、社内の「リモート」部門のユーザーと実際のユーザーの間に特に大きな違いはありません。 内部ユーザーでさえ、どのような変更が予想されるか、または機能がどのように機能するか、または機能がどのように機能するか、またはどのように見えるかを正確に知りません。 唯一の主な違いは、同僚にフィードバックをすばやく送信したりコメントを残したりするように促すことができることです。 その時、投票フォームが導入されます。 テスターはこの機能を試すだけでなく、コメントを追加して賛成または反対することもできます。 投票は製品戦略やビジネス要件と比較検討する必要がありますが、ユーザーが機能が役に立たない、または役立つと明確に感じた場合、それはフィードバックを収集し、製品が期待どおりに機能するかどうかをテストするための簡単で効果的な方法です。
4.ベータテスターでテストする
機能が技術チェック、ユーザビリティチェック、および社内でのレビューに合格した場合、次の論理的なステップは、それをオーディエンスの一部のセグメントに紹介することです。 ただし、ユーザーのランダムなセグメントに展開する代わりに、チームはベータテスター（テストに参加して実験的な機能のフィードバックを送信することを選択したユーザー）の間でレビューする機能を送信します。 機能に反対票を投じたり、賛成票を投じたり、バグを報告したり、コードの一部をコミットしたりできます。
しかし、どのようにして適切なベータテスターを選択しますか？ テスターにインターフェースを壊すように勧めたい場合は、技術的なスキルを持つ高度な忠実なユーザーに焦点を当てることができます。必要に応じてバグに関する技術的な詳細を提供できるユーザーや、既存のインターフェースを十分に理解しているユーザーです。他のユーザーが抱えている可能性のある問題を予測することができます。
ただし、ユーザーがベータテスターになるのに十分なレベルに進んでいるかどうかを判断するための基準が必要です。 メールクライアントの場合、ChromeまたはFirefoxを使用している（つまり、デフォルトのブラウザを変更する方法を知っている）人で、受信トレイに3つ以上のフォルダを作成し、モバイルアプリもインストールしている可能性があります。
5.手動でオプトインするユーザーでテストする
この時点まで、テストには管理可能な数のユーザー、構成、およびテストレポートが含まれていました。 それでも、オペレーティングシステム、ブラウザ、プラグイン、ネットワーク設定、ウイルス対策ソフトウェア、その他のローカルにインストールされたアプリケーションなど、実際に使用されているユーザー、システム、構成の多様性は、規模がやや困難になる可能性があります。
Mail.ruの場合、次のステップは、フラグの背後にあるライブインターフェイスで機能を展開し、アクティブユーザーのこのより大きなセグメントに電子メールを送信して、新機能を提示し、アクティブユーザーにアクティブ化するように招待することです。通常、光沢のある「更新」ボタンを使用して、インターフェイスで所有します。 実際のユーザーにとっての機能の価値を測定するために、チームは再び投票システムを使用し、あちこちにいくつかのプロンプトを表示して、基本的に機能が役立つか役立つかをユーザーに尋ねます。 このレベルと前のレベルの違いは、手動オプトインにははるかに多くの対象者が関与することです。ベータテスターとは異なり、その多くはまったく技術的ではありません。
したがって、タイミングと調整が重要です。 バグレポートのストリームが入り始めたときにカスタマーサポートチームと開発者が利用できるようにするため、アクティブユーザーに電子メールを送信するためにランダムな日を選択することはおそらくないでしょう。そのため、電子メールはで送信されます。週の初め、すべての（またはほとんどの）開発者が利用可能であり、サポートチームが行動に移す準備ができており、SkypeまたはSlackを介して開発者にブリーフィングされ、積極的に接続されています。 小規模な会社では、開発者がサポートデスクに数時間座って、顧客に直接話しかけることで問題の核心にすばやく到達することもできます。
6.分割テストと保持の確認
これまでの手順では、ユーザビリティテストを除いて、すべてのテスターが自主的に新機能を使用しています。 ただし、この機能をデフォルトで有効にすると、突然ユーザーがそれを使用する必要があります。これは非常に異なる種類のグループであり、まだテストしていません。
パッシブユーザーの習慣を壊さないようにするために、ユーザーの3つの小さなセグメントで分割テストを行い、保持を測定することができます。 結局のところ、新しいバージョンが少なくとも前のバージョンと同じように機能することを確認する必要があります。 インターフェイスで最も重要なアクティビティを特定し、ロールアウトの前後にユーザーがそれに費やした時間だけでなく、ユーザーが戻るまでに経過した時間も測定します。 Mail.ruの場合、保持にはユーザーが自分の電子メールをチェックしてメッセージを作成することが含まれます。 ユーザーが戻ってくる頻度が高いほど、保持率が高くなります。これは、UXが優れていることを示しています。
各セグメントはわずかに異なるビューを取得します。これにより、後ですべてのユーザーに新機能を表示する方法をテストできます。 最初のセグメントでは、新しい機能を追加し、その使用方法に関するチュートリアルを提供します。 2番目のセグメントでは、新しい機能を追加するだけです。 3番目のセグメントでは、機能をそのままにしておくことができます。 これらすべてのセグメントについて、同時に変更を実装し、テストを実行するための適切な時間枠を選択し、保持を測定して、結果を比較することができます。 セグメントの保持率が高いほど、後ですべてのユーザーにデザインが宣伝される可能性が高くなります。
7.ゆっくりと徐々にリリースします
機能がこの時点まで完全に機能している場合は、おそらく、オーディエンスの大部分ですでにうまく機能しています。 これは、フィードバックを収集するための投票プロンプトを使用して、すべてのユーザーに段階的に展開できる場合です。 フィードバックがほとんど肯定的なものである場合は、機能を展開し続けることができ、最終的にはインターフェースの不可欠な部分になります。 それ以外の場合は、フィードバックを評価して、次の反復のためにラボに戻ります。
ただし、この機能を展開するだけでは不十分です。ユーザーに伝達する必要があります。 これを行う一般的な方法は、電子メールとソーシャルメディアを使用することです。 それでも、実際のシナリオでの機能の価値を説明する簡単なウォークスルーチュートリアルも役立つ場合があります。 また、すぐにフィードバックを収集するために提案ボックスを統合することを忘れないでください。
8.余波を測定する
機能が公開されると、そのパフォーマンスを監視し、さまざまな方法で注目を集めることができるため、ユーザーはタスクをより効率的に実行できます。 最も一般的なタスクまたは最も訪問されたページを追跡し、ユーザーが目標を達成するための少し賢くて速い方法を推奨する小さなインラインメモを表示し、ユーザーがこの新機能を好むか通常の方法を好むかを測定できます。
開発者や設計者だけでなく、チーム全体にフィードバックを返すことを忘れないでください。そうすることで、彼らはやる気と関与を持ち、当初は大まかなアイデアにすぎなかった機能を人々がどのように使用するかを確認できます。 思い描いたとおりに、またはまったく異なる方法でアプリケーションを使用して、幸せで喜んでいる人々を見るほど、やる気を起こさせるものはありません。 また、チームの後続機能の成長にも栄養を与えます。
レビュープロセスは複雑で徹底的に見えますが、ユーザーテストのための時間と幅広いネットだけで問題が明らかになる場合があります。 たとえば、変更が着信メッセージの概要に影響を与える場合、単体テストでは、支援ソフトウェアのユーザーが遭遇する可能性のある問題を明らかにすることはできません。 メールインターフェイスで、ユーザー補助デバイスに最初に何を読み取らせたいですか？日付、送信者、件名、またはメッセージ自体ですか？ 概要の列を再配置する方法によって、ユーザーが情報にアクセスする方法が変わる可能性があります。 そのため、新機能をオフにできるようにすることも重要です。
結論
では、展開戦略はどのようになっているのでしょうか。 依存関係のグラフを調べて、変更がどの程度広範囲に及ぶかを理解することから始めることができます。 次に、制御された環境で開発者と実際のユーザーを使用して機能をテストできます。 次に、ベータテスターの選択したグループに送信する前に、機能を確認するよう同僚に依頼することができます。 最後に、この機能をオプションとしてユーザーが利用できるようにすることができます。 また、すべての人に機能を有効にする前に、分割テストを実行して機能を導入するための最良の方法を見つけ、重要なタスクの保持率を測定することができます。
明らかに、展開は直線的なプロセスではありません。 プロセス全体を通して、リリース候補が最終的に得られるまで、一歩前進するために2歩後退する必要がある場合があります。 上記のワークフローは非常に遅く、特にアジャイルではないように思われるかもしれませんが、ユーザーが突然予期しない問題に直面し、結果としてエクスペリエンスが低下するリスクを大幅に最小限に抑えます。 状況によっては、それだけの価値があるかもしれません。