その結果、潜在的な所有者がカードをアクティブ化するプロセスをテストするときに、多くの問題が発生しました。 簡単に説明すると、1ステップで3ステップ、さらにログインするには2ステップ、不便なパスワードを不便に入力します。 その結果、予測される効率は最大10％です。 これはすべて、訪問者の行動に対する設計の欠如の結果です。
「カード番号を入力し、訪問者にボーナスをクレジットするためのウィンドウがどのように機能するかのロジック」を説明するために契約しました。 構造全体が現在機能している方法（システムに名前を付けるのが怖い）。
私はそれを「訪問者の行動の設計」と呼び、3つの部分に分けました。カードを持たない訪問者+カードオペレーターによる登録、訪問者がカードにボーナスをクレジットする、訪問者がカードで支払う。
理論的には、これはすべて1つのドキュメントに含まれているはずです。 これはすべて、単一のスクリプトプロセスの説明です。 しかし、論理の結合は、特にITから遠く離れた人々にとって、研究にとって非常に面倒で不便になります。
仕事の初めに、私の説明と価格の後に、企業全体の「メイン」が発行されました。「はい、ビールのために店主と一緒に膝の上に半時間描きます」 正直、気分を害した。 その結果、訪問者が1分以内で完了するプロセスは、この作業に割り当てられた4日間で説明されました。
最終バージョンと私の推奨事項は、ボトルネックだけでなく、店の側で動作するスクリプトを完全にやり直す必要があるという事実を示し、現在動作する形式では、ボーナスのクレジット時のエラーだけでなく、詐欺のすべての前提条件がありますアカウントに。
私自身は、オンラインストアインターフェイスでカードを操作するプロセスをできる限りシンプルにし、エラーや妨害から保護するようにタスクを設定して、地上のオペレーターの行動を明確に説明しました。 そして、それは必須であるため、問題が発生した場合、訪問者はかんしゃくで問題を解決することなく迅速に対処できます。 結局のところ、カードを入力するためのウィンドウと対話するプロセスが難しい場合、問題はストア内の変換に直接影響します-それはすぐに変換に影響します。 そして、一般的に、クラブシステムは会員を失います。
設計された動作（以降、簡単に「ロジック」と呼びます）には、いわゆる利害関係者のグループが3つあることが判明しました。 つまり、プロセスに関与する被験者。 オペレーター、ビジター、スクリプト。 後者は論理的にも重要なアクションを実行するため、興味のある人のグループに彼を登録しました。
プロセス全体を説明しても意味がありません。 このリンクでロジックを作成したスキームを見ることができます 。ここでは、動作の3つのシナリオの中で最も単純ですが、残りはどのように行われたかは構造的に明らかです。
プロセスの設計を通じて明らかになった重要なポイントについて説明します。
インターフェイスの外観を変更する
設計プロセス中に、カード番号を入力するフィールドに加えて、いくつかの要素をワークフローに追加する必要があることが明らかになりました。
- 「カードはありませんか？無料で入手できます！」などのリンク。
- 短い説明テキスト。
- サポート電話番号。
- カード所有者検証用の新しい入力フィールド（詳細は以下）。
- カード所有者の検証後に発行されたテキスト。
この点で、ブラウザやスペシャルによってブロックされないシンプルなポップアップを導入することを提案しました。 メインウィンドウを暗くするプログラム。 ポップアップの新しいウィンドウ、新しいタブなどはありません 注文プロセスは線形である必要があることを忘れないでください。つまり、訪問者はプロセスを大幅に変更することなく、あるウィンドウから別のウィンドウにスムーズに移動しました。
さらに、プリセットの繰り返しカードの数字などの些細なこと：9800000000000（その後、変化する3桁の数字があります）。
カード所有者の検証
この問題は2つの方法で解決できます。 カードをストア内の訪問者のアカウントにリンクします。 あなたの顧客にカードを配られた場合にのみ機能します。 一度（オペレーターまたは訪問者自身）を結び付け、繰り返し検証を忘れると、特定の店舗の顧客の生活が大幅に簡素化されます。 しかし、これはすでに店舗自体の対決であり、それぞれ、カードをリンクするための機能を完成させるためのお金です。このため、ボーナスカードシステムは支払いません。
2番目のオプションは検証の繰り返しです。 訪問者がカードを使用する予定がある場合、訪問者は同じシーケンスを作成するたびに。
最初の方法では、2番目の方法が除外されません。 クラブボーナスプログラムは、あなたの顧客ではない他のカード所有者がいることを意味します。
検証はSMSを介して行われ、訪問者はSMSからコードを入力する必要があります。 すべてが単純なように思えますが、「それは数百回」でした。 実際、考慮すべき点がいくつかあります。
- SMSは来ませんでした、訪問者は何をすべきですか？ これは、サポートサービス番号の必要性が現れる場所です。
- SMSが届きましたが、別の人（入力や悪用によってミスを犯した人）には、検証番号に加えてSMSの内容を検討する必要があります。
顧客の代表者に仕事を引き渡すと、クライアントが単にボーナス口座にお金を預けたいという条件で、カード所有者の検証の必要性について紛争がありました。 なぜここに検証があるのでしょうか？ 誰も他の誰かの口座にお金を預けたいとは思わない。
私は検証を主張しました、私の議論は次のとおりでした：
- 不正なカード入力によるエラーに対して訪問者にプログラムで警告する必要があります;検証以外の方法は見ていません。 （アラン・クーパーを読んで、本の最初に彼の考えの確認を見つけました） ;
- スクリプトは、訪問者が実行したい操作を認識していないため、「ボーナスを使いたい」チェックボックスなどの追加の手順が必要です。
- 多くの訪問者はボーナスを使いたいと思うでしょう。 したがって、チェックボックスの要求は大多数になります。 さらに、同じ過半数は、アカウントにあるボーナスの数を絶対に認識していません。
- 前の段落から、アカウントのボーナスをチェックするという問題が発生します。これは必須の検証を意味します。
- クライアントは、支払いシステムを作っているという事実に反論しました。たとえば、ほとんどのウェブマネーユーザーは、自分のアカウントにどれだけのお金があるかを知っています。 ちなみに、このクラブカードの将来の重要な特徴が入り込んでいます。 ユーザーはウェブマネーを使用して商品の代金を支払い 、カードを使用して商品を購入してボーナスを受け取ったり、ボーナスを使用したりします。 そして、カードを配布する方法と原則に基づいて、聴衆はそれをボーナスとして知覚します。そのため、クライアントが関連付けを変更する方法を理解できません（叙情的な余談はごめんなさい） 。
- 追加の手順により、変換が困難になります。 誰もが理解しています-より多くのステップ、より低いコンバージョン;
- オンラインストアは、訪問者のコンバージョンを減らす場合は、スーパーハイパーハイパークラブカードを使用したいと考えています。 前の段落から次のように、プロセスの複雑さは明らかであり、多くの店はそのような困難に反対しています。
プロセスの複雑さは明らかであり、スクリプトや訪問者の行動の設計に自然に適合する一連の条件が表示されます。
顧客担当者に私の無実を納得させるのに1時間かかりました。
アカウントのボーナス額の確認
システムは、カード所有者の検証後、スクリプトがカードアカウントおよびその他のデータの残りのボーナスを受け取るように設計されています。 したがって、利用可能なボーナスの量に関する情報は、店舗側のスクリプトのメモリに入力されます。
攻撃者はこの時点で、たとえばボーナスの一部を使って携帯電話を補充するなど、意図的に店舗をだまそうとすることができるため、「支払い」ボタンをクリックした後、残高の2番目のリクエストを提供しました。
ボーナス予約機能
オンラインストアの現在の現実は、訪問者が注文した商品が入手できない場合があるということです。 したがって、このような場合は、システムのサーバーにデータを送信するプログラムのロジックで提供する必要があります。
ボーナス資金で注文を支払う場合に、訪問者の口座に資金を予約する機能をお勧めします。 お金はクライアントの口座から出て、特定のバッファーに落ち、オペレーターからの確認を待ちます。状況に応じて、操作をキャンセルするか確認します。
当然のことながら、オペレーターは電話で（有線の顧客から）クライアントの口座からボーナス資金を引き出すことができ、注文の完全な交換が提供されます。
レスキューマネージャー
この機能は最後の瞬間に登場しました。 事実は、訪問者だけでなくオペレーターも間違っているということです。 間違いを犯したり、何か間違ったことを紹介したりするのは簡単なことです。 スクリプト機能で、注文管理パネルに次のチェックボックスを追加することをお勧めします。「訪問者にカードデータを繰り返したことを確認します」。 この場合、チェックボックスの使いやすさはひどいはずです-ボックス自体をクリックしたときだけです。 ボックスをチェックすることによってのみ、オペレーターは注文をさらに変更することができます。
この機能は小さな些細なことですが、訴訟や払い戻しのためにオペレーターや店舗の所有者に多くの神経を節約します。
まとめ
上記の機能のいくつかは、誰かにとってささいなことや些細なことのように思えるかもしれません。 1つだけ気づきたいのは、新しいサービスやオンラインストア全体の最初の立ち上げ時に見過ごされがちな些細な決まり文句です。 おそらく、このプロセスで発生するすべての問題を予測することはできませんでしたが、少なくともその数は減りました。
私の言葉とアプローチでは、ラメリズムのシェアがあることを認識していますが、一般的にこれは結果に大きな影響を与えなかったと思います。
オンラインストアの所有者向けに、サードパーティのスクリプトを接続したり、クラブシステムと契約を結んだりするときに忘れられるいくつかのポイントのチェックリストを投稿しました。
- 契約を確認して、店舗から受け取ったお金（顧客のお金）の責任者が明確に示されるようにします。
- 契約の終了に関するセクションを注意深く読んでください。 誰が誰に何を負いますか。
- ストアがログアウトするとどうなるかを慎重に考えますか？ 私のクライアントの場合、店には一種のサービスとして、システムの使用に対して単に支払う機会があります。 プログラムの終了は、クライアントにとって苦痛なプロセスです。
- システムを返金するプロセスを学びます。 日付、手数料など
- 提案されたスクリプトのユーザビリティとインターフェースを慎重に研究してください。 将来の変換はそれに非常に強く依存する可能性があります。