安全な旅行 -旅行サポートサービス
保険への訴求を1つのアクションポイントに減らすモバイルアプリケーションのケーススタディ
海外での休暇中に保険のケースがありましたか？ そうでなければ、それは良いことであり、神はあなたに健康を与えます！ しかし、スーツケースの底のどこかに横たわっている保険証券を思い出さなければならない場合、誰かに不快なことが起こる可能性があります。 横になっていなくてもスマートフォンに保存されている（そしてスマートフォンが常に手元にある）場合でも、緊急時には保険会社の電話番号を見つけ、オペレーターに電話して、インシデントを報告し、正確な場所と保険番号を述べる必要があります。 それほど難しくはないように見えますが、ストレスの多い状態です-シンプルであるほど良いです。
顧客と目標について
ルネッサンス保険は、ロシア最大の保険会社の1つです。 このプロジェクトで重要なのは、直接保険の場合-インターネットおよびコールセンターを介した保険の販売-ユニバーサル保険会社の絶対的なリーダーです。 モバイルアプリケーションは、シンプルで便利なルネッサンスの保険サービスを日常生活に統合するという概念の継続であると想定されていました。 顧客の生活を大幅に簡素化するサービス。
当初、顧客には明確な目標がありました：本当にクールで有用なサービス（できるだけ簡単で便利な保険イベントを宣言する機能）を作り、顧客ロイヤルティを高め、モバイル製品からビジネス上の利益を保証します（保険契約の繰り返しの販売を増やします）。
顧客価値：迅速なヘルプと節約
主な機能の動作スキーム-「パニックボタン」は次のとおりです。緊急時には、アプリケーションは被保険者に支援を提供するために必要なすべての情報（被害者の名前、GPS座標と連絡先の詳細、保険ケースの種類、保険番号）を含むSMSを生成し、呼び出しに送信しますセンター。 オペレーターは観光客に電話をかけ直し、詳細を明確にして問題の解決を支援します。
クライアントは通話自体を保存し（ローミングでの着信は発信よりもはるかに安い）、「正確にどこにいるのか」という質問でパニックに陥ることはありません。また、手元の情報（パスポートと保険番号、保険会社の電話番号）を心配しません。
すべてが構築された最も重要な瞬間は、不可抗力の場合に、パニックボタンをすぐに見て押して、何にも邪魔されないようにする機会でした。パベル・ゴルシコフ、Redmadrobotのアートディレクター
2番目のポイントは、ユーザーにメッセージを送信するためのアルゴリズムを可能な限り透過的にし、混乱せず、迷子にならないように実行することです：対話の各ステップで、彼は今何が起こっているかを理解し、完了したら、今何をすべきか？
主な使用例
前提条件：クライアントはSafe Tripモバイルアプリケーションをダウンロードしてインストールし、ポリシーの詳細を入力しました。 そうでなければ、彼は問題を昔ながらの方法で解決する必要があります-何かが既に起こっているとき、誰もアプリケーションをダウンロードすることを気にしません。
•保険事故が発生した-旅行のキャンセル、荷物の紛失、アパートでの事件、怪我や病気、事故、またはクライアントのポリシーで規定されているその他の状況。
•クライアントはSafe Tripアプリケーションに入り、スタート画面の[Need Help]ボタンを確認してクリックします。 次に、彼は保険イベントのタイプを選択し、「コールミー」ボタンを押します。
•アプリケーションはSMSを生成して送信します。SMSは、クライアントの状況、GPS座標、個人データ、およびポリシー番号を保険会社に通知します。
•15分以内に、オペレーターはクライアントにコールバックし、電話を介して正確な情報に基づいてさらに通信が行われます。
もちろん、「画面-大きな赤いボタンのように」という概念がプロジェクトの議論に登場しました。 しかし、それは非実用的であることが判明しました。 一方では、人はすでに心配しています-ヘルプデスクからの電話を待っている間に、巨大な半画面ボタンを見ることを好まないでしょう。 一方、アプリケーションでは、ストレスなしで使用する他の重要なサービスがあります。
•ポリシーと旅行の管理。 アプリケーションでアラームを処理し、情報を保険会社のコールセンターに正しく転送できるようにするには、ユーザーが必要なすべてのデータを入力する必要があります。
•保険期間、旅行日、居住国の考慮。
•アプリケーション設定。
•情報および参照の異議申し立て。
デザイン：シンプルさは難しい
アプリケーションの設計の承認には約3か月かかりました。この間、5つのレイアウトが描画され、静的なHTMLで描画され、異なるロジック遷移とレイアウト画面が使用されました。 ビジネスタスク用のアプリケーションは非常に単純に見えるにもかかわらず、合計で約100の画面が入力されました。
インターフェイスでの設計は決して設計ではありません。 これは、一方でユーザーの問題を解決し、他方でビジネスを解決するためのシナリオの設計です。 また、モバイルコンテキストでは、特に注意する必要があります。画面はコンピューターモニターよりも1桁小さいです。 指はマウスカーソルよりも比較にならないほど大きいです。 最短時間、最大レベルの注意散漫。 ニュアンスが非常に多いため、真にエンジニアリングのアプローチが必要です。マキシムテンス、Redmadrobotのクリエイティブディレクター
開発者がプロッターA0形式を使用する理由
モバイルアプリケーション開発者は印刷する必要があるように思えますか？ さて、十数個のiPhoneスクリーン。 このためには、通常のA4カラープリンターで十分です。 しかし、なぜプロッターなのか？
実際のところ、アプリケーションロジックが複雑で、画面とそれらの間のトランジションの数が100に選択されている場合、これらすべてを頭の中に保持することは不可能であり、1つのモニターでも機能しません-小さすぎます。 これは、大規模なプロッタが役立つ場所で、その上に画面のマップ（アプリケーション全体）を表示できます。 その後、壁に掛けてチーム全体と話し合うことができます。
アプリケーション開発のいくつかのコンポーネントは、紙上でより便利で視覚的です-プロジェクト管理のタスクで、視覚資料を含むワークスペース全体の編成を含みます。
ポリシー、観光客、スマートフォン：多対多
たとえば、クライアントが常に単独で1つのデバイスと一緒に旅行するとは限らないため、アプリケーション内のロジックの複雑さが発生します。
•旅行者は、たとえば異なる国に対していくつかの既存のポリシーを持っている場合があります。
•複数の人を1つのポリシーに含めることができます-家族全員または開拓者全員です。
•アプリケーションは複数のデバイスにインストールできます。 繰り返しますが、クライアントが家族として旅行する場合。
つまり、エンティティ「観光客」、「ポリシー」、および「デバイス」は多対多の関係にあり、開発時にはこれを考慮する必要があります。
アーキテクチャ：責任範囲を明確にする
開発者が自分でアプリケーションを作成する場合、アーキテクチャは技術用語でのみ重要です。したがって、製品は信頼性が高くスケーラブルであるため、個々のブロックを開発し、それらがどのように適合するかを理解できます。
しかし、プロジェクトが法人顧客向けである場合、アーキテクチャは政治的問題も反映し、請負業者と顧客の責任範囲を区別するのに役立ちます。 たとえば、外部の開発者を保険会社のバックオフィスアプリケーションに入れることはできませんが、統合が必要になります。
このアーキテクチャは、両方の当事者が一緒に開発したものであり、セキュリティサービスとの調整はかなり簡単でしたが、これは実際には珍しいことです。 問題はありませんでした。 どうやら、開発者はすでにコーンを詰め込んでおり、これは前向きな役割を果たしました。 次に、会計システム上でWebサービスを作成しました。 そして、Redmadrobotのメンバーは、アプリケーション自体とミドルウェアサーバーを作成しました。 実際には、通信はそれを通過します。アプリケーションはミドルウェアにアクセスし、すでにWebサービスと対話し、キャッシュが行われます。ルネッサンス保険プロジェクトのテクニカルディレクター、セルゲイトロフィモフ
個人データ
厳密に言えば、Safe Tripは個人データを処理しません。 クライアントがアプリケーションに情報を入力すると、当然、アプリケーションに保存されますが、これは個人のデバイスにローカルに保存された彼の情報のみです。 さらに、ポリシー番号と被保険者の名前を保存するだけで済みます。これは個人データでさえないため、通常のセキュリティ対策で十分です。 すべてのクライアントの一連の個人データの処理は、安全な境界線に位置し、管轄当局のすべての要件を満たす保険会社のサーバーで行われます。
これについては、警備員と主な議論がありました。 ISはアプリケーションへのアクセスに必須のパスワードを要求しましたが、クライアントが自分のセキュリティに責任を負うべきであるという立場を擁護しました-必要に応じて、パスワードを設定できますが、パスワードを必須にしませんでした。
Nikolay Efankin、Renaissance InsuranceのSafe Tripプロジェクトマネージャー
サイトのモバイルアプリケーションVSモバイルバージョン
アプリケーションとモバイルバージョンのサイトの主な違いは、最初のケースでは、サービス（コンテンツ、サービス）がユーザーのデバイス上で「生き」、先を見越して対話できることです。
保険の例を見てみましょう。 旅行する顧客の中には、有効期間が長く、保険日数が限られている（たとえば、それぞれ180日と90日）複数のポリシーを購入することが多いものもあります。 保険を期限内に延長するために旅行に費やした日数をカウントする必要があり（次の購入のカレンダーの日付を覚えているだけでは機能しません）、無効な保険に悩まされることはありません。 使用済みの保険日数を計算するこの退屈な仕事は、アプリケーションに任せるのが最適です。
Safe Tripの最初のバージョンでは、クライアントは旅行に関する情報を入力する必要があります。その後、GPSデータを使用してクライアントの場所を特定し、保険日の計算を自動化する予定です。
このフォームでは、サイトのモバイルバージョンのサービスは「ライブ」できません。
ところで、延長について-モバイルアプリケーションを使用すると、顧客はよくある質問に対する回答を自分で見つけたり、電子保険を手配/更新したり、保険金請求の際に段階的な指示を受けたりすることができます。 そして、これは節約です。
今後の計画
Androidバージョンとセルフコントロール-不要な機能でアプリケーションをオーバーロードせず、顧客のビジネスに集中することなく、複雑化することを控えることが重要です。