情報畑でつかまえてロゴ
本サイトは NTTテクノロスが旬の IT をキーワードに
IT 部門が今知っておきたい最新テクノロジーに関する情報をお届けするサイトです

みんなに愛される『CipherCraft/Mail 7』のつくり方(その4:シナリオ検討篇)

当社が提供している「CipherCraft/Mail 7」が、UXデザイン手法をどのように活用して、生まれたのか。今回はシナリオ検討です。

おはようございます。こんにちは。こんばんは。

HCD-Net認定 人間中心設計スペシャリスト 井山貴弘です。

挨拶

 

その1:概要篇」「その2:調査準備篇」「その3:調査結果篇」と続き、今回で4本目の記事となります。

 

個人的に、4本目が最高傑作といえば、映画『スター・ウォーズ エピソード4/新たなる希望』が思い浮かびましたが、これは実際には1本目であり、ちょっとズルい選択です。

 

他の映画では『ロッキー4/炎の友情』『スーパーマン4/最強の敵』などもあり、私はどちらも大好きですが、今回はこれらのお話ではなく...。

 

4本目にして原点回帰し、シリーズを盛り上げるきっかけとなった、『ワイルド・スピード MAX』について、少しUX視点で変えて考えてみると...。

 

同作は、2作目、3作目と変容し、縮小しかけていたシリーズに対し、1作目のコンビを復活させた上に、迫力のカーアクションを魅せてくれました。

子供たちの運転

 

その結果、既存のファンを喜ばせてくれただけでなく、物語的にも、観客層的にも、更なる広がりを可能にしてくれました。

 

どのような配役、どのような内容にすれば、観客が観に来てくれて、楽しんでくれるのか。

 

物語の細かな整合性や話の上手さといった部分とは違った、その前提となる、観客が映画に接する場面や状況、そして観賞前から観賞後までの感情までもを踏まえた、「観客の行動シナリオ」が優れていたからこそ、劣勢の状況からシリーズを立て直し、更に飛躍させることができた。そんな印象を受けました。

 

実際の制作時は「観客の行動シナリオ」以上のことが考えられており、細やかなマーケティング、たくさんの大人の事情が絡み合っているとは思いますが、ごく個人的な感想として、今作以降のシリーズ展開は大絶賛で、毎回劇場に足を運んでいます。

 

...ということで、今回のメール誤送信防止ソフト「CipherCraft/Mail」カイゼン話は、そんな「シナリオ」の話を中心に、進めたいと思います。

 

UXデザイン手法における「シナリオ」とは?

UXデザイン手法では、ユーザが行動する場面やそのときの感情を、物語のように具体的に描写していくことで、その行動や感情を満たすために必要な機能やUIを明確にし、関係者で共有する、構造化シナリオ法という手法があります。

シナリオ検討

 

一般的な流れでは、複数のユーザインタビューからペルソナ(仮想ユーザ)を作成し、ペルソナの視点で、場面とタッチポイントを明らかにするジャーニーマップを作成、そして、それをシナリオ化していきます。

 

シナリオ化では、以下3種類のシナリオを、段階的に作成していくのが主流です。

  • 「バリューシナリオ」・・・ユーザの価値を定義

  • 「アクティビティシナリオ」・・・ユーザの普遍的な行動を定義

  • 「インタラクションシナリオ」・・・ユーザの具体的な操作を定義

 

では「CipherCraft/Mail」は、どのようにシナリオ化を進めたのか。

 

まず、前回の調査結果篇で明らかになった、過去の事例とインタビュー、そして現場調査の結果から、「アクティビティシナリオ」...を言い換えて、理想とする通常時の点検シナリオと、その派生となる例外時の点検シナリオ、ふたつの「点検シナリオ」を、ユーザ目線で作成しました。

 

そして、その両者のシナリオを満たせる点検項目と画面、操作手順を、当社の関係者ならびに、旧NTTアイティ社こころを動かすデザインラボと共に検討し、ワイヤーフレームの作成に繋がる「インタラクションシナリオ」を言い換え、「操作シナリオ」を完成させました。

 

ふたつの「点検シナリオ」

前回の分析資料提供時点で、

  • 点検項目を絞り込んだ方がよいこと

  • 想定しない方法で点検が行われ、リスクが発生していること

を開発担当の方に共有し、あるべき画面は理解いただいていました。

想定外

 

しかし実際の開発を進めるためには、開発担当だけでなく関係者全員に、その方針を受け入れていただく必要があります。

 

ですので、前回の繰り返しのような話になりますが、

  • 点検項目を絞り込むことで、誤送信がより確実に防止できること

  • 想定しない方法で点検を行われても、リスクが発生しないこと

を製品への関与が少ない方でもイメージできるように説明し、納得していただかなくてはなりません。

 

そのため、まず現行画面の点検項目の内、誤送信の原因として多い項目を抽出しました。

 

抽出した点検項目について、繰り返し操作によるマンネリなどの要素も加味し、「付帯情報を極力絞った必要な情報のみ、必要なタイミングで表示。確実な確認を促すことによって点検漏れにより誤送信が減る」という結論に辿り着く、開発側が想定する通常利用時の点検シナリオを作成しました。

 

それに加えて「確認する情報が必ず目に入る装飾とすることで、キーボード操作でも、マウス操作と変わらない意識で点検が行える」という結論に辿り着く、開発側が想定しない特殊状況時の点検シナリオも作成しました。

 

作成したシナリオは、こちらに公開できませんが、システムは人間の手助けになるものであることという当たり前が、いずれのシナリオにとっても重要な要素となりました。

 

画面も検討した「操作シナリオ」

新たなサービスの設計工程の場合、画面があることでアイデアの範囲を狭めてしまうため、シナリオ段階で画面の検討を行わないことが多いです。

 

しかし今回は既存画面のカイゼンです。

 

画面を検討することで、点検の必要がある項目とない項目を、明確に共有できると思い、シナリオと併せて画面のレイアウト検討も行いました。

ホワイトボード

 

当社UXメンバと旧NTTアイティ社こころを動かすデザインラボで集まり、ワイヤーフレームの素材になるような画面のレイアウト案も作成できるよう、ホワイトボードも使いながら、シナリオの検討とレビューを実施しました。

 

誤送信事故結果から想定されるリスクの高いメール内容、同姓アドレスの組み合わせなど、間違えやすい場面と状況を検討し、必要な点検項目の選定と、想定される操作を明確にしていきました。

 

想定ユーザが、どのような状況下で、どのような相手に、どのような内容のメールを作成し、何度目のメール送信をしようとしているのか、そして点検時は、どのような感情でどう確認を進めていくのか、という操作シナリオと、それを満たす手書きの画面案を完成させました。

 

関係者への提案

関係者へ提供した資料には、シナリオに加えて、イメージが想起しやすいように、手書きの画面案の写真を貼り付けました。

ワイヤーフレーム

 

そして、誤送信を防止する観点から、点検画面に必要な要素も整理しました。

 

  • メーリングリスト選択誤り防止

    • ...ドメインも点検ボタン化し、点検対象とする

    • ...点検ボタンのそばに確認メッセージを表示する

  • 同姓アドレス選択誤り防止

    • ...メールアドレスをボタン化し、必ず視界に入れる

    • ...点検ボタンのそばに確認メッセージを表示する

  • 慣れによる確認スルー防止

    • ...点検が必要な項目のみ表示/点検させることで、 点検画面=要確認であることを常に意識させる

 

更に人間工学の観点も考慮した防止策も整理しました。

 

  • 知覚におけるエラー防止策(ナレッジベースにおけるエラー防止策)

    • ...点検対象を絞り、付帯情報を表示しない


      • 「宛先:メールアドレス」「添付ファイル」「暗号化」の3点のみ対象にする
      • 付帯情報は、マウスオーバー時のみ表示する
  • ルールベースにおけるエラー防止策

    • ...必要があるもののみ点検させる


      • 『返信履歴のあるメールで、かつ送信履歴のある宛先は、点検対象外(=ボタン表示しない)』など、条件を設定する
  • 認知段階におけるエラー防止策(スキルベースにおけるエラー防止策)

    • ...点検ボタンのそばに確認メッセージを表示する


      • 確認メッセージを点検ボタンのすぐそばに表示し、注意すべき点検項目を明確にする
      • 送信履歴から同姓者や類似MLの情報を取得し、指摘する

     

    このように、シナリオを完遂するために対象とすべき点検項目と付帯情報、その操作と表示条件といった機能仕様に近い部分まで含めた資料を用意し、カイゼン方針の提案を行いました。

     

    もう少しかんたんに表現すると、シナリオで利用場面を具体的にイメージいただき、画面案を使って実際の操作を見て、納得いただきました。

     

    その結果、カイゼン支援前まで行ってきた、点検項目や点検画面を増やして誤送信を減らす方針、それとは真逆の、点検項目を減らし、リスクがある場合のみ画面を表示する、つまり、必要最低限な点検にすることで誤送信を減らす、という方針が、開発担当だけでなく、関係者全員に、承諾されました。

    大団円

     

    ...と、実際のシナリオが公開できないが故の、あっさり感もありますが、以上が、シナリオ検討篇となります。

     

    前回の繰り返しのような展開も、理想のシステムに導くためには、手を変え、品を変え、相手を変えて、何度も説得が必要となる場面もある、そんな一例になったかと思います。

     

    次回は、シナリオと手書きの画面案から実画面になった過程、「CipherCraft/Mail 7」編の最終回をお届けしたいと思います。お楽しみに。

     

     

    ちなみに、最終回に向けての予告としては・・・

     

    日本食

     

    この記事の公開日である2/14のバレンタインで、チョコを食べ過ぎた方が感じているかもしれない「日本に生まれたらやっぱり日本食だよね」的な感覚が大切な鍵になります。

     

     

    CCMailバナー
    こころを動かすICTデザインラボバナー

※Windows は米国 Microsoft Corporation の米国およびその他の国における登録商標です。
※「CipherCraft」はNTTテクノクロス株式会社の登録商標です。
※その他会社名、製品名などの固有名詞は、一般に該当する会社もしくは組織の商標または登録商標です。

連載シリーズ
(366)日のUXデザイン
著者プロフィール
井山 貴弘