この記事では、従業員の作業インターフェイスについて説明し、従業員にとってなぜそれが重要なのか、従業員をどのように作成するのかを説明します。
では、なぜこれが重要なのでしょうか？
私たちは国内最大の支店ネットワークを持つ国内最大の銀行です。 サービスのデジタル化の一般的な傾向にもかかわらず、顧客はオフィスに行く必要があり、コンタクトセンターに電話する必要があります。 ロシアでは、毎日何千人もの銀行員が最前線のオフィスにいます。 ユニファイドフロントシステムの目的は、右下のボタンの色を変更するだけでなく、銀行の従業員の仕事を支援することです。
銀行員は何枚の画面を見ると思いますか？ 日中にサービスマネージャーに表示される画面を重ねると、4つのエッフェル塔ができます。 なぜそんなに多いのですか？ 国内最大の銀行には多くのプロセス、膨大な数の製品があるためです。 同時に、システムの信頼性は99.99％です。 このレベルの信頼性により、祖母は時間通りに部門の年金を受け取ることができ、母親は遅滞なくローンまたは公共料金を支払うことができます。
ESFプログラムチームは重要なタスクに直面しています。品質と信頼性を損なうことなく、システムを各従業員にとって便利で理解しやすいものにします。 以前は、 統合の秘密を共有していたため、技術的な詳細には触れませんが、ビジネスユニット側の難しさについて説明します。
その結果、さまざまな食品部門の従業員は何か良いことをしたいと思っていますが、必ずしも同意する時間はありません。 そして、これは多くの大企業の問題です。 その結果、彼らが製品を紹介し始めたとき、他のチームがやった部分はそれに接続されていませんでした。 そして、そのような話が起こり、クライアントはカードの銀行支店に来て、従業員は非常に複雑な方法で問題を解決します：彼は最初に1つのシステムに入り、紙にデータを書き込み、次に別のシステムに入り、そこでクライアントを見つけて製品を作成し、次に行きます3番目のシステムに。 そして、私たちはそれを変えています。
どこから始めましたか？
彼らはシステムを最も単純なものから変え始めました。 私たちは製品チームと顧客サービスの単一モデルを持っていることに同意しました：彼が私たちのところに来たとき、私たちは彼をシステムで一度だけ見つけ、彼の必要性を決定し、必要な操作を実行します。 ESFプラットフォームを使用すると、すべてのプロセスを単一の順次チェーンに結合できます。 約100のチームがプログラムでこのようなチェーンのサポートと開発に取り組んでいます。一部のチームはクロスプラットフォームプロセス（多くの運用とサービスに共通）を開発し、他のチームは実際の製品マジックに取り組んでいます。
100チームの作業を同時にサポートするにはどうすればよいですか？
チームワークでは、アジャイル開発手法を使用します。 理論的には秘密の知識はありませんが、実際には、1つのタスクで効果的に作業するために非常に多くの人々を同期させるにはどうすればよいでしょうか？ 結局のところ、各チームはその製品だけでなく、全体のプロセス全体にも取り組んでいます。 たとえば、約5つのチームが新しいクライアントカードを作成する操作の開発に関与しています。
試行錯誤、継続的なチームワークを通じて、独自のレシピを開発しました。
- セレモニー
私たちはさまざまな式典を開催し、その間に計画と回顧を議論し、現在の開発を示し、関連部門と議論し、交渉します。 式典、そのタスク、および参加者に応じて、会議のカレンダーが計画されます。 最大の式典の1つは、四半期のタスクの共同計画です。 会議のカレンダーの計画は、内部銀行業務の手順とリリース、ルールの影響を受けます。コンプライアンスの必要性は、最初に説明したすべてのシステムの高い信頼性によるものです。
そのため、3か月ごとに、開発が将来のリリースに含まれるすべてのチームが集まり、四半期のタスクについて合意します。 最後のそのような会議の数は400人の参加者を超えました。 チームのタスクはバックログに分割され、スプリントに分割され、スプリントは必然的に同期されます。 話し合いの過程で、参加者はリスクと、以前に考えも計画もしていなかった単純な「ホワイト」ゾーンを作成することが重要です。 このようなセレモニーのスクリプトは毎分計算され、チームの計画に加えて、プログラムには建築家、デザイナー、および計画の初期段階でプロセス全体のボトルネックを解決するのに役立つその他の関連専門家とのコミュニケーションが含まれます。
このアプローチにより、ある時点で従業員が何らかの操作を完了できないという状況を除外できます。
- UXテスト
私たちは多くのことをテストしています。 2週間のスプリントでは、すべてのチームが製品および「エンドツーエンド」プロセスで約200のUXテストを実施し、その結果に応じて製品に最大1000個の変更が加えられます。 その結果、習慣の改善と強さの間の妥協点を見つけたと確信でき、インターフェイスソリューションは各従業員にとって便利で理解できます。
- 設計
ESFプログラムの設計ブロックは、適用と概念の2つの部分に分かれています。 概念設計者は、従業員の仕事がどのように見えるかの一般的な概念を開発しており、ESF設計システムを開発しています。 当社の設計システムは、アトミックデザインの原則に基づいており、コンポーネント、ガイド、グリッド、テンプレートで構成されています。
適用されたデザイナーはプロジェクトで直接働き、製品所有者、アナリスト、プログラマーと毎日コミュニケーションを取り、プロセスを理解し、概念デザイナーが開発したコンセプトを実装します。
これが実際に銀行員に与えることは何ですか？
実際のスプリントタスクの1つの例から、提示されたインターフェイスのデータはテストデータであることがわかります。
領収書を持って銀行に来て、ガス、電気、電話の代金を支払います。 以前は、従業員が銀行で各支払いを個別に実行していましたが、ビジネス顧客は領収書の束で支払うことができるバスケットを作成することにしました。 開発者は、Unified Frontal Systemでの開発の開始前であっても、既存のインターフェースでバスケットの最初のバージョンを組み立てました。 お客様は、バスケットのこのオプションを可能な限り保持し、いくつかの方法で支払う機能を追加するように私たちに依頼しました（店舗で、十分な現金がなく、金額の一部をカードで支払うことにした場合）。
従業員が対処しているかどうかを確認するために、顧客の要件に可能な限り近いバスケットの最初のバージョンを設計しました。
このソリューションでは、画面が3つの部分に分割されました。支払いのリスト、支払い方法の選択、総費用です。 テストの結果、従業員は最後の画面で支払いを行ったことを覚えていないことがわかりました。 1人の従業員が仕事をしたわけではなく、UXの重要度は高いと判断されました。
UXテストでは、2つの重要なメトリックを評価します。
- タスクを完了した従業員の数。
- 発言の臨界レベル。 重大度は、高、中、低のいずれかになります。 高-従業員は操作を完了できません。 中-実行できますが、エラーが発生します。 low-実行しますが、わずかな偏差があります。
2番目の試み。 支払い方法を取り上げました。 彼らは、支払い方法を単一と複数に分けることを提案しました。 画面の高さを減らしました。 テスト結果は、5人の従業員のうち3人がすでにタスクを完了したことを示していましたが、重要度はまだ高かったです。
3番目の試み。 支払選択方法を変更しました。 彼らは支払い方法を詳細に書いた。 ここでは、すでにすべての回答者がタスクに対処しており、最適なソリューションが見つかりました。
このプログラムでは、常に新しいプラクティスを試行し、事例を共有しています。この記事では、新しいUXツールを使用したパイロットについて説明し、添付ファイルでは、従業員向けのUXトピックに関する最新のプレゼンテーションを見ることができます。
このパイロットを実施するきっかけとなった理由は、次のとおりです。質の高いUX研究（3〜5人）を実施する場合、デジタル製品とのユーザーインタラクションの理想的なプロセスからの逸脱をしばしば明らかにします。 そして、改善に関する決定を下すには、顧客の総質量に対するこれらの逸脱の重要性を非常に迅速に確認/反論する必要があります。 この問題を解決するために、1〜2日で必要な定量データ（50〜100人*）を取得できるリモートの非モデレートテストの方法を試しました。
パイロットには、Usability FactoryからFabuzのリモートユーザビリティテストを実施するためのクラウドベースのツールが選択されました。ちなみに、多くのロシアの大企業がこのような問題を解決するために使用しています。
パイロットへの挑戦
クライアントは、別の地域の銀行のクライアント（高齢の親relative）の銀行のモバイルアプリケーションで家賃を支払わなければなりませんでした。
回答者：25〜45歳の働く男性と女性（50/50）は、銀行部門やマーケティング分野の出身ではありません。 これらのうち、50％は銀行のモバイルアプリケーションのアクティブユーザーであり、50％は非アクティブです（1か月に1回以下のトランザクションを実行します）。 回答者は、モスクワとノボシビルスクの2つの特定の地域に住むことになっています。
テストした仮説：
•アプリケーションの領域をどのように変更するかは、ユーザーには明らかではありません。
•ユーザーが支払いの地域を変更することにより、プロファイルの地域を変更していることはユーザーには明らかではありません。
もちろん、私たちが持っていた条件は非常に短いものでした。
検証のために、ユーザーがモバイルアプリケーションで別の地域の親relativeの請求書を支払う必要があると想定されるプロトタイプをまとめました。
次に、システムに特別なアンケートを作成しました（2時間かかりました）。これには、スクリーニングの質問（性別、年齢、地理など）が含まれます。 プロトタイプアプリケーションで自分の電話で実行する必要があった参加者のタスク。 難易度の評価と彼らが遭遇した困難についての自由回答式の質問。
その後、モスクワとノボシビルスクの調査参加者からアンケートへのリンクが自動的に送信されました。 参加者はリンクをクリックし、質問に答え、タスクを完了し、評価とコメントをしました。 調査中に、ツールはリアルタイムモードでオンラインレポートになり、集計されたデータを収集しました。
•ジェスチャーの視覚化による参加者の携帯電話画面のビデオ録画
•問題に関する参加者の評価とコメント
•プロトタイプページ間で参加者を移動する
•テスト結果（失敗/失敗/失敗）
•テストリードタイム
•場所とクリック数
などなど。
日中、モスクワとノボシビルスクの57人の回答者がプロトタイプの支払いシナリオを実行しました。 これらの参加者のデータを分析した後（分析には約8時間かかりました）、次の結果が得られました。
•回答者の60％は、プロトタイプに実装されたインターフェイスの機能により、このタスクを迅速に完了/完了できなかったため、仮説が確認されました。
•ユーザーが問題を解決することがわかったいくつかの一般的なルートが見つかりました。これは、プロトタイプの完成とUXの設計に大いに役立ちます。
•さらに、いくつかの洞察を受け取りました。たとえば、ユーザーは別のクライアントへの支払いを送金として認識している、プロファイルで地域を変更する機能を見つけられないなどです。
コメントでは、あなたの提案について話し合い、質問に答え、慣行を交換します。
そして、これが「プロモーション」会議のスピーチの約束されたビデオです。