ユーザーエクスペリエンスを考える上で、機能の説明をするチュートリアルという要素は重要なものです。ですが、このチュートリアルの設計を誤ると、大量の初期離脱ユーザーを招いたり、何も読まずにチュートリアルを飛ばされた結果、全く意味のない要素となってしまいます。
過去の事例から学んでみましょう。
FinalFantasyV
FinalFantasyは日本を代表するRPGシリーズのひとつで、その5作目のナンバリングタイトルとして1992年に発売されました。シリーズとしては、スーパーファミコンでは2作目のゲームになります。
FF5のチュートリアル
オープニングを終えると、早い段階で戦闘に入りますが、特に何も説明はなく、コマンドが現れるだけです。
当然、何もしないとゲームオーバーになりますが、このコマンドの選択肢が「たたかう」と「アイテム」しか無いので、ユーザーは「たたかう」を選ぶか、「アイテム」を選ぶか、何もしないかを選択することになります。
「アイテム」を選んでも殆ど何もできないため、最終的に、多くのユーザーは「たたかう」を選択します。すると、主人公のキャラクターがアニメーションし、敵のグラフィックの近くに数字が表示されます。
勘の良いユーザーでなくても、この数字がダメージを表すというのはわかるかと思います。また、画面下部に何やら数字が表示されています。敵から攻撃され、主人公キャラクターに同じく数字が表示されますが、このとき、下に表示されている数字も同じだけ減算されます。これが体力を表していることが推測できます。
また、ジョブやアビリティという要素がありますが、これは序盤のダンジョンをひとつクリアしたあとに初めて解放される要素であり、その頃にはユーザーも戦闘システムに慣れている頃なので、スムーズに新要素を受け入れることができます。
このチュートリアルの優れた点は、ゲームの世界観にうまく学びを溶け込ませることによって、チュートリアルであるということを気づかせないことにあります。こうして、ゲーム進行のスピード感を損なわず、「勉強させられている感」を最小限に抑えた上で、ユーザーに段階的かつ自然な学びを提供することが出来ています。
文章で説明しない
「『たたかう』を選択するとキャラクターが攻撃するよ！」といった親切なメッセージを出してあげるのも、選択肢のひとつではあります。しかし、それでは世界観に没入する、という体験を得る契機をひとつ失ってしまいます。
ユーザーはゲームの世界観を楽しみたいのに、わざわざ座学を強いられてしまうわけです。これはお世辞にも楽しい時間とは言えません。
要素を一度に見せすぎない
人の脳は、基本的にはマルチタスクが得意なようには出来ていない（参考：同時作業が得意な「2％の超人類」）ようです。つまり、parallelではなく、serialに情報を処理するほうが得意なことがわかります。
FF5は、ジョブやアビリティなどの多様な要素がありますが、それらが解禁されるのは最初のダンジョンをクリアした頃であり、しかも、20種類以上あるジョブも、その時点では数種類しか取得できません。こういった工夫により、脳に一度に情報がなだれ込むことを防止しています。
チュートリアルを再考する
時代が異なることもあり、もちろんこれが正解というわけではありません。
そもそもなぜチュートリアルが必要なのか
チュートリアルは、ソフトウェアなどの使い方を学んでもらうための、いわばレッスンなわけです。昔はそれを説明書が担っていましたが、説明書がチュートリアルと決定的に違うのが、「必要になったら参照できる」つまり、必要になるまでは殆ど参照しないという性質のものだったわけです。
Windowsは、F1キーでヘルプ機能を呼び出すことができ、こちらも同様に、「必要になったとき」に閲覧できるようになっています。
しかし、多くのチュートリアルでは、スキップできる機能など稀であり、強制的に見せられる性質のものが多く、さらに、あとから見返そうと思っても、見返すような機能が実装されていなかったり、実装されていたとしても、それを閲覧するための手順が分かりづらかったりします。
また、UIデザインも、直感的に理解できるようにいくつか決まりごとを守って実装されていました。たとえば、「Aボタンが決定」「Bボタンがキャンセル」というのは、昔のゲームでは常識的なインターフェースでしたし、Windowsのアプリケーションでは、フロッピーディスクのアイコンが保存を表しているのは当然のことでした。
とはいえ、それも分からない、というユーザーは一定数存在します。そんなユーザーのために、説明書やヘルプ機能があったわけです。ですが、もしかすると、Windowsのヘルプ機能を使ったことが無い、という人も多いのではないでしょうか？
時代の変遷とともに、ソフトウェアの複雑性は増していますから、操作方法をユーザーに学んでもらう重要性は高まってきていますが、ソフトウェアの使い方を学ぶモチベーションが高まっていなければ、強制的に見せられたとしても、そのまま読まずに飛ばしてしまうユーザーが多いのではないかと思います。
これでは、ソフトウェアの使い方を学んでもらうという目的を達成できません。
現代ソフトウェアのチュートリアル
多くのアプリでは、少々冗長な説明がなされているように思います。
もちろん、詳細なチュートリアルが必要なソフトウェアもありますが、それはアイコンなどのイラストから意味が類推できなかったり、デザインが重視されているソフトウェアに多いようです。
酷いのが紙芝居形式のチュートリアルで、一切インタラクションもありませんから、まずもって興味を引くことができません。「それ、モーダルウィンドウでブロックしてまで見せることか？」と感じたアプリも多いです。
そんな中でも、ユーザーが必要になったときに、執事のようにぱっと出てきて使い方を教えてくれる、というようなアプリが無いわけではありません。PayPayなどはこのあたりのユーザーエクスペリエンスが比較的優れているプロダクトだと思います。（2021年1月現在）
執事とは言いましたがExcelのイルカくんは別です。
必要なときに、必要な分だけ
電卓アプリを例にとってみましょう。電卓の使い方というのは、通常誰にでもわかるものです。しかし、「足し算をするには、数字をタップしてから、＋ボタンをタップし、また数字をタップし、＝ボタンをタップします」のようなチュートリアルがあるとどうでしょうか。親切なアプリだな、と思う人は少ないでしょう。
ゲームでも、「『攻撃』と書いてあるボタンをタップすると、攻撃するよ！」と言われても、「攻撃って書かれてるからそうだろうね…」となりますよね。
プログラミングのコメントもそうです。
// ユーザーの名前を取得します。
getUserName(user) {
return user.name;
}
見ればわかるものを、わざわざ書かないといけないというのは、あまり良くないとされていますよね。こういったUX設計でも同じことが言えそうです。
過剰に説明しないと理解しないユーザーがいるかも…？
それは事実です。
しかし、ターゲット層とユーザー比率を考えてみましょう。特に説明がなくても理解出来る人が大多数の場合、全ての人を救おうと過剰に説明すると、大多数の人のUXを損ねてしまいます。
逆に、過剰に説明する必要のあるユーザーが多数の場合は、説明がなくても理解出来るようなユーザーに多少の不便を強いるのは仕方のないことです。
バランスを取るのは難しいですが、A/Bテストなどを用いたりして、より効果的な方法を探るのが重要です。
チュートリアルが効果的に作用しているかどうかを知る
チュートリアル画面を閲覧している時間を取得するなどすれば、読み飛ばしているユーザーを推定することは比較的容易でしょう。またはユーザーインタビューを行うなどの方法もあります。重要なことは、実装しただけで終わらず、それが確実に効果を出しているかを検証することです。
効果検証は、時には痛みを伴います。なにせ、頑張って実装したものが全くの逆効果であったということもありうるのです。
しかし、多くのユーザーは不便に思ったとしても、それをフィードバックしてはくれません。単に、プロダクトを使うのをやめるだけです。
「チュートリアルごときで」と思うかもしれませんが、ユーザーが最初に触れるのがチュートリアルであるということを忘れないでください。そこで劣悪な体験を受けてしまえば、離脱されてしまう可能性は高くなってしまいます。
まとめ
ユーザーが一番最初に触れる体験である、チュートリアルの設計は、簡単に見えて難しいことがわかります。また、この部分の体験は他に比べて軽視されやすいものでもあります。
初期ユーザーが定着しない場合は、この部分を見直してみるのも良いかと思います。